[PATCH rtems-docs] eng/release: Add libbsd version update
--- eng/release-process.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/eng/release-process.rst b/eng/release-process.rst index be73c3e..8399a9e 100644 --- a/eng/release-process.rst +++ b/eng/release-process.rst @@ -340,6 +340,15 @@ the needed changes. * :file:`tester/rtems/version.cfg`: Update ``rtems_version``. +#. rtems_libbsd requires the following files and branches be changed: + +* :file:`README.md`: Update ``Branches`` section. + +* :file:`wscript`: Update ``rtems_version``. + +* Create a new branch for tracking the FreeBSD stable version. E.g. + ``6-freebsd-12``. + Release Procedure = -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 2/2] wscript: Update RTEMS version to 6.
--- wscript | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wscript b/wscript index 3ca9478e7..faeb6b168 100644 --- a/wscript +++ b/wscript @@ -32,7 +32,7 @@ from __future__ import print_function -rtems_version = "5" +rtems_version = "6" try: import rtems_waf.rtems as rtems -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 1/2] README: Update with information for RTEMS 6
--- README.md | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 9ab8a2603..7794b12b8 100644 --- a/README.md +++ b/README.md @@ -170,17 +170,23 @@ Branches * master - branch intended for the RTEMS master which tracks the FreeBSD master branch. This branch must be used for libbsd development. Back ports to the - 5-freebsd-12 are allowed. + 6-freebsd-12 are allowed. -* 5-freebsd-12 - branch intended for RTEMS 5 which tracks the FreeBSD stable/12 +* 6-freebsd-12 - branch intended for RTEMS 6 which tracks the FreeBSD stable/12 branch. This branch is maintained and regular updates from FreeBSD are planned. It is recommended for production systems. +* 5-freebsd-12 - branch belongs to the RTEMS 5 release. It is based on FreeBSD + stable/12 branch. It is recommended for production systems that use RTEMS 5. + +* 5 - branch belongs to the RTEMS 5 release. It is based on a FreeBSD + development version. + * freebsd-9.3 - branch for some RTEMS version with a FreeBSD 9.3 baseline. - This branch is unmaintained. It is recommended to update to RTEMS 5. + This branch is unmaintained. It is recommended to update to RTEMS 5 or 6. * 4.11 - branch for the RTEMS 4.11 release series. This branch is - unmaintained. It is recommended to update to RTEMS 5. + unmaintained. It is recommended to update to RTEMS 5 or 6. Updating RTEMS Waf Support -- -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 0/2] Update for RTEMS 6
Hello, If the patches are OK, I'll push them to rtems-libbsd master. I will also create a 6-freebsd-12 branch and push only the second patch to that one too. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd] testsuite: Use new name of test-info.h.
In RTEMS the test.h has been renamed to test-info.h to allow the new test framework to take over. --- testsuite/epoch01/test_main.c | 2 +- testsuite/evdev01/init.c| 2 +- testsuite/include/rtems/bsd/test/default-init.h | 2 +- testsuite/include/rtems/bsd/test/default-network-init.h | 2 +- testsuite/include/rtems/bsd/test/default-termios-init.h | 4 ++-- testsuite/smp01/test_main.c | 2 +- testsuite/swi01/init.c | 2 +- testsuite/timeout01/init.c | 2 +- testsuite/usb01/init.c | 2 +- testsuite/usbkbd01/init.c | 2 +- testsuite/usbmouse01/init.c | 2 +- testsuite/usbserial01/init.c| 2 +- 12 files changed, 13 insertions(+), 13 deletions(-) diff --git a/testsuite/epoch01/test_main.c b/testsuite/epoch01/test_main.c index f979a2fe..6aa30653 100644 --- a/testsuite/epoch01/test_main.c +++ b/testsuite/epoch01/test_main.c @@ -56,7 +56,7 @@ #include #include -#include +#include #include #define TEST_NAME "LIBBSD EPOCH 1" diff --git a/testsuite/evdev01/init.c b/testsuite/evdev01/init.c index 38ae1e12..fe588ff4 100644 --- a/testsuite/evdev01/init.c +++ b/testsuite/evdev01/init.c @@ -48,7 +48,7 @@ #define TEST_NAME "LIBBSD EVDEV" #define TEST_STATE_USER_INPUT 1 -#include +#include #define PRIO_OPEN (RTEMS_MAXIMUM_PRIORITY - 12) #define PRIO_KEYBOARD (RTEMS_MAXIMUM_PRIORITY - 11) diff --git a/testsuite/include/rtems/bsd/test/default-init.h b/testsuite/include/rtems/bsd/test/default-init.h index cf7e0ea9..f8ea3acd 100644 --- a/testsuite/include/rtems/bsd/test/default-init.h +++ b/testsuite/include/rtems/bsd/test/default-init.h @@ -10,7 +10,7 @@ #include #include #include -#include +#include #include #include diff --git a/testsuite/include/rtems/bsd/test/default-network-init.h b/testsuite/include/rtems/bsd/test/default-network-init.h index 02cdd33f..b367d956 100644 --- a/testsuite/include/rtems/bsd/test/default-network-init.h +++ b/testsuite/include/rtems/bsd/test/default-network-init.h @@ -45,7 +45,7 @@ #include #include -#include +#include #include #include #include diff --git a/testsuite/include/rtems/bsd/test/default-termios-init.h b/testsuite/include/rtems/bsd/test/default-termios-init.h index 6935007c..f7e8b466 100644 --- a/testsuite/include/rtems/bsd/test/default-termios-init.h +++ b/testsuite/include/rtems/bsd/test/default-termios-init.h @@ -10,7 +10,7 @@ #include #include #include -#include +#include #include #include @@ -156,4 +156,4 @@ rtems_task Init( #include -#endif /* RTEMS_BSD_TEST_DEFAULT_INIT_H */ \ No newline at end of file +#endif /* RTEMS_BSD_TEST_DEFAULT_INIT_H */ diff --git a/testsuite/smp01/test_main.c b/testsuite/smp01/test_main.c index 35c10c96..ad661bdc 100644 --- a/testsuite/smp01/test_main.c +++ b/testsuite/smp01/test_main.c @@ -52,7 +52,7 @@ #include #include -#include +#include #define TEST_NAME "LIBBSD SMP 1" diff --git a/testsuite/swi01/init.c b/testsuite/swi01/init.c index 25e35cfe..d1de191a 100644 --- a/testsuite/swi01/init.c +++ b/testsuite/swi01/init.c @@ -44,7 +44,7 @@ #include #include -#include +#include #include "swi_test.h" diff --git a/testsuite/timeout01/init.c b/testsuite/timeout01/init.c index 1c8df1c9..6dfacd34 100644 --- a/testsuite/timeout01/init.c +++ b/testsuite/timeout01/init.c @@ -42,7 +42,7 @@ #include #include -#include +#include #include "timeout_test.h" diff --git a/testsuite/usb01/init.c b/testsuite/usb01/init.c index 2f5260e3..85bae4d3 100644 --- a/testsuite/usb01/init.c +++ b/testsuite/usb01/init.c @@ -49,7 +49,7 @@ #define TEST_NAME "LIBBSD USB 1" #define TEST_STATE_USER_INPUT 1 -#include +#include static rtems_status_code media_listener(rtems_media_event event, rtems_media_state state, diff --git a/testsuite/usbkbd01/init.c b/testsuite/usbkbd01/init.c index 238e2318..0ea2d2b7 100644 --- a/testsuite/usbkbd01/init.c +++ b/testsuite/usbkbd01/init.c @@ -45,7 +45,7 @@ #define TEST_NAME "LIBBSD USB KEYBOARD" #define TEST_STATE_USER_INPUT 1 -#include +#include #define USB_SERIAL_TEST_BUFFER_SIZE 48 #define PRIO_OPEN (RTEMS_MAXIMUM_PRIORITY - 12) diff --git a/testsuite/usbmouse01/init.c b/testsuite/usbmouse01/init.c index 95276147..5bf732d8 100644 --- a/testsuite/usbmouse01/init.c +++ b/testsuite/usbmouse01/init.c @@ -47,7 +47,7 @@ #define TEST_NAME "LIBBSD USB MOUSE" #define TEST_STATE_USER_INPUT 1 -#include +#include #define USB_SERIAL_TEST_BUFFER_SIZE 48 #define PRIO_OPEN (RTEMS_MAXIMUM_PRIORITY - 12) diff --git a/testsuite/usbserial01/init.c b/testsuite/usbserial01/init.c index 5b62b72e..0e75d8f1 100644 --- a/testsuite/usbserial01/init.c +++ b/testsuite/usbserial01/init.c @@ -46,7 +46,7 @@ #define TEST_NAME "LIBBSD USB SERIAL"
Re: rtems-libbsd: 6-freebsd-12 branch
Hello Gedare, Chris and Sebastian, to summarize: I'll create a 6-freebsd-12 branch with the new commits. Regarding documentation: We have a "Branches" Section in the README.md of the libbsd. Sebastian added it in 2019: https://git.rtems.org/rtems-libbsd/commit/README.md?id=5754194298a9210c8c1a9ac9f1ec800b7671b0fb If it is OK, I'll just update the description with the new branches. I didn't find a good location in the rtems-docs repo. We don't have a lot of documentation for libbsd there. @Chris: You wanted to collect every location where we have to update a description or version number after a release. I think the libbsd Branches section in the README.md is one of these locations too. Beneath that there is a rtems_version = "5" in the libbsd wscript. I think you had a ticket to collect these changes? Or is it a section in the documentation? Best regards Christian On 29/07/2020 06:09, Gedare Bloom wrote: > On Tue, Jul 28, 2020 at 9:29 PM Chris Johns wrote: >> >> On 29/7/20 1:16 am, Christian Mauderer wrote: >>> On 28/07/2020 17:14, Gedare Bloom wrote: >>>> On Tue, Jul 28, 2020 at 7:29 AM Christian Mauderer >>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I sent a few patches about ten days ago that add some features (like a >>>>> GPIO driver for i.MX that is based on the RTEMS i.MX GPIO driver that I >>>>> also posted). I would like to push them soon. >>>>> >>>>> Normally I would have pushed them to master and 5-freebsd-12. But the >>>>> later one is now a release branch and shouldn't get new features. Would >>>>> that be a good time to create a 6-freebsd-12 branch? >>>>> >>>> >>>> I would let Sebastian or Chris decide. Do we anticipate having a >>>> paired release of RTEMS-6 with FreeBSD-12? (Probably so, since we try >>>> to reduce the release cycle time.) >>> >>> If not: Would it rather be a 6-freebsd-stable branch? With that name we >>> can update it to 13 as soon as FreeBSD makes that jump. >> >> I think 6-freebsd-12. I am not sure about using stable as a user tracking the >> branch may get a surprise when it jumps to from 12 to 13. >> >> Please add a 6-freebsd-12 branch. >> >> It would be nice something was added to the eng manual on this topic. >> > > At the very least, it should be well-documented in the libbsd README. > >> Thanks >> Chris -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: rtems-libbsd: 6-freebsd-12 branch
On 28/07/2020 17:14, Gedare Bloom wrote: > On Tue, Jul 28, 2020 at 7:29 AM Christian Mauderer > wrote: >> >> Hello, >> >> I sent a few patches about ten days ago that add some features (like a >> GPIO driver for i.MX that is based on the RTEMS i.MX GPIO driver that I >> also posted). I would like to push them soon. >> >> Normally I would have pushed them to master and 5-freebsd-12. But the >> later one is now a release branch and shouldn't get new features. Would >> that be a good time to create a 6-freebsd-12 branch? >> > > I would let Sebastian or Chris decide. Do we anticipate having a > paired release of RTEMS-6 with FreeBSD-12? (Probably so, since we try > to reduce the release cycle time.) If not: Would it rather be a 6-freebsd-stable branch? With that name we can update it to 13 as soon as FreeBSD makes that jump. > >> Best regards >> >> Christian >> -- >> >> embedded brains GmbH >> Herr Christian Mauderer >> Dornierstr. 4 >> D-82178 Puchheim >> Germany >> email: christian.maude...@embedded-brains.de >> Phone: +49-89-18 94 741 - 18 >> Fax: +49-89-18 94 741 - 08 >> 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 -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
rtems-libbsd: 6-freebsd-12 branch
Hello, I sent a few patches about ten days ago that add some features (like a GPIO driver for i.MX that is based on the RTEMS i.MX GPIO driver that I also posted). I would like to push them soon. Normally I would have pushed them to master and 5-freebsd-12. But the later one is now a release branch and shouldn't get new features. Would that be a good time to create a 6-freebsd-12 branch? Best regards Christian -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: [PATCH rtems-tools] trace: Use c++14 instead of c++11 if possible
Hello Joel,
On 22/07/2020 21:39, Joel Sherrill wrote:
>
>
> On Wed, Jul 22, 2020 at 2:26 PM Christian Mauderer <mailto:o...@c-mauderer.de>> wrote:
>
> Ping again.
>
> It's clearly not BSP specific. So I would like to get an approval for
> that before pushing it anywhere.
>
>
> CentOS 7's gcc appears to have the option and I would assume this is the
> oldest distribution anyone is using.
Currently CentOS 6 is still supported (till end of this year). So that
would most likely be a better reference. But it's not really a problem:
The patch adds a check whether c++14 is available and uses it if it is.
If it is not available it will fall back to c++11 which is the same
cflag we had before. So it works on CentOS 6 too.
>
> $ gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
>
> Go ahead and push it.
Thanks. I'll do that. I'll also update rtems-source-builder to use the
new version.
Best regards
Christian
>
> --joel
>
>
> On 15/06/2020 17:36, Christian Mauderer wrote:
> > Ping.
> >
> > Currently shouldn't be a matter for much hosts (less than 20 including
> > FreeBSD, Fedora, Arch, openSUSE according to distrowatch [1]) but I
> > assume that llvm 10 will spread fast.
> >
> >
> > [1]
> >
>
> http://distrowatch.org/search.php?pkg=llvm=greaterequal=10=InLatest#pkgsearch
> >
> >
> > On 08/06/2020 08:52, Christian Mauderer wrote:
> >> llvm version 10 uses features from c++14 standard in the headers.
> With
> >> that, the record/record-main-lttng.cc doesn't build any more.
> This patch
> >> makes sure that c++14 is used if it is available.
> >> ---
> >> trace/wscript | 6 +-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/trace/wscript b/trace/wscript
> >> index 656f92b..53a1ab4 100644
> >> --- a/trace/wscript
> >> +++ b/trace/wscript
> >> @@ -45,6 +45,7 @@ def configure(conf):
> >> if conf.check(header_name='zlib.h', features='cxx',
> mandatory=False):
> >> conf.check_cxx(lib = 'z')
> >> conf.check_cxx(lib = 'ws2_32', mandatory=False)
> >> + conf.check_cxx(cxxflags='-std=c++14', mandatory=False,
> define_name="HAVE_STD_CXX14")
> >> conf.write_config_header('config.h')
> >>
> >> def build(bld):
> >> @@ -60,7 +61,10 @@ def build(bld):
> >> conf['warningflags'] = ['-Wall', '-Wextra', '-pedantic']
> >> conf['optflags'] = bld.env.C_OPTS
> >> conf['cflags'] = ['-pipe', '-g'] + conf['optflags']
> >> - conf['cxxflags'] = ['-std=c++11'] + conf['cflags']
> >> + cxxstd = '-std=c++11'
> >> + if bld.env.HAVE_STD_CXX14:
> >> + cxxstd = '-std=c++14'
> >> + conf['cxxflags'] = [cxxstd] + conf['cflags']
> >> conf['linkflags'] = ['-g']
> >> conf['lib'] = []
> >> if bld.env.LIB_WS2_32:
> >>
> > ___
> > devel mailing list
> > devel@rtems.org <mailto:devel@rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> ___
> devel mailing list
> devel@rtems.org <mailto: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-tools] trace: Use c++14 instead of c++11 if possible
Ping again.
It's clearly not BSP specific. So I would like to get an approval for
that before pushing it anywhere.
On 15/06/2020 17:36, Christian Mauderer wrote:
> Ping.
>
> Currently shouldn't be a matter for much hosts (less than 20 including
> FreeBSD, Fedora, Arch, openSUSE according to distrowatch [1]) but I
> assume that llvm 10 will spread fast.
>
>
> [1]
> http://distrowatch.org/search.php?pkg=llvm=greaterequal=10=InLatest#pkgsearch
>
>
> On 08/06/2020 08:52, Christian Mauderer wrote:
>> llvm version 10 uses features from c++14 standard in the headers. With
>> that, the record/record-main-lttng.cc doesn't build any more. This patch
>> makes sure that c++14 is used if it is available.
>> ---
>> trace/wscript | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/trace/wscript b/trace/wscript
>> index 656f92b..53a1ab4 100644
>> --- a/trace/wscript
>> +++ b/trace/wscript
>> @@ -45,6 +45,7 @@ def configure(conf):
>> if conf.check(header_name='zlib.h', features='cxx', mandatory=False):
>> conf.check_cxx(lib = 'z')
>> conf.check_cxx(lib = 'ws2_32', mandatory=False)
>> +conf.check_cxx(cxxflags='-std=c++14', mandatory=False,
>> define_name="HAVE_STD_CXX14")
>> conf.write_config_header('config.h')
>>
>> def build(bld):
>> @@ -60,7 +61,10 @@ def build(bld):
>> conf['warningflags'] = ['-Wall', '-Wextra', '-pedantic']
>> conf['optflags'] = bld.env.C_OPTS
>> conf['cflags'] = ['-pipe', '-g'] + conf['optflags']
>> -conf['cxxflags'] = ['-std=c++11'] + conf['cflags']
>> +cxxstd = '-std=c++11'
>> +if bld.env.HAVE_STD_CXX14:
>> +cxxstd = '-std=c++14'
>> +conf['cxxflags'] = [cxxstd] + conf['cflags']
>> conf['linkflags'] = ['-g']
>> conf['lib'] = []
>> if bld.env.LIB_WS2_32:
>>
> ___
> 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 3/3] bsps/fdt: Make sure data is cache aligned.
Hello Gedare,
I'll re-check to make absolutely sure and push it afterwards.
Best regards
Christian
On 20/07/2020 22:01, Gedare Bloom wrote:
> looks good if it works, thanks Christian!
>
> On Sun, Jul 19, 2020 at 11:47 PM Christian Mauderer
> wrote:
>>
>> The cache of the fdt blob is flushed after copy. Therefore it should be
>> aligned.
>> ---
>> bsps/shared/start/bsp-fdt.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
>> index 7e8d8922a8..50a485eb16 100644
>> --- a/bsps/shared/start/bsp-fdt.c
>> +++ b/bsps/shared/start/bsp-fdt.c
>> @@ -29,10 +29,11 @@
>>
>> #ifdef BSP_FDT_BLOB_READ_ONLY
>> static const uint32_t
>> -bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] = { 0xdeadbeef };
>> +bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)]
>> CPU_STRUCTURE_ALIGNMENT =
>> + { 0xdeadbeef };
>> #else
>> static uint32_t
>> -bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)];
>> +bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)]
>> CPU_STRUCTURE_ALIGNMENT;
>> #endif
>>
>> void bsp_fdt_copy(const void *src)
>> @@ -48,6 +49,7 @@ void bsp_fdt_copy(const void *src)
>>
>>if (s != d) {
>> size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
>> +size_t aligned_size = roundup2(m, CPU_CACHE_LINE_BYTES);
>> size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
>> size_t i;
>>
>> @@ -55,7 +57,7 @@ void bsp_fdt_copy(const void *src)
>>d[i] = s[i];
>> }
>>
>> -rtems_cache_flush_multiple_data_lines(d, m);
>> +rtems_cache_flush_multiple_data_lines(d, aligned_size);
>>}
>> }
>>
>> --
>> 2.26.2
>>
--
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
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 rtems v2 3/3] bsps/fdt: Make sure data is cache aligned.
The cache of the fdt blob is flushed after copy. Therefore it should be
aligned.
---
bsps/shared/start/bsp-fdt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
index 7e8d8922a8..50a485eb16 100644
--- a/bsps/shared/start/bsp-fdt.c
+++ b/bsps/shared/start/bsp-fdt.c
@@ -29,10 +29,11 @@
#ifdef BSP_FDT_BLOB_READ_ONLY
static const uint32_t
-bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] = { 0xdeadbeef };
+bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] CPU_STRUCTURE_ALIGNMENT
=
+ { 0xdeadbeef };
#else
static uint32_t
-bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)];
+bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] CPU_STRUCTURE_ALIGNMENT;
#endif
void bsp_fdt_copy(const void *src)
@@ -48,6 +49,7 @@ void bsp_fdt_copy(const void *src)
if (s != d) {
size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
+size_t aligned_size = roundup2(m, CPU_CACHE_LINE_BYTES);
size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
size_t i;
@@ -55,7 +57,7 @@ void bsp_fdt_copy(const void *src)
d[i] = s[i];
}
-rtems_cache_flush_multiple_data_lines(d, m);
+rtems_cache_flush_multiple_data_lines(d, aligned_size);
}
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems 3/3] bsps/fdt: Make sure data is cache aligned.
Hello Gedare,
thanks for the review.
On 17/07/2020 17:53, Gedare Bloom wrote:
> The other 2 BSP-specific patches look fine. I didn't look too closely
> at the imx-specific part.
>
> On Thu, Jul 16, 2020 at 11:55 PM Christian Mauderer
> wrote:
>>
>> The cache of the fdt blob is flushed after copy. Therefore it should be
>> aligned.
>> ---
>> bsps/shared/start/bsp-fdt.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
>> index 7e8d8922a8..f55273e4ca 100644
>> --- a/bsps/shared/start/bsp-fdt.c
>> +++ b/bsps/shared/start/bsp-fdt.c
>> @@ -28,10 +28,10 @@
>> #endif
>>
>> #ifdef BSP_FDT_BLOB_READ_ONLY
>> -static const uint32_t
>> +static const uint32_t CPU_STRUCTURE_ALIGNMENT
>
> Typically seen the alignment after the variable decl. Maybe it is
> flexible, but we might consider a rule for consistency if both
> placements work.
I'll move it.
>
>> bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] = { 0xdeadbeef };
>> #else
>> -static uint32_t
>> +static uint32_t CPU_STRUCTURE_ALIGNMENT
>> bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)];
>> #endif
>>
>> @@ -48,6 +48,7 @@ void bsp_fdt_copy(const void *src)
>>
>>if (s != d) {
>> size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
>> +size_t aligned_size = ((m-1) | (CPU_CACHE_LINE_BYTES-1)) + 1;
>
> This is a little bit of magic, I guess it works with cache line bytes
> a power of 2. Do we have a macro for this?
>
I don't think that we have a macro for alignment. But I found a
"roundup2" in newlibs sys/param.h after some searching. I'll try to use
that one.
>> size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
>> size_t i;
>>
>> @@ -55,7 +56,7 @@ void bsp_fdt_copy(const void *src)
>>d[i] = s[i];
>> }
>>
>> -rtems_cache_flush_multiple_data_lines(d, m);
>> +rtems_cache_flush_multiple_data_lines(d, aligned_size);
>>}
>> }
>>
>> --
>> 2.26.2
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
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
Re: A question about rtems license
Hello, note that I'm not a lawyer. I can only provide my personal opinion regarding that topic. Depending of the legal system of your country a lawyer might has a different point of view. I'm also only a small part of the project and can't speak for all persons involved. As far as I understand your situation you basically forked RTEMS. The fork would consist of "rtems src" and "rtems src2". These parts would be covered by the RTEMS license. So if you provide a binary to someone, you would have to make the "rtems src" and "rtems src2" available to this person too if they ask. But your application is still a separate part and would be covered by the linking exception. That means: you can keep it private. Please note that there is an ongoing effort to change the RTEMS license to a BSD style license. A lot of sources are already BSD licensed. You can see that if you have a look at the file headers. As another note: RTEMS is always open to patches. So you might want to think about polishing the "rtems src2" parts a bit and sending them to the mailing list for integration into the official sources. Best regards Christian On 18/07/2020 11:45, small...@aliyun.com wrote: > Hi, > There is a project using rtems as a real time os in an arm cortex R5 > bsp. Primary RTEMS License says > that RTEMS is free software; you can redistribute it and/or modify it under > terms of the > GPL. > As a special exception, including RTEMS header files in a file, instantiating > RTEMS generics or templates, or linking other files with RTEMS objects to > produce an executable application, does not by itself cause the resulting > executable application to be covered by the GPL. > I draw a picture to describe this special exception: > There are "rtems src", "rtems header" and our "application". The "rtems > src" will be compiled to a lib called "rtems lib". If our "application" > includes "rtems header" and linkes with "rtems lib", then our > "application" does not follow GPL. > > OK, here is my question: we modify some code in "rtems src" and build it > to "rtems lib2". If our "application" includes "rtems header" and > linkes with "rtems lib2", whether or not our "application" should follow > GPL? > (of course, rtems src2 should follow GPL) > > > small...@aliyun.com > > ___ > 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-libbsd 1/7] gpioregulator: Remove.
Sorry: I accidentally set a reply address instead of having the patch
set as a reply to the intro mail for the first patch set. Please don't
use the reply to addres. It won't work.
On 17/07/2020 07:56, Christian Mauderer wrote:
> There is a bug in the #ifdef regarding FDT so this file hasn't been
> compiled. If that bug is solved, the driver doesn't work for some other
> reason.
>
> With the FDT-bug the driver hasn't been used by anyone. So just remove
> it again.
> ---
> freebsd/sys/dev/gpio/gpioregulator.c | 352 ---
> libbsd.py| 1 -
> rtemsbsd/include/bsp/nexus-devices.h | 1 -
> 3 files changed, 354 deletions(-)
> delete mode 100644 freebsd/sys/dev/gpio/gpioregulator.c
>
> diff --git a/freebsd/sys/dev/gpio/gpioregulator.c
> b/freebsd/sys/dev/gpio/gpioregulator.c
> deleted file mode 100644
> index 8ca35bfe..
> --- a/freebsd/sys/dev/gpio/gpioregulator.c
> +++ /dev/null
> @@ -1,352 +0,0 @@
> -#include
> -
> -/*-
> - * Copyright (c) 2016 Jared McNeill
> - * All rights reserved.
> - *
> - * 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 AUTHOR ``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 AUTHOR 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.
> - *
> - * $FreeBSD$
> - */
> -
> -/*
> - * GPIO controlled regulators
> - */
> -
> -#include
> -__FBSDID("$FreeBSD$");
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#if !defined(__rtems__) || defined(FDT)
> -#include
> -#include
> -
> -#include
> -
> -#include
> -
> -#include
> -
> -struct gpioregulator_state {
> - int val;
> - uint32_tmask;
> -};
> -
> -struct gpioregulator_init_def {
> - struct regnode_init_def reg_init_def;
> - struct gpiobus_pin *enable_pin;
> - int enable_pin_valid;
> - int startup_delay_us;
> - int nstates;
> - struct gpioregulator_state *states;
> - int npins;
> - struct gpiobus_pin **pins;
> -};
> -
> -struct gpioregulator_reg_sc {
> - struct regnode *regnode;
> - device_tbase_dev;
> - struct regnode_std_param*param;
> - struct gpioregulator_init_def *def;
> -};
> -
> -struct gpioregulator_softc {
> - device_tdev;
> - struct gpioregulator_reg_sc *reg_sc;
> - struct gpioregulator_init_def init_def;
> -};
> -
> -static int
> -gpioregulator_regnode_init(struct regnode *regnode)
> -{
> - struct gpioregulator_reg_sc *sc;
> - int error, n;
> -
> - sc = regnode_get_softc(regnode);
> -
> - if (sc->def->enable_pin_valid == 1) {
> - error = gpio_pin_setflags(sc->def->enable_pin, GPIO_PIN_OUTPUT);
> - if (error != 0)
> - return (error);
> - }
> -
> - for (n = 0; n < sc->def->npins; n++) {
> - error = gpio_pin_setflags(sc->def->pins[n], GPIO_PIN_OUTPUT);
> - if (error != 0)
> - return (error);
> - }
> -
> - return (0);
> -}
> -
> -static int
> -gpioregulator_regnode_enable(struct regnode *regnode, bool enable, int
> *udelay)
> -{
> - struct gpioregulator_reg_sc *sc;
> - bool active;
> -
[PATCH rtems-libbsd 5/7] busdma: Don't sync nocache memory on ARM
The busdma shouldn't try to flush or invalidate cache in a nocache area.
---
rtemsbsd/rtems/rtems-kernel-bus-dma.c | 8
1 file changed, 8 insertions(+)
diff --git a/rtemsbsd/rtems/rtems-kernel-bus-dma.c
b/rtemsbsd/rtems/rtems-kernel-bus-dma.c
index 4dc634f3..bda4f3d7 100644
--- a/rtemsbsd/rtems/rtems-kernel-bus-dma.c
+++ b/rtemsbsd/rtems/rtems-kernel-bus-dma.c
@@ -48,6 +48,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -400,6 +402,12 @@ bus_dmamap_sync(bus_dma_tag_t dmat, bus_dmamap_t map,
bus_dmasync_op_t op)
uintptr_t size = map->buffer_size;
uintptr_t begin = (uintptr_t) map->buffer_begin;
uintptr_t end = begin + size;
+#ifdef __arm__
+ if (begin >= (uintptr_t)bsp_section_nocache_begin &&
+ end <= (uintptr_t)bsp_section_nocachenoload_end) {
+ return;
+ }
+#endif
if ((map->flags & DMAMAP_CACHE_ALIGNED) != 0) {
begin &= ~CLMASK;
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 3/7] busdma: Option to round to cache lines on sync
Some targets support only flushing or invalidating complete cache lines.
In this cases misaligned buffers might lead to unexpected results. This
patch adds a flag that allows drivers to signal to the bus dma driver
that it is OK to round a buffer to the next full cache line. That's for
example necessary if a driver wants to send out 14 byte via a USB DMA.
Only the driver knows whether these 14 bytes are located in an otherwise
unused cache line aligned buffer.
---
freebsd/sys/dev/usb/usb_busdma.c | 31
freebsd/sys/dev/usb/usb_busdma.h | 5
freebsd/sys/dev/usb/usb_transfer.c | 20 +
freebsd/sys/dev/usb/usbdi.h | 4 +++
freebsd/sys/sys/bus_dma.h| 6
rtemsbsd/include/machine/rtems-bsd-bus-dma.h | 3 ++
rtemsbsd/rtems/rtems-kernel-bus-dma-mbuf.c | 3 ++
rtemsbsd/rtems/rtems-kernel-bus-dma.c| 9 ++
8 files changed, 81 insertions(+)
diff --git a/freebsd/sys/dev/usb/usb_busdma.c b/freebsd/sys/dev/usb/usb_busdma.c
index dc52fe15..b74f0823 100644
--- a/freebsd/sys/dev/usb/usb_busdma.c
+++ b/freebsd/sys/dev/usb/usb_busdma.c
@@ -67,6 +67,9 @@
#include
#include
#endif /* USB_GLOBAL_INCLUDE_FILE */
+#ifdef __rtems__
+#include
+#endif /* __rtems__ */
#if USB_HAVE_BUSDMA
static voidusb_dma_tag_create(struct usb_dma_tag *, usb_size_t,
usb_size_t);
@@ -543,6 +546,15 @@ usb_pc_alloc_mem(struct usb_page_cache *pc, struct
usb_page *pg,
uptag = pc->tag_parent;
+#if defined(__rtems__) && defined(CPU_DATA_CACHE_ALIGNMENT)
+ while (align % CPU_DATA_CACHE_ALIGNMENT != 0) {
+ align *= 2;
+ }
+ if (size % CPU_DATA_CACHE_ALIGNMENT != 0) {
+ size = (size + (CPU_DATA_CACHE_ALIGNMENT - 1)) &
+ ~(CPU_DATA_CACHE_ALIGNMENT - 1);
+ }
+#endif /* __rtems__ */
if (align != 1) {
/*
* The alignment must be greater or equal to the
@@ -605,7 +617,12 @@ usb_pc_alloc_mem(struct usb_page_cache *pc, struct
usb_page *pg,
/* load memory into DMA */
err = bus_dmamap_load(
utag->tag, map, ptr, size, _pc_alloc_mem_cb,
+#if defined(__rtems__) && CPU_DATA_CACHE_ALIGNMENT
+ pc, (BUS_DMA_WAITOK | BUS_DMA_COHERENT |
+ BUS_DMA_DO_CACHE_LINE_BLOW_UP));
+#else /* __rtems__ */
pc, (BUS_DMA_WAITOK | BUS_DMA_COHERENT));
+#endif /* __rtems__ */
if (err == EINPROGRESS) {
cv_wait(uptag->cv, uptag->mtx);
@@ -662,6 +679,12 @@ usb_pc_free_mem(struct usb_page_cache *pc)
uint8_t
usb_pc_load_mem(struct usb_page_cache *pc, usb_size_t size, uint8_t sync)
{
+#ifdef __rtems__
+ int flags;
+
+ flags = pc->dma_do_cache_line_blow_up ?
+ BUS_DMA_DO_CACHE_LINE_BLOW_UP : 0;
+#endif /* __rtems__ */
/* setup page cache */
pc->page_offset_buf = 0;
pc->page_offset_end = size;
@@ -687,7 +710,11 @@ usb_pc_load_mem(struct usb_page_cache *pc, usb_size_t
size, uint8_t sync)
*/
err = bus_dmamap_load(
pc->tag, pc->map, pc->buffer, size,
+#ifndef __rtems__
_pc_alloc_mem_cb, pc, BUS_DMA_WAITOK);
+#else /* __rtems__ */
+ _pc_alloc_mem_cb, pc, BUS_DMA_WAITOK | flags);
+#endif /* __rtems__ */
if (err == EINPROGRESS) {
cv_wait(uptag->cv, uptag->mtx);
err = 0;
@@ -709,7 +736,11 @@ usb_pc_load_mem(struct usb_page_cache *pc, usb_size_t
size, uint8_t sync)
*/
if (bus_dmamap_load(
pc->tag, pc->map, pc->buffer, size,
+#ifndef __rtems__
_pc_load_mem_cb, pc, BUS_DMA_WAITOK)) {
+#else /* __rtems__ */
+ _pc_load_mem_cb, pc, BUS_DMA_WAITOK | flags)) {
+#endif /* __rtems__ */
}
}
} else {
diff --git a/freebsd/sys/dev/usb/usb_busdma.h b/freebsd/sys/dev/usb/usb_busdma.h
index d75e67ee..03eca30d 100644
--- a/freebsd/sys/dev/usb/usb_busdma.h
+++ b/freebsd/sys/dev/usb/usb_busdma.h
@@ -102,6 +102,11 @@ struct usb_page_cache {
* from the memory. Else write. */
uint8_t ismultiseg:1; /* set if we can have multiple
* segments */
+#ifdef __rtems__
+ uint8_t dma_do_cache_line_blow_up:1;
+ /* set if it is OK to align the buffer
+* start and end to next cache line */
+#endif /* __rtems__ */
#endif
};
diff --git a/freebsd/sys/dev/usb/usb_transfer.c
b/freebsd/sys/dev/usb/usb_transfer.c
index 3b67c20c..ee1e4c28 100644
--- a/freebsd/sys/dev/usb/usb_transfer.c
+++ b/freebsd/sys/dev/usb/usb_transfer.c
@@ -2195,6 +2195,9 @@
[PATCH rtems-libbsd 7/7] if_ffec: Align send buffers to cache if necessary.
---
freebsd/sys/dev/ffec/if_ffec.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c
index aee2aa64..e8287ed2 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -714,8 +714,16 @@ ffec_encap(struct ifnet *ifp, struct ffec_softc *sc,
struct mbuf *m0,
tx_desc->buf_paddr = segs[i].ds_addr;
tx_desc->flags2 = flags2;
#ifdef __rtems__
- rtems_cache_flush_multiple_data_lines((void *)segs[i].ds_addr,
- segs[i].ds_len);
+ uintptr_t addr_flush = (uintptr_t)segs[i].ds_addr;
+ size_t len_flush = segs[i].ds_len;
+#ifdef CPU_CACHE_LINE_BYTES
+ /* mbufs should be cache line aligned. So we can just round. */
+ addr_flush = addr_flush & ~(CPU_CACHE_LINE_BYTES - 1);
+ len_flush = (len_flush + (CPU_CACHE_LINE_BYTES - 1)) &
+ ~(CPU_CACHE_LINE_BYTES - 1);
+#endif
+ rtems_cache_flush_multiple_data_lines((void*)addr_flush,
+ len_flush);
#endif /* __rtems__ */
if (i == 0) {
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 4/7] rtwn_usb: Make sure buffers are cache aligned
---
freebsd/sys/dev/rtwn/usb/rtwn_usb_attach.c | 11 +++
freebsd/sys/dev/rtwn/usb/rtwn_usb_tx.c | 7 +++
2 files changed, 18 insertions(+)
diff --git a/freebsd/sys/dev/rtwn/usb/rtwn_usb_attach.c
b/freebsd/sys/dev/rtwn/usb/rtwn_usb_attach.c
index 8626d0a3..fad41f36 100644
--- a/freebsd/sys/dev/rtwn/usb/rtwn_usb_attach.c
+++ b/freebsd/sys/dev/rtwn/usb/rtwn_usb_attach.c
@@ -37,6 +37,10 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#ifdef __rtems__
+#include
+#include
+#endif /* __rtems__ */
#include
#include
@@ -115,7 +119,14 @@ rtwn_usb_alloc_list(struct rtwn_softc *sc, struct
rtwn_data data[],
for (i = 0; i < ndata; i++) {
struct rtwn_data *dp = [i];
dp->m = NULL;
+#if defined(__rtems__) && defined(CPU_DATA_CACHE_ALIGNMENT)
+ maxsz = maxsz + (CPU_DATA_CACHE_ALIGNMENT - 1) &
+ ~(CPU_DATA_CACHE_ALIGNMENT - 1);
+ dp->buf = rtems_heap_allocate_aligned_with_boundary(maxsz,
+ CPU_DATA_CACHE_ALIGNMENT, 0);
+#else /* __rtems__ */
dp->buf = malloc(maxsz, M_USBDEV, M_NOWAIT);
+#endif /* __rtems__ */
if (dp->buf == NULL) {
device_printf(sc->sc_dev,
"could not allocate buffer\n");
diff --git a/freebsd/sys/dev/rtwn/usb/rtwn_usb_tx.c
b/freebsd/sys/dev/rtwn/usb/rtwn_usb_tx.c
index 61f0ba43..14762c0c 100644
--- a/freebsd/sys/dev/rtwn/usb/rtwn_usb_tx.c
+++ b/freebsd/sys/dev/rtwn/usb/rtwn_usb_tx.c
@@ -64,6 +64,10 @@ __FBSDID("$FreeBSD$");
#include
#include
+#ifdef __rtems__
+#include
+#endif /* __rtems__ */
+
static struct rtwn_data * _rtwn_usb_getbuf(struct rtwn_usb_softc *);
static struct rtwn_data * rtwn_usb_getbuf(struct rtwn_usb_softc *);
static voidrtwn_usb_txeof(struct rtwn_usb_softc *,
@@ -170,6 +174,9 @@ tr_setup:
if (data->ni == NULL && RTWN_CHIP_HAS_BCNQ1(sc))
rtwn_switch_bcnq(sc, data->id);
usbd_xfer_set_frame_data(xfer, 0, data->buf, data->buflen);
+#if defined(__rtems__) && defined(CPU_DATA_CACHE_ALIGNMENT)
+ usbd_xfer_frame_allow_cache_line_blow_up(xfer, 0);
+#endif /* __rtems__ */
usbd_transfer_submit(xfer);
if (sc->sc_ratectl != RTWN_RATECTL_NET80211)
sc->sc_tx_n_active++;
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 2/7] imx: Use RTEMS GPIO driver instead of FreeBSD one.
---
freebsd/sys/arm/freescale/imx/imx_gpio.c | 914 --
libbsd.py | 2 +-
rtemsbsd/include/bsp/nexus-devices.h | 2 +-
.../sys/arm/freescale/imx/imx_rtems_gpio.c| 306 ++
4 files changed, 308 insertions(+), 916 deletions(-)
delete mode 100644 freebsd/sys/arm/freescale/imx/imx_gpio.c
create mode 100644 rtemsbsd/sys/arm/freescale/imx/imx_rtems_gpio.c
diff --git a/freebsd/sys/arm/freescale/imx/imx_gpio.c
b/freebsd/sys/arm/freescale/imx/imx_gpio.c
deleted file mode 100644
index c33205c2..
--- a/freebsd/sys/arm/freescale/imx/imx_gpio.c
+++ /dev/null
@@ -1,914 +0,0 @@
-#include
-
-/*-
- * Copyright (c) 2012, 2013 The FreeBSD Foundation
- * All rights reserved.
- *
- * This software was developed by Oleksandr Rybalko under sponsorship
- * from the FreeBSD Foundation.
- *
- * 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 AUTHOR 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 AUTHOR 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.
- */
-
-/*
- * Freescale i.MX515 GPIO driver.
- */
-
-#include
-__FBSDID("$FreeBSD$");
-
-#include
-
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-
-#include
-
-#ifdef INTRNG
-#include
-#endif
-
-#defineWRITE4(_sc, _r, _v)
\
- bus_space_write_4((_sc)->sc_iot, (_sc)->sc_ioh, (_r), (_v))
-#defineREAD4(_sc, _r)
\
- bus_space_read_4((_sc)->sc_iot, (_sc)->sc_ioh, (_r))
-#defineSET4(_sc, _r, _m)
\
- WRITE4((_sc), (_r), READ4((_sc), (_r)) | (_m))
-#defineCLEAR4(_sc, _r, _m)
\
- WRITE4((_sc), (_r), READ4((_sc), (_r)) & ~(_m))
-
-/* Registers definition for Freescale i.MX515 GPIO controller */
-
-#defineIMX_GPIO_DR_REG 0x000 /* Pin Data */
-#defineIMX_GPIO_OE_REG 0x004 /* Set Pin Output */
-#defineIMX_GPIO_PSR_REG0x008 /* Pad Status */
-#defineIMX_GPIO_ICR1_REG 0x00C /* Interrupt Configuration */
-#defineIMX_GPIO_ICR2_REG 0x010 /* Interrupt Configuration */
-#defineGPIO_ICR_COND_LOW 0
-#defineGPIO_ICR_COND_HIGH 1
-#defineGPIO_ICR_COND_RISE 2
-#defineGPIO_ICR_COND_FALL 3
-#defineGPIO_ICR_COND_MASK 0x3
-#defineIMX_GPIO_IMR_REG0x014 /* Interrupt Mask Register */
-#defineIMX_GPIO_ISR_REG0x018 /* Interrupt Status Register */
-#defineIMX_GPIO_EDGE_REG 0x01C /* Edge Detect Register */
-
-#ifdef INTRNG
-#defineDEFAULT_CAPS(GPIO_PIN_INPUT | GPIO_PIN_OUTPUT | \
-GPIO_INTR_LEVEL_LOW | GPIO_INTR_LEVEL_HIGH | GPIO_INTR_EDGE_RISING | \
-GPIO_INTR_EDGE_FALLING | GPIO_INTR_EDGE_BOTH)
-#else
-#defineDEFAULT_CAPS(GPIO_PIN_INPUT | GPIO_PIN_OUTPUT)
-#endif
-
-#defineNGPIO 32
-
-#ifdef INTRNG
-struct gpio_irqsrc {
- struct intr_irqsrc gi_isrc;
- u_int gi_irq;
- uint32_tgi_mode;
-};
-#endif
-
-struct imx51_gpio_softc {
- device_tdev;
- device_tsc_busdev;
- struct mtx sc_mtx;
- struct resource *sc_res[3]; /* 1 x mem, 2 x IRQ */
- void*gpio_ih[2];
- bus_space_tag_t sc_iot;
- bus_space_handle_t sc_ioh;
- int gpio_npins;
- struct gpio_pin gpio_pins[NGPIO];
-#ifdef INTRNG
- struct gpio_irqsrc
[PATCH rtems-libbsd 6/7] imx: Don't use USB_NEED_BUSDMA_COHERENT_ALLOC
That option makes problems with some drivers because the buffers are not allways cache line aligned. --- rtemsbsd/include/rtems/bsd/local/opt_usb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rtemsbsd/include/rtems/bsd/local/opt_usb.h b/rtemsbsd/include/rtems/bsd/local/opt_usb.h index 9f654863..a4138d5b 100644 --- a/rtemsbsd/include/rtems/bsd/local/opt_usb.h +++ b/rtemsbsd/include/rtems/bsd/local/opt_usb.h @@ -7,7 +7,7 @@ #define USB_HAVE_BUSDMA 1 -#if !defined(LIBBSP_ARM_IMX_BSP_H) && !defined(LIBBSP_ARM_STM32H7_BSP_H) +#if !defined(LIBBSP_ARM_STM32H7_BSP_H) #define USB_NEED_BUSDMA_COHERENT_ALLOC 1 #endif -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 1/7] gpioregulator: Remove.
There is a bug in the #ifdef regarding FDT so this file hasn't been
compiled. If that bug is solved, the driver doesn't work for some other
reason.
With the FDT-bug the driver hasn't been used by anyone. So just remove
it again.
---
freebsd/sys/dev/gpio/gpioregulator.c | 352 ---
libbsd.py| 1 -
rtemsbsd/include/bsp/nexus-devices.h | 1 -
3 files changed, 354 deletions(-)
delete mode 100644 freebsd/sys/dev/gpio/gpioregulator.c
diff --git a/freebsd/sys/dev/gpio/gpioregulator.c
b/freebsd/sys/dev/gpio/gpioregulator.c
deleted file mode 100644
index 8ca35bfe..
--- a/freebsd/sys/dev/gpio/gpioregulator.c
+++ /dev/null
@@ -1,352 +0,0 @@
-#include
-
-/*-
- * Copyright (c) 2016 Jared McNeill
- * All rights reserved.
- *
- * 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 AUTHOR ``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 AUTHOR 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.
- *
- * $FreeBSD$
- */
-
-/*
- * GPIO controlled regulators
- */
-
-#include
-__FBSDID("$FreeBSD$");
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#if !defined(__rtems__) || defined(FDT)
-#include
-#include
-
-#include
-
-#include
-
-#include
-
-struct gpioregulator_state {
- int val;
- uint32_tmask;
-};
-
-struct gpioregulator_init_def {
- struct regnode_init_def reg_init_def;
- struct gpiobus_pin *enable_pin;
- int enable_pin_valid;
- int startup_delay_us;
- int nstates;
- struct gpioregulator_state *states;
- int npins;
- struct gpiobus_pin **pins;
-};
-
-struct gpioregulator_reg_sc {
- struct regnode *regnode;
- device_tbase_dev;
- struct regnode_std_param*param;
- struct gpioregulator_init_def *def;
-};
-
-struct gpioregulator_softc {
- device_tdev;
- struct gpioregulator_reg_sc *reg_sc;
- struct gpioregulator_init_def init_def;
-};
-
-static int
-gpioregulator_regnode_init(struct regnode *regnode)
-{
- struct gpioregulator_reg_sc *sc;
- int error, n;
-
- sc = regnode_get_softc(regnode);
-
- if (sc->def->enable_pin_valid == 1) {
- error = gpio_pin_setflags(sc->def->enable_pin, GPIO_PIN_OUTPUT);
- if (error != 0)
- return (error);
- }
-
- for (n = 0; n < sc->def->npins; n++) {
- error = gpio_pin_setflags(sc->def->pins[n], GPIO_PIN_OUTPUT);
- if (error != 0)
- return (error);
- }
-
- return (0);
-}
-
-static int
-gpioregulator_regnode_enable(struct regnode *regnode, bool enable, int *udelay)
-{
- struct gpioregulator_reg_sc *sc;
- bool active;
- int error;
-
- sc = regnode_get_softc(regnode);
-
- if (sc->def->enable_pin_valid == 1) {
- active = enable;
- if (!sc->param->enable_active_high)
- active = !active;
- error = gpio_pin_set_active(sc->def->enable_pin, active);
- if (error != 0)
- return (error);
- }
-
- *udelay = sc->def->startup_delay_us;
-
- return (0);
-}
-
-static int
-gpioregulator_regnode_set_voltage(struct regnode *regnode, int min_uvolt,
-int max_uvolt, int *udelay)
-{
- struct gpioregulator_reg_sc *sc;
- const struct gpioregulator_state *state;
- int error, n;
-
- sc = regnode_get_softc(regnode);
- state = NULL;
-
- for (n = 0; n < sc->def->nstates; n++) {
- if (sc->def->states[n].val >= min_uvolt &&
-
[PATCH rtems / rtems-libbsd] Updates for imx BSP
Hello, this two patch sets add fixes and improvements for the imx BSP: In RTEMS: - A small GPIO driver is added. It is used in the SPI driver to fix a wrong behaviour of the chip select lines that can't be fixed if the chip selects are controlled by the SPI controller instead of GPIOs. - The copy of the FDT is now cache aligned if a cache alignment is given for the CPU. In libbsd: - Some dead code is eliminated. - The imx GPIO driver is used instead of the ported FreeBSD one. Otherwise the FreeBSD driver will re-initialize the GPIOs. - Some caching problems are fixed. Both patch sets are intended for the master branches. In theory we could think about backporting them to 5 because some bugs are fixed. But I'm not sure whether the GPIO counts as a new feature or not. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 2/3] bsp/imx: Use GPIOs for SPI CS.
The chip select lines of the iMX SPI module doesn't work well for a
generic API like the one RTEMS uses. The existing solution only worked
in some special cases and had odd bugs when trying transfers of
different sizes (like deselecting between each byte for lengths that are
not dividable by 4).
With this patch the same approach like on FreeBSD or Linux is used:
Treat the CS lines as GPIOs.
---
bsps/arm/imx/spi/imx-ecspi.c | 92 +---
1 file changed, 85 insertions(+), 7 deletions(-)
diff --git a/bsps/arm/imx/spi/imx-ecspi.c b/bsps/arm/imx/spi/imx-ecspi.c
index a18047f2e0..26ba812f62 100644
--- a/bsps/arm/imx/spi/imx-ecspi.c
+++ b/bsps/arm/imx/spi/imx-ecspi.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
#include
#include
@@ -23,6 +24,8 @@
#include
#define IMX_ECSPI_FIFO_SIZE 64
+#define IMX_ECSPI_MAX_CHIPSELECTS 4
+#define IMX_ECSPI_CS_NONE IMX_ECSPI_MAX_CHIPSELECTS
typedef struct imx_ecspi_bus imx_ecspi_bus;
@@ -44,6 +47,10 @@ struct imx_ecspi_bus {
void (*pop)(imx_ecspi_bus *, volatile imx_ecspi *);
rtems_id task_id;
rtems_vector_number irq;
+ struct {
+struct imx_gpio_pin pin;
+bool valid;
+ } cspins[IMX_ECSPI_MAX_CHIPSELECTS];
};
static bool imx_ecspi_is_rx_fifo_not_empty(volatile imx_ecspi *regs)
@@ -129,6 +136,27 @@ static void imx_ecspi_push(imx_ecspi_bus *bus, volatile
imx_ecspi *regs)
}
}
+/* Call with IMX_ECSPI_CS_NONE for @a cs to set all to idle */
+static void
+imx_ecspi_set_chipsel(imx_ecspi_bus *bus, uint32_t cs)
+{
+ size_t i;
+
+ /* Currently this is fixed active low */
+ static const uint32_t idle = 1;
+ static const uint32_t select = 0;
+
+ for (i = 0; i < IMX_ECSPI_MAX_CHIPSELECTS; ++i) {
+if (bus->cspins[i].valid) {
+ if (i != cs) {
+imx_gpio_set_output(>cspins[i].pin, idle);
+ } else {
+imx_gpio_set_output(>cspins[cs].pin, select);
+ }
+}
+ }
+}
+
static uint32_t imx_ecspi_conreg_divider(imx_ecspi_bus *bus, uint32_t speed_hz)
{
uint32_t post;
@@ -286,6 +314,11 @@ static void imx_ecspi_next_msg(imx_ecspi_bus *bus,
volatile imx_ecspi *regs)
msg->cs
);
}
+if ((msg->mode & SPI_NO_CS) != 0) {
+ imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
+} else {
+ imx_ecspi_set_chipsel(bus, msg->cs);
+}
bus->todo = msg->len;
bus->rx_buf = msg->rx_buf;
@@ -323,6 +356,37 @@ static void imx_ecspi_interrupt(void *arg)
}
}
+static int imx_ecspi_check_messages(
+ imx_ecspi_bus *bus,
+ const spi_ioc_transfer *msg,
+ uint32_t size)
+{
+ while(size > 0) {
+if (msg->delay_usecs != 0) {
+ return -EINVAL;
+}
+if (msg->bits_per_word > 32) {
+ return -EINVAL;
+}
+if ((msg->mode &
+~(SPI_CPHA | SPI_CPOL | SPI_LOOP | SPI_NO_CS)) != 0) {
+ return -EINVAL;
+}
+if ((msg->mode & SPI_NO_CS) == 0 &&
+(msg->cs > IMX_ECSPI_MAX_CHIPSELECTS || !bus->cspins[msg->cs].valid)) {
+ return -EINVAL;
+}
+if (msg->cs_change != 0) {
+ return -EINVAL;
+}
+
+++msg;
+--size;
+ }
+
+ return 0;
+}
+
static int imx_ecspi_transfer(
spi_bus *base,
const spi_ioc_transfer *msgs,
@@ -330,16 +394,22 @@ static int imx_ecspi_transfer(
)
{
imx_ecspi_bus *bus;
+ int rv;
bus = (imx_ecspi_bus *) base;
- bus->msg_todo = n;
- bus->msg = [0];
- bus->task_id = rtems_task_self();
+ rv = imx_ecspi_check_messages(bus, msgs, n);
- imx_ecspi_next_msg(bus, bus->regs);
- rtems_event_transient_receive(RTEMS_WAIT, RTEMS_NO_TIMEOUT);
- return 0;
+ if (rv == 0) {
+bus->msg_todo = n;
+bus->msg = [0];
+bus->task_id = rtems_task_self();
+
+imx_ecspi_next_msg(bus, bus->regs);
+rtems_event_transient_receive(RTEMS_WAIT, RTEMS_NO_TIMEOUT);
+imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
+ }
+ return rv;
}
static void imx_ecspi_destroy(spi_bus *base)
@@ -356,6 +426,14 @@ static int imx_ecspi_init(imx_ecspi_bus *bus, const void
*fdt, int node)
rtems_status_code sc;
int len;
const uint32_t *val;
+ size_t i;
+
+ for (i = 0; i < IMX_ECSPI_MAX_CHIPSELECTS; ++i) {
+rtems_status_code sc_gpio = imx_gpio_init_from_fdt_property(
+>cspins[i].pin, node, "cs-gpios", IMX_GPIO_MODE_OUTPUT, i);
+bus->cspins[i].valid = (sc_gpio == RTEMS_SUCCESSFUL);
+ }
+ imx_ecspi_set_chipsel(bus, IMX_ECSPI_CS_NONE);
imx_ecspi_config(
bus,
@@ -436,7 +514,7 @@ int spi_bus_register_imx(const char *bus_path, const char
*alias_or_path)
}
bus->base.max_speed_hz = imx_ccm_ecspi_hz();
- bus->base.delay_usecs = 1;
+ bus->base.delay_usecs = 0;
bus->regs = imx_get_reg_of_node(fdt, node);
bus->irq = imx_get_irq_of_node(fdt, node, 0);
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 1/3] bsp/imx: Add a GPIO driver.
---
bsps/arm/imx/gpio/imx-gpio.c | 359 +++
bsps/arm/imx/headers.am | 1 +
bsps/arm/imx/include/bsp/imx-gpio.h | 196 +++
bsps/arm/imx/include/bsp/irq.h | 1 +
bsps/arm/imx/start/bspstart.c| 2 +-
bsps/include/bsp/fatal.h | 1 +
c/src/lib/libbsp/arm/imx/Makefile.am | 3 +
7 files changed, 562 insertions(+), 1 deletion(-)
create mode 100644 bsps/arm/imx/gpio/imx-gpio.c
create mode 100644 bsps/arm/imx/include/bsp/imx-gpio.h
diff --git a/bsps/arm/imx/gpio/imx-gpio.c b/bsps/arm/imx/gpio/imx-gpio.c
new file mode 100644
index 00..552e1d5cc2
--- /dev/null
+++ b/bsps/arm/imx/gpio/imx-gpio.c
@@ -0,0 +1,359 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019-2020 embedded brains GmbH.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IMX_GPIO_ALIAS_NAME "gpioX"
+
+/*
+ * i.MX6ULL has 5, i.MX7D has 7
+ *
+ * Be careful when changing this. The attach() does a simple ASCII conversion.
+ */
+#define IMX_MAX_GPIO_MODULES 7
+
+struct imx_gpio_regs {
+ uint32_t dr;
+ uint32_t gdir;
+ uint32_t psr;
+ uint32_t icr1;
+#define IMX_GPIO_ICR_LOW_LEVEL 0
+#define IMX_GPIO_ICR_HIGH_LEVEL 1
+#define IMX_GPIO_ICR_RISING_EDGE 2
+#define IMX_GPIO_ICR_FALLING_EDGE 3
+ uint32_t icr2;
+ uint32_t imr;
+ uint32_t isr;
+ uint32_t edge_sel;
+};
+
+struct imx_gpio {
+ char name[sizeof(IMX_GPIO_ALIAS_NAME)];
+ struct imx_gpio_regs *regs;
+ rtems_interrupt_lock lock;
+};
+
+/* The GPIO modules. These will be initialized based on the FDT alias table. */
+struct imx_gpio imx_gpio[IMX_MAX_GPIO_MODULES];
+
+const char *imx_gpio_get_name(struct imx_gpio *imx_gpio)
+{
+ return imx_gpio->name;
+}
+
+static void imx_gpio_attach(void)
+{
+ size_t i;
+ const void *fdt;
+
+ fdt = bsp_fdt_get();
+
+ memset(imx_gpio, 0, sizeof(imx_gpio));
+
+ for (i = 0; i < IMX_MAX_GPIO_MODULES; ++i) {
+const char *path;
+int node;
+const uint32_t *val;
+uint32_t gpio_regs = 0;
+int len;
+
+memcpy(imx_gpio[i].name, IMX_GPIO_ALIAS_NAME, sizeof(IMX_GPIO_ALIAS_NAME));
+imx_gpio[i].name[sizeof(IMX_GPIO_ALIAS_NAME)-2] = (char)('0' + i);
+
+path = fdt_get_alias(fdt, imx_gpio[i].name);
+if (path == NULL) {
+ continue;
+}
+
+node = fdt_path_offset(fdt, path);
+if (node < 0) {
+ bsp_fatal(IMX_FATAL_GPIO_UNEXPECTED_FDT);
+}
+
+val = fdt_getprop(fdt, node, "reg", );
+if (len > 0) {
+ gpio_regs = fdt32_to_cpu(val[0]);
+} else {
+ bsp_fatal(IMX_FATAL_GPIO_UNEXPECTED_FDT);
+}
+
+imx_gpio[i].regs = (struct imx_gpio_regs *)gpio_regs;
+rtems_interrupt_lock_initialize(_gpio[i].lock, imx_gpio[i].name);
+ }
+}
+
+struct imx_gpio *imx_gpio_get_by_index(unsigned idx)
+{
+ if ((idx < IMX_MAX_GPIO_MODULES) && (imx_gpio[idx].regs != NULL)) {
+return _gpio[idx];
+ }
+ return NULL;
+}
+
+struct imx_gpio *imx_gpio_get_by_register(void *regs)
+{
+ size_t i;
+
+ for (i = 0; i < IMX_MAX_GPIO_MODULES; ++i) {
+if (imx_gpio[i].regs == regs) {
+ return _gpio[i];
+}
+ }
+ return NULL;
+}
+
+static void imx_gpio_direction_input(struct imx_gpio_pin *pin)
+{
+ rtems_interrupt_lock_context lock_context;
+ rtems_interrupt_lock_acquire(>gpio->lock, _context);
+ pin->gpio->regs->gdir &= ~pin->mask;
+ rtems_interrupt_lock_release(>gpio->lock, _context);
+}
+
+static void imx_gpio_direction_output(struct imx_gpio_pin *pin)
+{
+ rtems_interrupt_lock_context lock_context;
+ rtems_interrupt_lock_acquire(>gpio->lock, _context);
+ pin->gpio->regs->gdir |= pin->mask;
+
[PATCH rtems 3/3] bsps/fdt: Make sure data is cache aligned.
The cache of the fdt blob is flushed after copy. Therefore it should be
aligned.
---
bsps/shared/start/bsp-fdt.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
index 7e8d8922a8..f55273e4ca 100644
--- a/bsps/shared/start/bsp-fdt.c
+++ b/bsps/shared/start/bsp-fdt.c
@@ -28,10 +28,10 @@
#endif
#ifdef BSP_FDT_BLOB_READ_ONLY
-static const uint32_t
+static const uint32_t CPU_STRUCTURE_ALIGNMENT
bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] = { 0xdeadbeef };
#else
-static uint32_t
+static uint32_t CPU_STRUCTURE_ALIGNMENT
bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)];
#endif
@@ -48,6 +48,7 @@ void bsp_fdt_copy(const void *src)
if (s != d) {
size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
+size_t aligned_size = ((m-1) | (CPU_CACHE_LINE_BYTES-1)) + 1;
size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
size_t i;
@@ -55,7 +56,7 @@ void bsp_fdt_copy(const void *src)
d[i] = s[i];
}
-rtems_cache_flush_multiple_data_lines(d, m);
+rtems_cache_flush_multiple_data_lines(d, aligned_size);
}
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] media-server: Add ability for retry.
Hello Gedare,
thanks for the review.
On 17/07/2020 07:43, Gedare Bloom wrote:
> On Thu, Jul 9, 2020 at 2:21 AM Christian Mauderer
> wrote:
>>
>> 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.
> delete one 'this'
>
> Glad you have this comment, that was my first thought when I read the
> commit msg.
>
>> */
>> 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, , 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, , 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);
> line length
>
> How do you use a retry counter? It's not obvious to me, but this is
> not an area I work with much.
>
The retry is only done if explicitly requested by the media listener.
The media listener is a software provided by the user. If the user
requests a retry he should also decide how often he wants to retry the
operation.
A possibility to add a retry counter is to use the user specifiable
argument of the media listener. The user can provide a pointer to some
own data structure where the retries are counted.
I think the retries in general are a quite exotic feature. Like my
comment suggests I used it to try a mount for an on-board memory, if it
doesn't work I format the disk and retry the mount.
Best regards
Christian
>>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
--
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
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
Re: [PATCH] media-server: Add ability for retry.
Ping.
On 09/07/2020 10:21, Christian Mauderer wrote:
> 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, , 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, , 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) {
>
--
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
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
Re: [PATCH] Changing pwm pinmux to use better register definitions
Hello James,
like said in the other Thread: I squashed it together with your first
patch and pushed it.
Thanks for the fix.
Best regards
Christian
On 13/07/2020 11:53, James Fitzsimons wrote:
> ---
> bsps/arm/beagle/pwm/pwm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/bsps/arm/beagle/pwm/pwm.c b/bsps/arm/beagle/pwm/pwm.c
> index 9a346995aa..81ace1254e 100644
> --- a/bsps/arm/beagle/pwm/pwm.c
> +++ b/bsps/arm/beagle/pwm/pwm.c
> @@ -102,9 +102,9 @@ bool beagle_pwm_pinmux_setup(bbb_pwm_pin_t pin_no,
> BBB_PWMSS pwm_id)
> } else if (pin_no == BBB_P8_36_1A) {
> REG(AM335X_PADCONF_BASE + BBB_CONTROL_CONF_LCD_DATA(10)) =
> BBB_MUXMODE(BBB_P8_36_MUX_PWM);
> } else if (pin_no == BBB_P9_14_1A) {
> - REG(AM335X_PADCONF_BASE + BBB_CONTROL_CONF_GPMC_AD(18)) =
> BBB_MUXMODE(BBB_P9_14_MUX_PWM);
> + REG(AM335X_PADCONF_BASE + AM335X_CONF_GPMC_A2) =
> BBB_MUXMODE(BBB_P9_14_MUX_PWM);
> } else if (pin_no == BBB_P9_16_1B) {
> - REG(AM335X_PADCONF_BASE + BBB_CONTROL_CONF_GPMC_AD(19)) =
> BBB_MUXMODE(BBB_P9_16_MUX_PWM);
> + REG(AM335X_PADCONF_BASE + AM335X_CONF_GPMC_A3) =
> BBB_MUXMODE(BBB_P9_16_MUX_PWM);
> } else {
> is_valid = false;
> }
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix for Beaglebone BSP PWM bug
On 13/07/2020 11:55, James Fitzsimons wrote:
> Hi Christian and Chris,
>
> On Sun, 12 Jul 2020 at 06:27, Christian Mauderer <mailto:o...@c-mauderer.de>> wrote:
>
> Hello Fitzsimons,
>
> sorry for the late review and thanks Chris for poking me.
>
> I have some troubles understanding the patch and the current code:
>
> == Regarding your patch:
>
> There is no pin GPMC_AD(18) or GPMC_AD(19). That offset will lead you to
> the pins GPMC_A8 and GPMC_A9. The correct macros to use would be
> AM335X_CONF_GPMC_A8 and AM335X_CONF_GPMC_A9. But that's only a style
> topic.
>
> What's a bit odd is that GPMC_A8 seems to be connected to the LED USR3
> on the BBB. Reasonable output for a PWM. But GPMC_A9 is a HDMI_INT,
> which seems a bit odd
>
>
> This is my fault for not really understanding the RTEMS header structure
> for the beaglebone bsp properly prior to now. I've dug into it a lot
> more over the last week or so while I've been working on implementing
> the eQEP driver and now have a much better understanding of how all the
> register definitions work.
>
> To be honest I found the following two macro definitions a bit
> unnecessary but thought I was doing the right thing by following the
> established pattern,
> /**
> * @brief BeagleBone Black PWM Macros.
> */
> #define BBB_CONTROL_CONF_GPMC_AD(n) (0x800 + (n * 4))
> #define BBB_CONTROL_CONF_LCD_DATA(n) (0x8a0 + (n * 4))
>
The BBB headers have grown a bit. It's a cheap platform and therefore it
has been used during quite some GSoC and entry level projects. With that
the files have been written by much more authors then most other BSPs.
The headers most likely would need some clean up to get a consistent
structure.
>
>
> == Regarding the old pins
>
> The old pins on the other hand (GPMC_AD2 and AD3) are connected to
> MMC1_DAT2 and 3 which is on P8 pin 5 and 6. That sounds a lot more
> reasonable. But the pins are definitively not what the pin_no suggests.
>
> == What (maybe) should be the correct one
>
> P9_14 and P9_16 are EHRPWM1A and EHRPWM1B on the beagle schematic. These
> are GPMC_AD8 and GPMC_AD9. These pins have a PWM function as an
> alternative function. So I would expect that you have to use these.
>
> It's really hard to find a documentation from TI for the pinmux but I
> found a list:
>
>
> https://git.ti.com/cgit/sitara-dss-files/am335x-dss-files/tree/padconf/am335x-pinmux.data
>
>
> A much better and easier to understand resource are the following two
> documents from Derek Molloy's Exploring Beaglebone website:
>
> http://exploringbeaglebone.com/wp-content/uploads/2019/01/533160-c06f008.png
> http://exploringbeaglebone.com/wp-content/uploads/2019/01/533160-c06f009.png
>
> As you can see from the P9 header sheet, the Address we want for
> EHRPWM1A on pin P9_14 is 0x848, and EHRPWM1B on pin P9_16 is 0x84c.
>
> It seems like all the register definitions in the am335x.h header in
> RTEMS are using the pin mode 1 name as the #define. So, for EHRPWM1A
> on pin P9_14 I should have used AM335X_CONF_GPMC_A2, and for EHRPWM1B
> on pin P9_16 I should have used AM335X_CONF_GPMC_A3.
> I have just made this change and tested it and it works as expected.
> I'll submit an updated patch for your review.
>
> Can you please double check the registers used in your patch
>
>
> BTW - the previous patch did actually calculate the correct register
> offset - I confirmed this both by printing the register value in a debug
> statement and by physically measuring a PWM output signal on the pins.
You are right. I'm not sure where I got my offset wrong. Of course it
should be GPMC_A2 and GPMC_A3.
Your new patch is on top of the first one (replaces ...AD(18) with
...A2). I'll squash both patches into one and push that one.
Best regards
Christian
>
> Cheers,
> James
>
>
> Best regards
>
> Christian
>
>
> On 05/07/2020 12:39, James Fitzsimons wrote:
> > ---
> > Fixed incorrect register offset values for EHRPWM1A on P9_14
> > and EHRPWM1B on P9_16
> >
> > bsps/arm/beagle/pwm/pwm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/bsps/arm/beagle/pwm/pwm.c b/bsps/arm/beagle/pwm/pwm.c
> > index 0bc5d125bf..9a346995aa 100644
> > --- a/bsps/arm/beagle/pwm/pwm.c
> > +++ b/bsps/arm/beagle/pwm/pwm.c
> > @@ -102,9 +102,9 @@ bool beagle_pwm_pinmux_setup(bbb_pwm_pin_t
> pin_no, BBB_PWMSS pwm_id)
> > } else if (pin_no == BBB_P8_36_1A) {
> >
Re: [PATCH] eng: fix typo in coding-file-hdr.rst
Pushed. Thanks. On 02/07/2020 23:19, G S Niteesh Babu wrote: > --- > eng/coding-file-hdr.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/eng/coding-file-hdr.rst b/eng/coding-file-hdr.rst > index 6355173..cda631a 100644 > --- a/eng/coding-file-hdr.rst > +++ b/eng/coding-file-hdr.rst > @@ -96,7 +96,7 @@ Use the following guidelines and template for C and C++ > header files (here > > .. code-block:: c > > -/* SPDX-License-Identifier: BSD-2-Clause > +/* SPDX-License-Identifier: BSD-2-Clause */ > > /** > * @file > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix for Beaglebone BSP PWM bug
Hello Fitzsimons,
sorry for the late review and thanks Chris for poking me.
I have some troubles understanding the patch and the current code:
== Regarding your patch:
There is no pin GPMC_AD(18) or GPMC_AD(19). That offset will lead you to
the pins GPMC_A8 and GPMC_A9. The correct macros to use would be
AM335X_CONF_GPMC_A8 and AM335X_CONF_GPMC_A9. But that's only a style topic.
What's a bit odd is that GPMC_A8 seems to be connected to the LED USR3
on the BBB. Reasonable output for a PWM. But GPMC_A9 is a HDMI_INT,
which seems a bit odd.
== Regarding the old pins
The old pins on the other hand (GPMC_AD2 and AD3) are connected to
MMC1_DAT2 and 3 which is on P8 pin 5 and 6. That sounds a lot more
reasonable. But the pins are definitively not what the pin_no suggests.
== What (maybe) should be the correct one
P9_14 and P9_16 are EHRPWM1A and EHRPWM1B on the beagle schematic. These
are GPMC_AD8 and GPMC_AD9. These pins have a PWM function as an
alternative function. So I would expect that you have to use these.
It's really hard to find a documentation from TI for the pinmux but I
found a list:
https://git.ti.com/cgit/sitara-dss-files/am335x-dss-files/tree/padconf/am335x-pinmux.data
Can you please double check the registers used in your patch?
Best regards
Christian
On 05/07/2020 12:39, James Fitzsimons wrote:
> ---
> Fixed incorrect register offset values for EHRPWM1A on P9_14
> and EHRPWM1B on P9_16
>
> bsps/arm/beagle/pwm/pwm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/bsps/arm/beagle/pwm/pwm.c b/bsps/arm/beagle/pwm/pwm.c
> index 0bc5d125bf..9a346995aa 100644
> --- a/bsps/arm/beagle/pwm/pwm.c
> +++ b/bsps/arm/beagle/pwm/pwm.c
> @@ -102,9 +102,9 @@ bool beagle_pwm_pinmux_setup(bbb_pwm_pin_t pin_no,
> BBB_PWMSS pwm_id)
> } else if (pin_no == BBB_P8_36_1A) {
> REG(AM335X_PADCONF_BASE + BBB_CONTROL_CONF_LCD_DATA(10)) =
> BBB_MUXMODE(BBB_P8_36_MUX_PWM);
> } else if (pin_no == BBB_P9_14_1A) {
> - REG(AM335X_PADCONF_BASE + BBB_CONTROL_CONF_GPMC_AD(2)) =
> BBB_MUXMODE(BBB_P9_14_MUX_PWM);
> + REG(AM335X_PADCONF_BASE + BBB_CONTROL_CONF_GPMC_AD(18)) =
> BBB_MUXMODE(BBB_P9_14_MUX_PWM);
> } else if (pin_no == BBB_P9_16_1B) {
> - REG(AM335X_PADCONF_BASE + BBB_CONTROL_CONF_GPMC_AD(3)) =
> BBB_MUXMODE(BBB_P9_16_MUX_PWM);
> + REG(AM335X_PADCONF_BASE + BBB_CONTROL_CONF_GPMC_AD(19)) =
> BBB_MUXMODE(BBB_P9_16_MUX_PWM);
> } else {
> is_valid = false;
> }
>
___
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.
On 09/07/2020 20:52, Vijay Kumar Banerjee wrote:
>
>
> On Fri, Jul 10, 2020, 12:11 AM Christian Mauderer <mailto:o...@c-mauderer.de>> 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
> > <mailto:christian.maude...@embedded-brains.de>> 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 = "
Re: [PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.
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] lvgl: Update to v7.1.0
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
[PATCH rtems-littlevgl] Allow to pass custom lv_conf.h and lv_drv_conf.h.
---
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
[PATCH] lvgl: Update to v7.1.0
--- 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
[PATCH] media-server: Add ability for retry.
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, , 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, , 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] bsps/beagle: Remove some debug output from I2C.
---
bsps/arm/beagle/i2c/bbb-i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/arm/beagle/i2c/bbb-i2c.c b/bsps/arm/beagle/i2c/bbb-i2c.c
index 664684b02f..b2a7cf814d 100644
--- a/bsps/arm/beagle/i2c/bbb-i2c.c
+++ b/bsps/arm/beagle/i2c/bbb-i2c.c
@@ -199,7 +199,7 @@ static int am335x_i2c_reset( bbb_i2c_bus *bus )
}
if ( timeout <= 0 ) {
-puts( "ERROR: Timeout in soft-reset\n" );
+debug_print( "ERROR: Timeout in soft-reset\n" );
return ETIMEDOUT;
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd
On 08/07/2020 10:29, Sebastian Huber wrote: > On 29/06/2020 21:39, Niteesh G. S. wrote: > >> Hello, >> >> I tried compiling RTEMS-libBSD with RTEMS6 toolchain and the new build >> system >> but failed. I get errors when compiling RTEMS-libBSD >> >> The new build system is pulled from Sebastian's branch >> HEAD: e4c193ddc163d6adb1b003254af9cc6b5d174a6f >> >> RTEMS was configured with the following options: >> 1) ./waf bsp_defaults --rtems-bsps=arm/beagleboneblack > config.ini >> 2) Enabled posix since libBSD complained about it during configuration. >> 3) ./waf configure --prefix=$HOME/development/rtems/6 >> 4) ./waf -j32 > > This didn't work for me. I got: > > [1391/1410] Linking > build/arm/beagleboneblack/testsuites/samples/iostream.exe > /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld: > ./librtemsbsp.a(bbb-i2c.c.1.o): in function `am335x_i2c_reset': > /home/EB/sebastian_h/src/rtems/build/arm/beagleboneblack/../../../bsps/arm/beagle/i2c/bbb-i2c.c:202: > undefined reference to `__wrap_puts' > collect2: error: ld returned 1 exit status > That's another problem: There is a puts in the bbb-i2c that maybe should be a printk instead. Haven't found the time yet to post a patch. I'll send one in a few minutes. > This error is related to this change: > > https://git.rtems.org/sebh/rtems.git/commit/?h=build=9e3a23e4dde96fca2fc5855995527e10a4a119cb > > > I guess I made this during the work to get rid of the bsp_specs. The > problem is that we have a cyclic reference: librtemstest depends on > librtemscpu which depends on librtemstest (via the wrapped output > functions). The librtemscpu and librtemsbsp are implicitly given at the > end via the -qrtems flag. I reverted the change since it seems to work > without it. Afterwards, I was able to install the BSP. > >> 5) ./waf install >> >> RTEMS-libBSD was configured with the following options: >> 1) ./waf configure --prefix=$HOME/development/rtems/6 >> --rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini >> --rtems-version=6 >> 2) ./waf -j16 >> I have attached the error log file. > > I got a different error: > > [1163/1163] Linking build/arm-rtems6-beagleboneblack-minimal/zerocopy01.exe > /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld: > testsuite/zerocopy01/test_main.c.96.o: in function `.LANCHOR0': > /home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../rtemsbsd/include/machine/rtems-bsd-config.h:238: > undefined reference to `_bsd_ip6_mroutemodule_sys_init' > > I fixed this with this commit: > > https://git.rtems.org/rtems-libbsd/commit/?h=5-freebsd-12=26866d2c1f2432b25b5db71995bce2035187c715 > > > Which branch do you use for libbsd? > > It seems the master branch. Here I get also your error: > > [1084/1184] Linking build/arm-rtems6-beagleboneblack-minimal/condvar01.exe > /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld: > ./libbsd.a(uipc_mbuf.c.16.o): in function `m_unmappedtouio': > /home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../freebsd/sys/kern/uipc_mbuf.c:1813: > undefined reference to `PHYS_TO_VM_PAGE' > /opt/rtems/6/lib/gcc/arm-rtems6/10.0.1/../../../../arm-rtems6/bin/ld: > /home/EB/sebastian_h/src/rtems-libbsd/build/arm-rtems6-beagleboneblack-minimal/../../freebsd/sys/kern/uipc_mbuf.c:1814: > undefined reference to `uiomove_fromphys' > > Could you please use the 5-freebsd-12 branch with the default build set. > This is what I use normally. > -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd
On 08/07/2020 08:35, Niteesh G. S. wrote: > On Wed, Jul 8, 2020 at 11:52 AM Christian Mauderer > <mailto:christian.maude...@embedded-brains.de>> wrote: > > On 08/07/2020 08:13, Sebastian Huber wrote: > > On 08/07/2020 08:10, Niteesh G. S. wrote: > > > >> On Tue, Jul 7, 2020 at 10:42 AM Sebastian Huber > >> <mailto:sebastian.hu...@embedded-brains.de> > >> <mailto:sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>>> wrote: > >> > >> Hello, > >> > >> the problem is that the new build system doesn't export > optimization > >> flags such as -Wl,--gc-sections. The libbsd build should > enable this > >> linker option unconditionally. > >> > >> > >> Thank you. I got it fixed (temporarily) by modifying rtems.py. > >> > >> conf.env.CFLAGS = cflags['cflags'] + ['-ffunction-sections'] + > >> ['-fdata-sections'] > > This instructs the compiler to add data elements and functions into > > separate sections. This is necessary so that the linker can carry out > > the garbage collection. > > There is an unused function in libbsd that can't link because a function > it calls isn't there. Till now the two flags had been provided by the > BSP. It seems that now they are not provided anymore. > > The problematic function is m_unmappedtouio in uipc_mbuf.c. It tries to > use PHYS_TO_VM_PAGE which isn't defined in libbsd. I think we should > just remove m_unmappedtouio (with #ifndef __rtems__) on the longer term. > But not having the -ffunction-sections and -fdata-sections most likely > makes our binary bigger and maybe leads to other similar bugs. Therefore > I suggested to add the CFLAGS first. > > >> > >> As per Christian suggestions, I tried exporting CFLAGS with these GCC > >> flags and then calling ./waf configure but they didn't work. > > You have to add -Wl,--gc-sections to the linker flags. > > As far as I know Niteesh used that one too. I think for that one LDFLAGS > worked as a workarround. > > > Yes, I did try exporting LDFLAGS too but they also didn't work out. > I tried the following: > 1) export LDFLAGS="-Wl,--gc-sections" > 2) ./waf configure --prefix=$RTEMS/6 --rtems-version=6 > --rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini > I also tried running > 1) LDFLAGS="-Wl,--gc-sections" ./waf configure --prefix=$RTEMS/6 > --rtems-version=6 --rtems-bsps=arm/beagleboneblack > --buildset=buildset/minimal.ini > Both of them didn't work out. Have the flags been ignored and not used or did that not fix the problem? I would assume the second. You should see the difference if you call "./waf -v" and take a look at one of the linker calls to generate the test applications. > > I might be wrong here but waf seems to add the "-Wl,--gc-sections" > flags if "--function-sections" flags are defined. > https://git.rtems.org/rtems_waf/tree/rtems.py#n389 > That's a bit odd. I don't think that I ever used that flag. But you are right: If CFLAGS contains the -function-section (only one -), "-Wl,--gc-sections" is added to the LDFLAGS here. > > > Best regards > > Christian > -- > > embedded brains GmbH > Herr Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de> > Phone: +49-89-18 94 741 - 18 > Fax: +49-89-18 94 741 - 08 > PGP: Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd
On 08/07/2020 08:13, Sebastian Huber wrote: > On 08/07/2020 08:10, Niteesh G. S. wrote: > >> On Tue, Jul 7, 2020 at 10:42 AM Sebastian Huber >> > <mailto:sebastian.hu...@embedded-brains.de>> wrote: >> >> Hello, >> >> the problem is that the new build system doesn't export optimization >> flags such as -Wl,--gc-sections. The libbsd build should enable this >> linker option unconditionally. >> >> >> Thank you. I got it fixed (temporarily) by modifying rtems.py. >> >> conf.env.CFLAGS = cflags['cflags'] + ['-ffunction-sections'] + >> ['-fdata-sections'] > This instructs the compiler to add data elements and functions into > separate sections. This is necessary so that the linker can carry out > the garbage collection. There is an unused function in libbsd that can't link because a function it calls isn't there. Till now the two flags had been provided by the BSP. It seems that now they are not provided anymore. The problematic function is m_unmappedtouio in uipc_mbuf.c. It tries to use PHYS_TO_VM_PAGE which isn't defined in libbsd. I think we should just remove m_unmappedtouio (with #ifndef __rtems__) on the longer term. But not having the -ffunction-sections and -fdata-sections most likely makes our binary bigger and maybe leads to other similar bugs. Therefore I suggested to add the CFLAGS first. >> >> As per Christian suggestions, I tried exporting CFLAGS with these GCC >> flags and then calling ./waf configure but they didn't work. > You have to add -Wl,--gc-sections to the linker flags. As far as I know Niteesh used that one too. I think for that one LDFLAGS worked as a workarround. Best regards Christian -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd
Hello Niteesh, I think there are multiple problems: 1. libbsd isn't adapted yet. There is a "rtems_version" in the wscript that you have to set to 6. 2. At least for me: There are some files not installed but should be there. To be exact: `$PREFIX/share/rtems6`. The files in this folder should be installed if INSTALL_LEGACY_MAKEFILES is set to True in the config.ini that is used for the new build system. But at least for my prefix something went wrong. I'll have to try to start with a clean build again tomorrow to see whether I maybe broke something. My prefix isn't in the best shape after trying multiple branches and installs. Best regards Christian On 06/07/2020 20:09, Niteesh G. S. wrote: > Hello all, > > This thread has lost activity for quite some time. > Can someone please provide a solution to this. This is blocking me from > testing my patches with libbsd. > > Thanks, > Niteesh. > > On Tue, Jun 30, 2020 at 1:12 AM Christian Mauderer <mailto:o...@c-mauderer.de>> wrote: > > Hello, > > On 29/06/2020 21:39, Niteesh G. S. wrote: > > Hello, > > > > I tried compiling RTEMS-libBSD with RTEMS6 toolchain and the new build > > system > > but failed. I get errors when compiling RTEMS-libBSD > > > > The new build system is pulled from Sebastian's branch > > HEAD: e4c193ddc163d6adb1b003254af9cc6b5d174a6f > > > > RTEMS was configured with the following options: > > 1) ./waf bsp_defaults --rtems-bsps=arm/beagleboneblack > config.ini > > 2) Enabled posix since libBSD complained about it during > configuration. > > 3) ./waf configure --prefix=$HOME/development/rtems/6 > > 4) ./waf -j32 > > 5) ./waf install > > > > RTEMS-libBSD was configured with the following options: > > 1) ./waf configure --prefix=$HOME/development/rtems/6 > > --rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini > > --rtems-version=6 > > 2) ./waf -j16 > > I have attached the error log file. > > > > Thanks, > > Niteesh > > > > > > I assume that for some reason the linker flags are not set correctly. It > seems that -ffunction-sections -fdata-sections isn't set. Sebastian: Is > there some adaption to libbsd necessary to work with the new build > system in RTEMS? > > Best regards > > Christian > > > ___ > 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
Beagle Board and -xM support
Hello, when answering some questions for Niteeshs GSoC project I noted that the beagleboardorig and beagleboardxm BSPs are really in no good shape. Since quite a long time only the beaglebone has been maintained. I think that only very basic stuff will work on the beagleboard if it works at all. Is someone interested in these BSPs? Has someone tried to run a recent RTEMS on one of these boards recently? At least the following drivers will not work for beagleboard: - I2C - GPIO - PWM - most likely SPI GPIO and PWM only implement stubs. I2C and SPI don't initialize the clock / pins or do it (most likely) wrong. I2C is partially my fault: I reworked that driver last year and printed an error for the beagleboards. The previous driver would most likely have done thrown an exception or would have done odd things because the clock initialization didn't take the beagleboard chip into account at all. Best regards Christian -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: NEW BUILD SYSTEM: Cannot build rtems-libbsd
Hello, On 29/06/2020 21:39, Niteesh G. S. wrote: > Hello, > > I tried compiling RTEMS-libBSD with RTEMS6 toolchain and the new build > system > but failed. I get errors when compiling RTEMS-libBSD > > The new build system is pulled from Sebastian's branch > HEAD: e4c193ddc163d6adb1b003254af9cc6b5d174a6f > > RTEMS was configured with the following options: > 1) ./waf bsp_defaults --rtems-bsps=arm/beagleboneblack > config.ini > 2) Enabled posix since libBSD complained about it during configuration. > 3) ./waf configure --prefix=$HOME/development/rtems/6 > 4) ./waf -j32 > 5) ./waf install > > RTEMS-libBSD was configured with the following options: > 1) ./waf configure --prefix=$HOME/development/rtems/6 > --rtems-bsps=arm/beagleboneblack --buildset=buildset/minimal.ini > --rtems-version=6 > 2) ./waf -j16 > I have attached the error log file. > > Thanks, > Niteesh > > I assume that for some reason the linker flags are not set correctly. It seems that -ffunction-sections -fdata-sections isn't set. Sebastian: Is there some adaption to libbsd necessary to work with the new build system in RTEMS? Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New Build System: Can't include headers
On 29/06/2020 19:39, Sebastian Huber wrote: > On 29/06/2020 17:13, Niteesh G. S. wrote: > >> 2) Is it possible to have two same files one in RTEMS and other in >> RTEMS-libBSD >> without collision? At least with different install paths? >> For eg: The openfirm.h in RTEMS under something like >> libfreebsd/dev/ofw/openfirm.h >> And the open in libBSD as it is done currently. >> So this way we can include the RTEMS variant with >> #include > Why can't we use your new stuff also in libbsd? We should avoid > duplication. Hello Sebastian, as far as possible, that is a good idea. For example for ti_cpuid.h: https://github.com/gs-niteesh/rtems/blob/397a3b5b961f852f47ade00dcae389c4b160c720/cpukit/libfreebsd/freebsd/sys/arm/ti/ti_cpuid.h That one should replace the one in libbsd. But I think that it will be hard to do that for some other headers. It will become tricky for everything that uses more complex interfaces like the openfirmware bus. Either we import a _lot_ of stuff from FreeBSD into RTEMS to get a libbsd compatible bus system. Or we have an incompatible system where the headers might differ. It's really hard to find a balance. In an earlier discussion (I think with Chris or Gedare) the direction for this new subsystem was to pull in only very few basic stuff so that we can use low-level drivers like pinmux or simple serial drivers. That also means that some of the software parts will be called very early. For example the Pinmux in BBB should be already set up before all other drivers are initialized. Therefore Niteesh added it as a SYSINIT during RTEMS_SYSINIT_BSP_PRE_DRIVERS. That means that multithreading isn't started yet which made trouble with some reentrant standard library functions. But these functions are sometimes used in FreeBSD code. I think that porting and integrating big (100% libbsd compatible) parts will be a huge effort. Therefore I suggested to keep the systems separate. Do you think importing bigger parts would be the better solution? Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] trace: Use c++14 instead of c++11 if possible
Ping.
Currently shouldn't be a matter for much hosts (less than 20 including
FreeBSD, Fedora, Arch, openSUSE according to distrowatch [1]) but I
assume that llvm 10 will spread fast.
[1]
http://distrowatch.org/search.php?pkg=llvm=greaterequal=10=InLatest#pkgsearch
On 08/06/2020 08:52, Christian Mauderer wrote:
> llvm version 10 uses features from c++14 standard in the headers. With
> that, the record/record-main-lttng.cc doesn't build any more. This patch
> makes sure that c++14 is used if it is available.
> ---
> trace/wscript | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/trace/wscript b/trace/wscript
> index 656f92b..53a1ab4 100644
> --- a/trace/wscript
> +++ b/trace/wscript
> @@ -45,6 +45,7 @@ def configure(conf):
> if conf.check(header_name='zlib.h', features='cxx', mandatory=False):
> conf.check_cxx(lib = 'z')
> conf.check_cxx(lib = 'ws2_32', mandatory=False)
> +conf.check_cxx(cxxflags='-std=c++14', mandatory=False,
> define_name="HAVE_STD_CXX14")
> conf.write_config_header('config.h')
>
> def build(bld):
> @@ -60,7 +61,10 @@ def build(bld):
> conf['warningflags'] = ['-Wall', '-Wextra', '-pedantic']
> conf['optflags'] = bld.env.C_OPTS
> conf['cflags'] = ['-pipe', '-g'] + conf['optflags']
> -conf['cxxflags'] = ['-std=c++11'] + conf['cflags']
> +cxxstd = '-std=c++11'
> +if bld.env.HAVE_STD_CXX14:
> +cxxstd = '-std=c++14'
> +conf['cxxflags'] = [cxxstd] + conf['cflags']
> conf['linkflags'] = ['-g']
> conf['lib'] = []
> if bld.env.LIB_WS2_32:
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
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: [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
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 4/5] libfreebsd: Port OFW to RTEMS
On 10/06/2020 17:11, Niteesh G. S. wrote:
> On Sat, Jun 6, 2020 at 5:40 PM Christian Mauderer <mailto:o...@c-mauderer.de>> wrote:
>
> On 04/06/2020 19:43, G S Niteesh Babu wrote:
> > The following files have been ported to RTEMS
> > 1) openfirm.h
> > 2) openfirm.c
> > 3) ofw_fdt.c
> > ---
> > cpukit/libfreebsd/dev/ofw/ofw_fdt.c | 117
> ++-
> > cpukit/libfreebsd/dev/ofw/openfirm.c | 59 +-
> > cpukit/libfreebsd/dev/ofw/openfirm.h | 18 +
> > 3 files changed, 191 insertions(+), 3 deletions(-)
> >
> > diff --git a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> > index e4f72e8142..5341440789 100644
> > --- a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> > +++ b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> > @@ -29,10 +29,13 @@
> > * SUCH DAMAGE.
> > */
> >
> > +#ifndef __rtems__
> > #include
> > __FBSDID("$FreeBSD$");
> > +#endif /* __rtems__ */
> >
> > #include
> > +#ifndef __rtems__
> > #include
> > #include
> > #include
> > @@ -45,9 +48,18 @@ __FBSDID("$FreeBSD$");
> > #include
> > #include
> > #include
> > +#endif /* __rtems__ */
> >
> > #include "ofw_if.h"
> > -
>
> I'm not really happy about lines starting with "-" in the porting
> commits. I think we should apply the same rules like in libbsd: Only add
> stuff. Exception: The one at the end of the file is OK (where git tells
> you "\ No newline at end of file"). You can't really avoid that.
>
>
> I fixed this.
>
>
>
> > +#ifdef __rtems__
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "openfirm.h"
> > +#endif /* __rtems__ */
> > +
> > +#ifndef __rtems__
> > #ifdef DEBUG
> > #define debugf(fmt, args...) do { printf("%s(): ", __func__);
> \
> > printf(fmt,##args); } while (0)
> > @@ -63,6 +75,7 @@ __FBSDID("$FreeBSD$");
> > #define FDT_MARVELL
> > #endif
> > #endif
> > +#endif /* __rtems__ */
> >
> > static int ofw_fdt_init(ofw_t, void *);
> > static phandle_t ofw_fdt_peer(ofw_t, phandle_t);
> > @@ -78,6 +91,7 @@ static ssize_t ofw_fdt_canon(ofw_t, const char
> *, char *, size_t);
> > static phandle_t ofw_fdt_finddevice(ofw_t, const char *);
> > static ssize_t ofw_fdt_instance_to_path(ofw_t, ihandle_t, char *,
> size_t);
> > static ssize_t ofw_fdt_package_to_path(ofw_t, phandle_t, char *,
> size_t);
> > +#ifndef __rtems__
> > static int ofw_fdt_interpret(ofw_t, const char *, int, cell_t *);
> >
> > static ofw_method_t ofw_fdt_methods[] = {
> > @@ -104,9 +118,11 @@ static ofw_def_t ofw_fdt = {
> > 0
> > };
> > OFW_DEF(ofw_fdt);
> > +#endif /* __rtems__ */
> >
> > static void *fdtp = NULL;
> >
> > +#ifndef __rtems__
> > static int
> > sysctl_handle_dtb(SYSCTL_HANDLER_ARGS)
> > {
> > @@ -127,6 +143,24 @@ sysctl_register_fdt_oid(void *arg)
> > sysctl_handle_dtb, "", "Device Tree Blob");
> > }
> > SYSINIT(dtb_oid, SI_SUB_KMEM, SI_ORDER_ANY,
> sysctl_register_fdt_oid, NULL);
> > +#else /* __rtems__ */
> > +const void* bsp_fdt_get(void);
> > +static void
> > +ofw_init(void)
> > +{
> > + int rv;
> > + const void *fdt;
> > +
> > + fdt = bsp_fdt_get();
> > + rv = ofw_fdt_init(NULL, fdt);
> > + assert(rv == 0);
>
> Is assert really the only error handling possible here? Asserts are
> allways a bit difficult because they stop the entire system. In which
> cases would it hit?
>
>
> The assert is reached when the FDT is not valid. The check is done
> using fdt_check_header. Shutting the system would be the only way
> right?
It's in a low level driver function and if it fails, there is most
likely much else to do. So OK.
> I agree to assert is not the right way to quit. Can we quit with
> a proper error code like BSP_FATAL_INVALID_FDT or do we have
> something like that already?
I don't know of an existing one.
Re: [PATCH 3/5] libfreebsd: FreeBSD porting helper header
On 10/06/2020 15:56, Niteesh G. S. wrote: > > On Sat, Jun 6, 2020 at 5:27 PM Christian Mauderer <mailto:cont...@c-mauderer.de>> wrote: > > On 04/06/2020 19:43, G S Niteesh Babu wrote: > > This file serve the purpose as rtems-bsd-kernel-space.h in the > > rtems-libbsd. > > This file is intended to be included in every source file that > > is to imported from FreeBSD. This is to reduce the number of > > redefinitions for commonly used functions like malloc, free > > and KASSERT. > > --- > > cpukit/libfreebsd/rtems-freebsd-helper.h | 45 > > > 1 file changed, 45 insertions(+) > > create mode 100644 cpukit/libfreebsd/rtems-freebsd-helper.h > > > > diff --git a/cpukit/libfreebsd/rtems-freebsd-helper.h > b/cpukit/libfreebsd/rtems-freebsd-helper.h > > How do you plan to include it? Currently you would need a > > #include "../../../rtems-freebsd-helper.h" > > right? Can become a bit hard to count the .. with a deep directory tree. > > > The right place for this file would be the standard include path. Since > we haven't decided > on this, I placed it temporarily here. > If we can add libfreebsd to the include path that will be really nice > because this will allow > us to have the same include path as in FreeBSD. > i.e. > The openfirm.h is included in FreeBSD sources as > #include > Including libfreebsd to include path will let us do the same. Hm. I'm not sure whether the current build system allows adding that to the include path. Definitively not for installed headers. If you see a simple way to add it: Do it. But don't put much effort into it (<30Minutes). It's not worth it. > > > > > new file mode 100644 > > index 00..1b9b7609f9 > > --- /dev/null > > +++ b/cpukit/libfreebsd/rtems-freebsd-helper.h > > @@ -0,0 +1,45 @@ > > + > > +/* SPDX-License-Identifier: BSD-2-Clause > > + > > + * > > + * @file > > + * > > + * @ingroup LIBFREEBSD > > You have a group LIBFREEBSD here. Earlier you had a LIBFREEBSDOFW. Do > you really want multiple groups? I would suggest to start with one for > the new libfreebsd subsystem. > > > I changed everything to LIBFREEBSD. OK > > > > > + * > > + * @brief > > + */ > > + > > +/* > > + * Copyright (C) <2020> Niteesh Babu <mailto:niteesh...@gmail.com>> > > + * > > + * Redistribution and use in source and binary forms, with or without > > + * modification, are permitted provided that the following conditions > > + * are met: > > + * 1. Redistributions of source code must retain the above copyright > > + * notice, this list of conditions and the following disclaimer. > > + * 2. Redistributions in binary form must reproduce the above > copyright > > + * notice, this list of conditions and the following > disclaimer in the > > + * documentation and/or other materials provided with the > distribution. > > + * > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND > CONTRIBUTORS "AS IS" > > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > LIMITED TO, THE > > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A > PARTICULAR PURPOSE > > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR > CONTRIBUTORS BE > > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, > EXEMPLARY, OR > > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, > PROCUREMENT OF > > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; > OR BUSINESS > > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, > WHETHER IN > > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR > OTHERWISE) > > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF > ADVISED OF THE > > + * POSSIBILITY OF SUCH DAMAGE. > > + */ > > + > > +#ifndef _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H > > +#define _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H > > + > > +#define _KERNEL 1 > > +#define KASSERT(cnd, msg) assert(cnd) > > +#define malloc(size, type, flags) malloc(size) > > +#define free(addr, type) free(addr) > > The tabs between the define
[PATCH rtems-tools] trace: Use c++14 instead of c++11 if possible
llvm version 10 uses features from c++14 standard in the headers. With
that, the record/record-main-lttng.cc doesn't build any more. This patch
makes sure that c++14 is used if it is available.
---
trace/wscript | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/trace/wscript b/trace/wscript
index 656f92b..53a1ab4 100644
--- a/trace/wscript
+++ b/trace/wscript
@@ -45,6 +45,7 @@ def configure(conf):
if conf.check(header_name='zlib.h', features='cxx', mandatory=False):
conf.check_cxx(lib = 'z')
conf.check_cxx(lib = 'ws2_32', mandatory=False)
+conf.check_cxx(cxxflags='-std=c++14', mandatory=False,
define_name="HAVE_STD_CXX14")
conf.write_config_header('config.h')
def build(bld):
@@ -60,7 +61,10 @@ def build(bld):
conf['warningflags'] = ['-Wall', '-Wextra', '-pedantic']
conf['optflags'] = bld.env.C_OPTS
conf['cflags'] = ['-pipe', '-g'] + conf['optflags']
-conf['cxxflags'] = ['-std=c++11'] + conf['cflags']
+cxxstd = '-std=c++11'
+if bld.env.HAVE_STD_CXX14:
+cxxstd = '-std=c++14'
+conf['cxxflags'] = [cxxstd] + conf['cflags']
conf['linkflags'] = ['-g']
conf['lib'] = []
if bld.env.LIB_WS2_32:
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 4/5] libfreebsd: Port OFW to RTEMS
On 04/06/2020 19:43, G S Niteesh Babu wrote:
> The following files have been ported to RTEMS
> 1) openfirm.h
> 2) openfirm.c
> 3) ofw_fdt.c
> ---
> cpukit/libfreebsd/dev/ofw/ofw_fdt.c | 117 ++-
> cpukit/libfreebsd/dev/ofw/openfirm.c | 59 +-
> cpukit/libfreebsd/dev/ofw/openfirm.h | 18 +
> 3 files changed, 191 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> index e4f72e8142..5341440789 100644
> --- a/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> +++ b/cpukit/libfreebsd/dev/ofw/ofw_fdt.c
> @@ -29,10 +29,13 @@
> * SUCH DAMAGE.
> */
>
> +#ifndef __rtems__
> #include
> __FBSDID("$FreeBSD$");
> +#endif /* __rtems__ */
>
> #include
> +#ifndef __rtems__
> #include
> #include
> #include
> @@ -45,9 +48,18 @@ __FBSDID("$FreeBSD$");
> #include
> #include
> #include
> +#endif /* __rtems__ */
>
> #include "ofw_if.h"
> -
I'm not really happy about lines starting with "-" in the porting
commits. I think we should apply the same rules like in libbsd: Only add
stuff. Exception: The one at the end of the file is OK (where git tells
you "\ No newline at end of file"). You can't really avoid that.
> +#ifdef __rtems__
> +#include
> +#include
> +#include
> +#include
> +#include "openfirm.h"
> +#endif /* __rtems__ */
> +
> +#ifndef __rtems__
> #ifdef DEBUG
> #define debugf(fmt, args...) do { printf("%s(): ", __func__);\
> printf(fmt,##args); } while (0)
> @@ -63,6 +75,7 @@ __FBSDID("$FreeBSD$");
> #define FDT_MARVELL
> #endif
> #endif
> +#endif /* __rtems__ */
>
> static int ofw_fdt_init(ofw_t, void *);
> static phandle_t ofw_fdt_peer(ofw_t, phandle_t);
> @@ -78,6 +91,7 @@ static ssize_t ofw_fdt_canon(ofw_t, const char *, char *,
> size_t);
> static phandle_t ofw_fdt_finddevice(ofw_t, const char *);
> static ssize_t ofw_fdt_instance_to_path(ofw_t, ihandle_t, char *, size_t);
> static ssize_t ofw_fdt_package_to_path(ofw_t, phandle_t, char *, size_t);
> +#ifndef __rtems__
> static int ofw_fdt_interpret(ofw_t, const char *, int, cell_t *);
>
> static ofw_method_t ofw_fdt_methods[] = {
> @@ -104,9 +118,11 @@ static ofw_def_t ofw_fdt = {
> 0
> };
> OFW_DEF(ofw_fdt);
> +#endif /* __rtems__ */
>
> static void *fdtp = NULL;
>
> +#ifndef __rtems__
> static int
> sysctl_handle_dtb(SYSCTL_HANDLER_ARGS)
> {
> @@ -127,6 +143,24 @@ sysctl_register_fdt_oid(void *arg)
> sysctl_handle_dtb, "", "Device Tree Blob");
> }
> SYSINIT(dtb_oid, SI_SUB_KMEM, SI_ORDER_ANY, sysctl_register_fdt_oid, NULL);
> +#else /* __rtems__ */
> +const void* bsp_fdt_get(void);
> +static void
> +ofw_init(void)
> +{
> + int rv;
> + const void *fdt;
> +
> + fdt = bsp_fdt_get();
> + rv = ofw_fdt_init(NULL, fdt);
> + assert(rv == 0);
Is assert really the only error handling possible here? Asserts are
allways a bit difficult because they stop the entire system. In which
cases would it hit?
> +}
> +RTEMS_SYSINIT_ITEM(
> + ofw_init,
> + RTEMS_SYSINIT_BSP_START,
> + RTEMS_SYSINIT_ORDER_FIRST
> +);
> +#endif /* __rtems__ */
>
> static int
> ofw_fdt_init(ofw_t ofw, void *data)
> @@ -297,7 +331,11 @@ ofw_fdt_getprop(ofw_t ofw, phandle_t package, const char
> *propname, void *buf,
> if (prop == NULL)
> return (-1);
>
> +#ifndef __rtems__
> bcopy(prop, buf, min(len, buflen));
> +#else /* __rtems__ */
> + memcpy(buf, prop, MIN(len, buflen));
> +#endif /* __rtems__ */
>
> return (len);
> }
> @@ -407,6 +445,7 @@ ofw_fdt_package_to_path(ofw_t ofw, phandle_t package,
> char *buf, size_t len)
> return (-1);
> }
>
> +#ifndef __rtems__
> #if defined(FDT_MARVELL)
> static int
> ofw_fdt_fixup(ofw_t ofw)
> @@ -476,4 +515,78 @@ ofw_fdt_interpret(ofw_t ofw, const char *cmd, int nret,
> cell_t *retvals)
> #else
> return (0);
> #endif
> -}
> \ No newline at end of file
> +}
> +#endif /* __rtems__ */
> +
> +#ifdef __rtems__
> +int OFW_INIT(ofw_t ofw_obj, void *cookie)
Again: Please use FreeBSD style. The return value should be on it's onw
line during the definition (not during declaration).
> +{
There should be one empty line if you have no local variables (I'm not
really consequent here too).
> + return ofw_fdt_init(ofw_obj, cookie);
And brackets around everything that is returned.
> +}
> +
> +phandle_t OFW_PEER(ofw_t ofw_obj, phandle_t node)
> +{
> + return ofw_fdt_peer(ofw_obj, node);
> +}
> +
> +phandle_t OFW_CHILD(ofw_t ofw_obj, phandle_t node)
> +{
> + return ofw_fdt_child(ofw_obj, node);
> +}
> +
> +phandle_t OFW_PARENT(ofw_t ofw_obj, phandle_t node)
> +{
> + return ofw_fdt_parent(ofw_obj, node);
> +}
> +
> +phandle_t OFW_INSTANCE_TO_PACKAGE(ofw_t ofw_obj, ihandle_t instance)
> +{
> + return ofw_fdt_instance_to_package(ofw_obj, instance);
> +}
> +
> +ssize_t OFW_GETPROPLEN(ofw_t ofw_obj, phandle_t package, const char
> *propname)
> +{
> + return
Re: [PATCH 3/5] libfreebsd: FreeBSD porting helper header
On 04/06/2020 19:43, G S Niteesh Babu wrote: > This file serve the purpose as rtems-bsd-kernel-space.h in the > rtems-libbsd. > This file is intended to be included in every source file that > is to imported from FreeBSD. This is to reduce the number of > redefinitions for commonly used functions like malloc, free > and KASSERT. > --- > cpukit/libfreebsd/rtems-freebsd-helper.h | 45 > 1 file changed, 45 insertions(+) > create mode 100644 cpukit/libfreebsd/rtems-freebsd-helper.h > > diff --git a/cpukit/libfreebsd/rtems-freebsd-helper.h > b/cpukit/libfreebsd/rtems-freebsd-helper.h How do you plan to include it? Currently you would need a #include "../../../rtems-freebsd-helper.h" right? Can become a bit hard to count the .. with a deep directory tree. > new file mode 100644 > index 00..1b9b7609f9 > --- /dev/null > +++ b/cpukit/libfreebsd/rtems-freebsd-helper.h > @@ -0,0 +1,45 @@ > + > +/* SPDX-License-Identifier: BSD-2-Clause > + > + * > + * @file > + * > + * @ingroup LIBFREEBSD You have a group LIBFREEBSD here. Earlier you had a LIBFREEBSDOFW. Do you really want multiple groups? I would suggest to start with one for the new libfreebsd subsystem. > + * > + * @brief > + */ > + > +/* > + * Copyright (C) <2020> Niteesh Babu > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS > IS" > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#ifndef _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H > +#define _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H > + > +#define _KERNEL 1 > +#define KASSERT(cnd, msg)assert(cnd) > +#define malloc(size, type, flags)malloc(size) > +#define free(addr, type) free(addr) The tabs between the define name and the value seem a bit random here. Please try to use FreeBSD style (I really hope I don't start a discussion now whether we should use RTEMS style instead for new files). https://www.freebsd.org/cgi/man.cgi?query=style=0=9 If it's not clear there: Take a look at some FreeBSD files. > + > +#endif /* _LIBFREEBSD_RTEMS_FREEBSD_HELPER_H */ > \ No newline at end of file > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/5] libfreebsd: Added ofw_if.h
Some style comments: On 04/06/2020 19:43, G S Niteesh Babu wrote: > This file is the RTEMS implementation of ofw_if.h in FreeBSD. The > ofw_if.h in FreeBSD is an autogenerated header file that maps the > OF_function calls to their respective implementation. But in RTEMS > this file maps the OF_functions directly to their FDT implementation. > --- > cpukit/libfreebsd/dev/ofw/ofw_if.h | 63 ++ > 1 file changed, 63 insertions(+) > create mode 100644 cpukit/libfreebsd/dev/ofw/ofw_if.h > > diff --git a/cpukit/libfreebsd/dev/ofw/ofw_if.h > b/cpukit/libfreebsd/dev/ofw/ofw_if.h > new file mode 100644 > index 00..7b9bcaa24a > --- /dev/null > +++ b/cpukit/libfreebsd/dev/ofw/ofw_if.h > @@ -0,0 +1,63 @@ > +/* SPDX-License-Identifier: BSD-2-Clause > + > + * > + * @file > + * > + * @ingroup LIBFREEBSDOFW > + * > + * @brief Declaration of OFW functions. > + */ > + > +/* > + * Copyright (C) <2020> Niteesh Babu > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS > IS" > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > + * POSSIBILITY OF SUCH DAMAGE. > + */ > + > +#ifndef _LIBFREEBSD_OFW_IF_H > +#define _LIBFREEBSD_OFW_IF_H > + > +#include > +#include "openfirm.h" > + > +typedef void*ofw_t; > + > +int OFW_INIT(ofw_t ofw_obj, void *cookie); > +phandle_t OFW_PEER(ofw_t ofw_obj, phandle_t node); > +phandle_t OFW_CHILD(ofw_t ofw_obj, phandle_t node); > +phandle_t OFW_PARENT(ofw_t ofw_obj, phandle_t node); > +phandle_t OFW_INSTANCE_TO_PACKAGE(ofw_t ofw_obj, ihandle_t instance); > +ssize_t OFW_GETPROPLEN(ofw_t ofw_obj, phandle_t package, const char > *propname); > +ssize_t OFW_GETPROP(ofw_t ofw_obj, phandle_t package, const char *propname, > +void *buf, size_t buflen); If we use FreeBSD Kernel style (which I would suggest for code that has to do with FreeBSD) you should indent the second line one tab more. Means ssize_t OFW_GETPROP(ofw_t ofw_obj, ..., void *buf, size_t buflen); That is: ssize_t OFW_GETPROP(ofw_t ofw_obj, ..., <1*tab><4*space>void *buf, size_t buflen); Take a look at some FreeBSD headers for that. For example rtems-libbsd/freebsd/sys/sys/rwlock.h. > +int OFW_NEXTPROP(ofw_t ofw_obj, phandle_t package, const char *prev, char > *buf, > +size_t size); > +int OFW_SETPROP(ofw_t ofw_obj, phandle_t package, const char *propname, > +const void *buf, size_t len); > +ssize_t OFW_CANON(ofw_t ofw_obj, const char *device, char *buf, size_t len); > +phandle_t OFW_FINDDEVICE(ofw_t ofw_obj, const char *device); > +ssize_t OFW_INSTANCE_TO_PATH(ofw_t ofw_obj, ihandle_t instance, char *buf, > +size_t len); > +ssize_t OFW_PACKAGE_TO_PATH(ofw_t ofw_obj, phandle_t package, char *buf, > +size_t len); > + > +#endif /* _LIBFREEBSD_OFW_IF_H */ > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LVGL applications with mouse
On 06/06/2020 13:09, Vijay Kumar Banerjee wrote: > On Fri, Jun 5, 2020 at 8:30 PM Christian Mauderer wrote: >> >> Hello Vijay, >> >> On 04/06/2020 21:36, Vijay Kumar Banerjee wrote: >>> Hi! >>> >>> I had been looking for an opportunity to do this for a long time and I'm >>> excited to post that LVGL apps on RTEMS can now use input devices >>> through the evdev interface! >> >> Sounds like a nice feature. >> >>> >>> I prepared some BSD evdev patches for lvgl repository and managed to get >>> them merged upstream. The patchset that I recently send to devel for >>> libbsd[1] and rtems-littlevgl[2], updates the rtems-libbsd and >>> rtems-littlevgl repository to adapt to the latest lvgl changes upstream >>> and adds the evdev support to rtems-littlevgl. >>> >>> I wrote an example lvgl application that uses the mouse, connected >>> through USB port of Beaglebone black. The example application uses the >>> RTEMS logo, which makes it a bit heavier patch for the devel. I have >>> posted the commit on my github fork [3] and would really appreciate it >>> if someone can review and approve it to merge upstream. >> >> Although most likely touch screens are more common in embedded systems, >> it's a good example. A lot of touchscreens should work via evdev too. >> > I couldn't work on the touchscreen due to the lack of hardware. The > intention is indeed to enable the use of a touchscreen or mouse > through evdev interface. > Can you please test if the touchscreen works on BBB with evdev01.exe > test in libbsd? If this works, I'll try to get the touchscreen model > that you have (most probably after the lockdown is over :) ) and will > integrate it into the same demo app. I would have to try first whether the touch is supported in FreeBSD. I'm not sure about that. But if you have tested one evdev device, another one should work too. You did test that the interface between libbsd and littelvgl works with the mouse. > >> Regarding the logo size: Also an RTEMS logo is a nice idea, maybe >> something smaller would be better to avoid that big file in the repo? >> Depending on how you generated the image: Maybe some run length encoding >> could reduce the size too (for example GIMP offers an option for that >> when exporting images to C sources). >> > Thanks for pointing this out. This indeed lowered the size by half. > I'm trying to get it working with lvgl and will post a patch to the > list once I get it done. Great. > >>> >>> Finally, please have a look at this very short video that shows the >>> example application running. It uses many features of lvgl, including >>> image, button, and input: >>> https://blog.thelunatic.dev/assets/video/lvgl_rtems_logo.mp4 >> >> Looks great. >> > Thanks. > > Best regards, > Vijay >> Best regards >> >> Christian >> >>> >>> We can now make full-fledged GUI applications with LVGL on RTEMS. :) >>> >>> [1]: https://lists.rtems.org/pipermail/devel/2020-June/060049.html >>> [2]: https://lists.rtems.org/pipermail/devel/2020-June/060050.html >>> [3]: >>> https://github.com/thelunatic/rtems-examples/commit/c526d3c06a69591dc36e62af32728c51012ea6c1 >>> >>> Thanks! >>> Vijay >>> >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >>> > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LVGL applications with mouse
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. 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). > > 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. 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-littlevgl 1/4] update lv_drivers submodule url
On 05/06/2020 12:13, Vijay Kumar Banerjee wrote: > On Fri, Jun 5, 2020 at 2:00 PM Christian Mauderer > wrote: >> >> >> On 04/06/2020 20:44, Vijay Kumar Banerjee wrote: >>> --- >>> .gitmodules | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/.gitmodules b/.gitmodules >>> index 5bf0006..69d2d5c 100644 >>> --- a/.gitmodules >>> +++ b/.gitmodules >>> @@ -1,6 +1,6 @@ >>> [submodule "lv_drivers"] >>> path = lv_drivers >>> - url = https://github.com/littlevgl/lv_drivers.git >>> + url = https://github.com/lvgl/lv_drivers.git >> >> The name of the project changed. Do the other submodules require an >> update too? >> > Hi, > > Yes, the lvgl submodule will require an update too. I'll add it to > this patch and send a v2. > > Thanks Great. Feel free to push as soon as you think that it is ready. >>> [submodule "lvgl"] >>> path = lvgl >>> url = https://github.com/littlevgl/lvgl.git >>> >> >> -- >> >> embedded brains GmbH >> Herr Christian Mauderer >> Dornierstr. 4 >> D-82178 Puchheim >> Germany >> email: christian.maude...@embedded-brains.de >> Phone: +49-89-18 94 741 - 18 >> Fax: +49-89-18 94 741 - 08 >> PGP: Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: [PATCH rtems-littlevgl 4/4] lv_drv_conf: Enable USE_BSD_EVDEV option
On 05/06/2020 12:29, Vijay Kumar Banerjee wrote: > On Fri, Jun 5, 2020 at 1:59 PM Christian Mauderer > wrote: >> >> Hello Vijay, >> >> On 04/06/2020 20:44, Vijay Kumar Banerjee wrote: >>> --- >>> lv_drv_conf.h | 6 +- >>> 1 file changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/lv_drv_conf.h b/lv_drv_conf.h >>> index 697ceaf..e8d2c40 100644 >>> --- a/lv_drv_conf.h >>> +++ b/lv_drv_conf.h >>> @@ -322,7 +322,11 @@ >>> # define USE_EVDEV 0 >>> #endif >>> >>> -#if USE_EVDEV >>> +#ifndef USE_BSD_EVDEV >>> +# define USE_BSD_EVDEV 1 >>> +#endif >> > Hi! > >> I haven't tested it and haven't had a detailed look. But first question >> that springs to my mind: Can we still use no evdev on targets without it >> with this change? Or becomes some evdev module for libbsd mandatory with >> it if you want to use lvgl? >> > With this change in the configuration, the evdev module will be > required to compile as it includes the evdev header files if this > option is set, just like in the case of fbdev. The build options still > remain same, so we can add --no-drivers and these files won't be > touched during the build. If it needs to be further broken down in > such a manner that the fbdev is required but not evdev, then I think > we can keep this option enabled and check it during waf configuration > if evdev is available. If not, we can skill building the evdev files. > > Do you think such checking would be necessary or would it be > sufficient to have the --no-drivers option? I'll work on it > accordingly if more options are required. First: --no-drivers should be enough for now. On the long term, I think we should slowly move to a better configurability. I'm not sure yet how that could look. The method that we use to build littlevgl is a bit limiting. The library has a quite fixed configuration (the lv_conf.h). For example if you want to use a different color depth than 16 bit, you have to adapt the build. If you want to use a different maximum resulution, you have to adapt the build. That's quite limiting. Either the settings in our repository match your requirements or you have to build the library yourself. It would be great if we could get a bit of more flexibility. Of course some of these points can't really be changed easily. It's just how littlevgl works. But it's the reason that I'm a bit careful when we add something that adds further restrictions. We maybe end up with a really nice build system that can build the library for exactly one demo application. The drivers part is a quite separate and less critical one. So --no-drivers should be OK for that. So feel free to go on with it. Best regards Christian > > Thanks for the review. > > Best regards, > Vijay >> Best regards >> >> Christian >> >>> + >>> +#if USE_EVDEV || USE_BSD_EVDEV >>> # define EVDEV_NAME "/dev/input/event0"/*You can use the >>> "evtest" Linux tool to get the list of devices and test them*/ >>> # define EVDEV_SWAP_AXES 0 /*Swap the x and y axes >>> of the touchscreen*/ >>> >>> >> >> -- >> >> embedded brains GmbH >> Herr Christian Mauderer >> Dornierstr. 4 >> D-82178 Puchheim >> Germany >> email: christian.maude...@embedded-brains.de >> Phone: +49-89-18 94 741 - 18 >> Fax: +49-89-18 94 741 - 08 >> PGP: Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: [PATCH rtems-littlevgl 1/4] update lv_drivers submodule url
On 04/06/2020 20:44, Vijay Kumar Banerjee wrote: > --- > .gitmodules | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/.gitmodules b/.gitmodules > index 5bf0006..69d2d5c 100644 > --- a/.gitmodules > +++ b/.gitmodules > @@ -1,6 +1,6 @@ > [submodule "lv_drivers"] > path = lv_drivers > - url = https://github.com/littlevgl/lv_drivers.git > + url = https://github.com/lvgl/lv_drivers.git The name of the project changed. Do the other submodules require an update too? > [submodule "lvgl"] > path = lvgl > url = https://github.com/littlevgl/lvgl.git > -- ---- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: [PATCH rtems-littlevgl 4/4] lv_drv_conf: Enable USE_BSD_EVDEV option
Hello Vijay, On 04/06/2020 20:44, Vijay Kumar Banerjee wrote: > --- > lv_drv_conf.h | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/lv_drv_conf.h b/lv_drv_conf.h > index 697ceaf..e8d2c40 100644 > --- a/lv_drv_conf.h > +++ b/lv_drv_conf.h > @@ -322,7 +322,11 @@ > # define USE_EVDEV 0 > #endif > > -#if USE_EVDEV > +#ifndef USE_BSD_EVDEV > +# define USE_BSD_EVDEV 1 > +#endif I haven't tested it and haven't had a detailed look. But first question that springs to my mind: Can we still use no evdev on targets without it with this change? Or becomes some evdev module for libbsd mandatory with it if you want to use lvgl? Best regards Christian > + > +#if USE_EVDEV || USE_BSD_EVDEV > # define EVDEV_NAME "/dev/input/event0"/*You can use the "evtest" > Linux tool to get the list of devices and test them*/ > # define EVDEV_SWAP_AXES 0 /*Swap the x and y axes of > the touchscreen*/ > > -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: GSoC: Porting OFW to RTEMS
Hello Niteesh, On 28/05/2020 17:08, Niteesh G. S. wrote: > Hello Christian, > > On Thu, May 28, 2020 at 8:12 PM Christian Mauderer > <mailto:christian.maude...@embedded-brains.de>> wrote: > > Hello Niteesh, > > On 28/05/2020 16:34, Niteesh G. S. wrote: > > > > > > On Wed, May 27, 2020 at 11:25 PM Christian Mauderer > mailto:o...@c-mauderer.de> > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote: > > > > On 27/05/2020 19:32, Niteesh G. S. wrote: > > > > > > > > > On Wed, May 27, 2020 at 12:04 AM Christian Mauderer > > mailto:o...@c-mauderer.de> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>> > > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>> wrote: > > > > > > Hello Niteesh, > > > > > > On 26/05/2020 19:56, Christian Mauderer wrote: > > > > Hello Niteesh, > > > > > > > > On 25/05/2020 11:20, Niteesh G. S. wrote: > > > >> Hello, > > > >> > > > >> I have completed the porting of the OFW code from FreeBSD > > to RTEMS. > > > >> I do acknowledge the fact that we haven't decided on the > > > directory for files > > > >> to be placed in. The previous conversation had > stopped quite a > > > while ago. > > > >> Christian suggested I work on the patch since that > would also > > > start the > > > >> conversation again and also refactoring the patch to the > > correct > > > directory > > > >> will not be much of work. > > > >> > > > >> cpukit/libfreebsd was suggested as one of the > directories to > > > place the > > > >> ported > > > >> FreeBSD files. It is suggested to place all the > source files > > > under this > > > >> directory. > > > >> Since this will make the sync part easier. But this > causes > > issues > > > when > > > >> porting > > > >> BSP dependent files. Since RTEMS currently doesn't allow > > files in > > > cpukit to > > > >> reference bsp headers. I faced a similar issue during my > > porting > > > process > > > >> also. > > > >> The OFW init function require bsp_fdt_get function to > get a > > > reference to > > > >> the fdt > > > >> blob. But I can't include the bsp/fdt.h header file > from a > > source > > > file > > > >> under cpukit. > > > >> We must decide the directory quickly because my > project will > > > import other > > > >> FreeBSD sources like the pinmux driver for beaglebone > into > > RTEMS. > > > > > > > > Do you have a suggestion for another directory? > > > > > > > > If cpukit makes problems (which it clearly does due to > the BSP > > > > dependencies) maybe something in bsps/shared? > > > > > > > >> > > > >> https://github.com/gs-niteesh/rtems/commits/ofw_branch > > > > > > > > For small patches it would be better to send them to > the list > > > using "git > > > > send-email". That allows to comment directly on the > patches. But > > > in this > > > > case using a repo is OK because especially the import is > > quite big. > > > > > > > > I'll add comments for small stuff directly on github. > I hope > > that > > > works ;-) > > > >
Re: GSoC: Porting OFW to RTEMS
Hello Niteesh, On 28/05/2020 16:34, Niteesh G. S. wrote: > > > On Wed, May 27, 2020 at 11:25 PM Christian Mauderer <mailto:o...@c-mauderer.de>> wrote: > > On 27/05/2020 19:32, Niteesh G. S. wrote: > > > > > > On Wed, May 27, 2020 at 12:04 AM Christian Mauderer > mailto:o...@c-mauderer.de> > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote: > > > > Hello Niteesh, > > > > On 26/05/2020 19:56, Christian Mauderer wrote: > > > Hello Niteesh, > > > > > > On 25/05/2020 11:20, Niteesh G. S. wrote: > > >> Hello, > > >> > > >> I have completed the porting of the OFW code from FreeBSD > to RTEMS. > > >> I do acknowledge the fact that we haven't decided on the > > directory for files > > >> to be placed in. The previous conversation had stopped quite a > > while ago. > > >> Christian suggested I work on the patch since that would also > > start the > > >> conversation again and also refactoring the patch to the > correct > > directory > > >> will not be much of work. > > >> > > >> cpukit/libfreebsd was suggested as one of the directories to > > place the > > >> ported > > >> FreeBSD files. It is suggested to place all the source files > > under this > > >> directory. > > >> Since this will make the sync part easier. But this causes > issues > > when > > >> porting > > >> BSP dependent files. Since RTEMS currently doesn't allow > files in > > cpukit to > > >> reference bsp headers. I faced a similar issue during my > porting > > process > > >> also. > > >> The OFW init function require bsp_fdt_get function to get a > > reference to > > >> the fdt > > >> blob. But I can't include the bsp/fdt.h header file from a > source > > file > > >> under cpukit. > > >> We must decide the directory quickly because my project will > > import other > > >> FreeBSD sources like the pinmux driver for beaglebone into > RTEMS. > > > > > > Do you have a suggestion for another directory? > > > > > > If cpukit makes problems (which it clearly does due to the BSP > > > dependencies) maybe something in bsps/shared? > > > > > >> > > >> https://github.com/gs-niteesh/rtems/commits/ofw_branch > > > > > > For small patches it would be better to send them to the list > > using "git > > > send-email". That allows to comment directly on the patches. But > > in this > > > case using a repo is OK because especially the import is > quite big. > > > > > > I'll add comments for small stuff directly on github. I hope > that > > works ;-) > > > > Finished adding comments for small stuff. Some bigger questions: > > > > - How do you plan to include ofw_if.h in some driver files? RTEMS > > currently puts every file that can be included with > into a path > > called "include". > > > > > > Will ofw_if.h be included in driver files? As far as I have > searched in the > > FreeBSD sources, other than the OFW implementation none of the driver > > files include this header. So this could be placed in the same > directory as > > the OFW sources and need not be added to the global include path. > > If there is a case where it is included in some driver please let > me know. > > > > And also all the references to this header in the OFW > implementations are > > relative so in future, if we add other implementations, having it > in the > > same > > directory would be the right choice. > > > > You are right. I didn't have a detailed enough look. The functions like > OFW_GETPROP (declared in ofw_if.h) are only used in openfirm.c. So that > location is OK. > > > > >
Re: GSoC: Porting OFW to RTEMS
On 27/05/2020 19:32, Niteesh G. S. wrote: > > > On Wed, May 27, 2020 at 12:04 AM Christian Mauderer <mailto:o...@c-mauderer.de>> wrote: > > Hello Niteesh, > > On 26/05/2020 19:56, Christian Mauderer wrote: > > Hello Niteesh, > > > > On 25/05/2020 11:20, Niteesh G. S. wrote: > >> Hello, > >> > >> I have completed the porting of the OFW code from FreeBSD to RTEMS. > >> I do acknowledge the fact that we haven't decided on the > directory for files > >> to be placed in. The previous conversation had stopped quite a > while ago. > >> Christian suggested I work on the patch since that would also > start the > >> conversation again and also refactoring the patch to the correct > directory > >> will not be much of work. > >> > >> cpukit/libfreebsd was suggested as one of the directories to > place the > >> ported > >> FreeBSD files. It is suggested to place all the source files > under this > >> directory. > >> Since this will make the sync part easier. But this causes issues > when > >> porting > >> BSP dependent files. Since RTEMS currently doesn't allow files in > cpukit to > >> reference bsp headers. I faced a similar issue during my porting > process > >> also. > >> The OFW init function require bsp_fdt_get function to get a > reference to > >> the fdt > >> blob. But I can't include the bsp/fdt.h header file from a source > file > >> under cpukit. > >> We must decide the directory quickly because my project will > import other > >> FreeBSD sources like the pinmux driver for beaglebone into RTEMS. > > > > Do you have a suggestion for another directory? > > > > If cpukit makes problems (which it clearly does due to the BSP > > dependencies) maybe something in bsps/shared? > > > >> > >> https://github.com/gs-niteesh/rtems/commits/ofw_branch > > > > For small patches it would be better to send them to the list > using "git > > send-email". That allows to comment directly on the patches. But > in this > > case using a repo is OK because especially the import is quite big. > > > > I'll add comments for small stuff directly on github. I hope that > works ;-) > > Finished adding comments for small stuff. Some bigger questions: > > - How do you plan to include ofw_if.h in some driver files? RTEMS > currently puts every file that can be included with into a path > called "include". > > > Will ofw_if.h be included in driver files? As far as I have searched in the > FreeBSD sources, other than the OFW implementation none of the driver > files include this header. So this could be placed in the same directory as > the OFW sources and need not be added to the global include path. > If there is a case where it is included in some driver please let me know. > > And also all the references to this header in the OFW implementations are > relative so in future, if we add other implementations, having it in the > same > directory would be the right choice. > You are right. I didn't have a detailed enough look. The functions like OFW_GETPROP (declared in ofw_if.h) are only used in openfirm.c. So that location is OK. > > > - You created quite some commits. I would suggest to merge all porting > commits so that you have one import commit, one port commit and maybe > one commit adding RTEMS specific files > > > I have squashed them into a single port commit. > > > > > - You have at least one completely hand written file (ofw_if.h). Maybe > we should think about whether that is located well in the same directory > as the imported code or whether a similar structure like used in libbsd > would be better. One tree for imported files and one for RTEMS specific > hand written ones. > > > Do we need a separate directory for RTEMS specific handwritten ones depends > on what we will be importing in the future? Since we intend only to > import mostly > driver related code I don't think there is a need for a separate > directory. I think > this way because I assuming we don't need any RTEMS specific file for > the drivers. > But if we plan to include some simple subsystem then having a separate > directory > will be nice. Things like that tend to grow. So even if we don't want
Re: GSoC: Porting OFW to RTEMS
Hello Niteesh, On 26/05/2020 19:56, Christian Mauderer wrote: > Hello Niteesh, > > On 25/05/2020 11:20, Niteesh G. S. wrote: >> Hello, >> >> I have completed the porting of the OFW code from FreeBSD to RTEMS. >> I do acknowledge the fact that we haven't decided on the directory for files >> to be placed in. The previous conversation had stopped quite a while ago. >> Christian suggested I work on the patch since that would also start the >> conversation again and also refactoring the patch to the correct directory >> will not be much of work. >> >> cpukit/libfreebsd was suggested as one of the directories to place the >> ported >> FreeBSD files. It is suggested to place all the source files under this >> directory. >> Since this will make the sync part easier. But this causes issues when >> porting >> BSP dependent files. Since RTEMS currently doesn't allow files in cpukit to >> reference bsp headers. I faced a similar issue during my porting process >> also. >> The OFW init function require bsp_fdt_get function to get a reference to >> the fdt >> blob. But I can't include the bsp/fdt.h header file from a source file >> under cpukit. >> We must decide the directory quickly because my project will import other >> FreeBSD sources like the pinmux driver for beaglebone into RTEMS. > > Do you have a suggestion for another directory? > > If cpukit makes problems (which it clearly does due to the BSP > dependencies) maybe something in bsps/shared? > >> >> https://github.com/gs-niteesh/rtems/commits/ofw_branch > > For small patches it would be better to send them to the list using "git > send-email". That allows to comment directly on the patches. But in this > case using a repo is OK because especially the import is quite big. > > I'll add comments for small stuff directly on github. I hope that works ;-) Finished adding comments for small stuff. Some bigger questions: - How do you plan to include ofw_if.h in some driver files? RTEMS currently puts every file that can be included with into a path called "include". - You created quite some commits. I would suggest to merge all porting commits so that you have one import commit, one port commit and maybe one commit adding RTEMS specific files. - You have at least one completely hand written file (ofw_if.h). Maybe we should think about whether that is located well in the same directory as the imported code or whether a similar structure like used in libbsd would be better. One tree for imported files and one for RTEMS specific hand written ones. Please see all comments as advises. Feel free to argue against any of them if you think different ;-) Best regards Christian > > Best regards > > Christian > >> Please have a look at the last 6 patches for the ported work. >> Below is a short summary of the patch. >> * The openfirm.h is the OF interface that will provided to the user. >> * The openfirm.c contains the function definition for openfirm.h. The >> functions >> call the respective OFW_* functions which are responsible for choosing >> the correct implementation for OF interface. >> * ofw_if.h is the replacement for ofw_if.h in FreeBSD. This is an auto >> generated >> header in FreeBSD which choose the correct OF implementation(ofw_fdt, >> ofw_std, >> ofw_32bit, ofw_real). In RTEMS we directly map to the FDT implementation as >> suggested by Sebastian. >> * ofw_fdt.c contains the fdt implementation of OF interface. >> >> Thanks, >> Niteesh. >> > ___ > 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: Porting OFW to RTEMS
Hello Niteesh, On 25/05/2020 11:20, Niteesh G. S. wrote: > Hello, > > I have completed the porting of the OFW code from FreeBSD to RTEMS. > I do acknowledge the fact that we haven't decided on the directory for files > to be placed in. The previous conversation had stopped quite a while ago. > Christian suggested I work on the patch since that would also start the > conversation again and also refactoring the patch to the correct directory > will not be much of work. > > cpukit/libfreebsd was suggested as one of the directories to place the > ported > FreeBSD files. It is suggested to place all the source files under this > directory. > Since this will make the sync part easier. But this causes issues when > porting > BSP dependent files. Since RTEMS currently doesn't allow files in cpukit to > reference bsp headers. I faced a similar issue during my porting process > also. > The OFW init function require bsp_fdt_get function to get a reference to > the fdt > blob. But I can't include the bsp/fdt.h header file from a source file > under cpukit. > We must decide the directory quickly because my project will import other > FreeBSD sources like the pinmux driver for beaglebone into RTEMS. Do you have a suggestion for another directory? If cpukit makes problems (which it clearly does due to the BSP dependencies) maybe something in bsps/shared? > > https://github.com/gs-niteesh/rtems/commits/ofw_branch For small patches it would be better to send them to the list using "git send-email". That allows to comment directly on the patches. But in this case using a repo is OK because especially the import is quite big. I'll add comments for small stuff directly on github. I hope that works ;-) Best regards Christian > Please have a look at the last 6 patches for the ported work. > Below is a short summary of the patch. > * The openfirm.h is the OF interface that will provided to the user. > * The openfirm.c contains the function definition for openfirm.h. The > functions > call the respective OFW_* functions which are responsible for choosing > the correct implementation for OF interface. > * ofw_if.h is the replacement for ofw_if.h in FreeBSD. This is an auto > generated > header in FreeBSD which choose the correct OF implementation(ofw_fdt, > ofw_std, > ofw_32bit, ofw_real). In RTEMS we directly map to the FDT implementation as > suggested by Sebastian. > * ofw_fdt.c contains the fdt implementation of OF interface. > > Thanks, > Niteesh. > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC: RTEMS directory for FreeBSD imports
On 13/05/2020 20:15, Niteesh G. S. wrote: > Hello, > > This mail is to regain attention for this topic and also to discuss a > few details > regarding the porting process. > > In the previous thread, Sebastian mentioned that we will be hard wiring > the OF > functions with the FDT implementation. For reasons please have a look at > previous thread. > https://lists.rtems.org/pipermail/devel/2020-May/059762.html > This will be achieved by inlining the functions in openfirm.h with functions > defined in ofw_fdt.c. This approach is valid for most functions but not all. > Since not all functions have a one to one mapping. > > For example, > The OF_peer can be directly mapped to ofw_fdt_peer. > But for OF_getencprop it calls ofw_fdt_getprop after few manipulations. > Inlining these functions doesn't seem like a good practice for me. > > One way to approach this would be to add the implementation for these > functions in > ofw_fdt.c but this would cause code redundancy if we plan to import > openfirm.c > in future since these functions are already defined in openfirm.c. Are the functions exact clones of the the ones in openfirm.c? In that case I would suggest to import openfirm.c and put #ifndef __rtems__ around everything you don't need. Eveni if it means that you only use 10% of the file. > > Another approach will be to import openfirm.c also and redefine the OFW_* > macro to directly call the respective functions. That sounds like a better aproach. > > I don't really know if there is any other better way to approach this. > Any suggestion on > how to proceed. > > Once this is resolved I will proceed with the porting even if we haven't > finalized the > directory since it is just a matter of moving files once we are finalized. > > If you think this is too early to start with coding for GSoC please > understand that my > university exams haven't been conducted yet. And due to the COVID > pandemic, the > dates are quite uncertain. But it is mostly expected to happen during > the coding period (july/aug) > and this would eat up quite a lot of time. So just to be one the safe > side I started > quite early. > > Thank, > Niteesh. > > On Mon, May 11, 2020 at 12:48 PM Christian Mauderer > <mailto:christian.maude...@embedded-brains.de>> wrote: > > On 11/05/2020 09:11, Chris Johns wrote: > > On 11/5/20 4:55 pm, Christian Mauderer wrote: > >> On 11/05/2020 06:57, Chris Johns wrote: > >>> > >>> > >>> On 11/5/20 2:03 pm, Niteesh G. S. wrote: > >>>> On Mon, May 11, 2020 at 4:34 AM Chris Johns <mailto:chr...@rtems.org> > >>>> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote: > >>>> > >>>> On 10/5/20 6:17 pm, Niteesh G. S. wrote: > >>>> > This thread is a continuation of "GSoC 2020: Implementation > >>>> of OFW > >>>> > functions". > >>>> > > >>>> > A summary of points discussed in that thread is given > below. > >>>> > > >>>> > Below is a short description of my GSoC project. For more > >>>> information please > >>>> > refer to the wiki. > >>>> > > >>>> https://devel.rtems.org/wiki/GSoC/2020/Beagle_FDT_initialization > >>>> > My GSoC project deals with refactoring the Beagle BSP > to add > >>>> support for FDT > >>>> > based initialization. As part of this process, I will > have to > >>>> import the > >>>> > pin mux driver > >>>> > into RTEMS which currently is present in libBSD. > >>>> > This would require having support for OFW functions > which are > >>>> currently > >>>> > not implemented > >>>> > in RTEMS. Some drivers(eg: imx_iomux.c) which require these > >>>> functions > >>>> > provide > >>>> > a local implementation using libFDT. > >>>> > >>>> I hope you do not mind if I wind back a couple of steps... > >>>> > >>>> OFW? Is this http://wiki.laptop.org/go/Open_Firmware? > >>>> How does OFW related to FDT? > >>>> > >>>> > &
Re: GSoC: RTEMS directory for FreeBSD imports
On 14/05/2020 18:59, Niteesh G. S. wrote: > On Thu, May 14, 2020 at 4:30 PM Christian Mauderer > <mailto:christian.maude...@embedded-brains.de>> wrote: > > On 13/05/2020 20:15, Niteesh G. S. wrote: > > Hello, > > > > This mail is to regain attention for this topic and also to discuss a > > few details > > regarding the porting process. > > > > In the previous thread, Sebastian mentioned that we will be hard > wiring > > the OF > > functions with the FDT implementation. For reasons please have a > look at > > previous thread. > > https://lists.rtems.org/pipermail/devel/2020-May/059762.html > > This will be achieved by inlining the functions in openfirm.h with > functions > > defined in ofw_fdt.c. This approach is valid for most functions > but not all. > > Since not all functions have a one to one mapping. > > > > For example, > > The OF_peer can be directly mapped to ofw_fdt_peer. > > But for OF_getencprop it calls ofw_fdt_getprop after few > manipulations. > > Inlining these functions doesn't seem like a good practice for me. > > > > One way to approach this would be to add the implementation for these > > functions in > > ofw_fdt.c but this would cause code redundancy if we plan to import > > openfirm.c > > in future since these functions are already defined in openfirm.c. > > Are the functions exact clones of the the ones in openfirm.c? In that > case I would suggest to import openfirm.c and put #ifndef __rtems__ > around everything you don't need. Eveni if it means that you only use > 10% of the file. > > > Yes, implementation of the mentioned > functions(OF_getencprop, OF_getencprop_alloc etc) > will be a copy of the ones in openfirm.c. > > > > > > Another approach will be to import openfirm.c also and redefine > the OFW_* > > macro to directly call the respective functions. > > That sounds like a better aproach. > > > We can also call the respective functions directly from the functions in > openfirm.c > instead of redefining the OFW_* macro. Which one do you prefer? I would suggest to use the method that is less invasive. For calling the functions directly you most likely have to do something like that: #ifndef __rtems__ OFW_DO_SOMETHING(x, y); #else /* __rtems__ */ direct_call_to_function(x, y); #endif If someone changes the OFW_DO_SOMETHING line and (for example) add another condition around it that will trigger a conflict on upgrade. If you add #ifdef __rtems__ #define OFW_DO_SOMETHING direct_call_to_function #endif that will apply fine on an upgrade. So I would use that one. > > I will wait for a couple for everyone to participate in the discussion > and then start > implementing it. > > > > > I don't really know if there is any other better way to approach this. > > Any suggestion on > > how to proceed. > > > > Once this is resolved I will proceed with the porting even if we > haven't > > finalized the > > directory since it is just a matter of moving files once we are > finalized. > > > > If you think this is too early to start with coding for GSoC please > > understand that my > > university exams haven't been conducted yet. And due to the COVID > > pandemic, the > > dates are quite uncertain. But it is mostly expected to happen during > > the coding period (july/aug) > > and this would eat up quite a lot of time. So just to be one the safe > > side I started > > quite early. > > > > Thank, > > Niteesh. > > > > On Mon, May 11, 2020 at 12:48 PM Christian Mauderer > > <mailto:christian.maude...@embedded-brains.de> > > <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>>> wrote: > > > > On 11/05/2020 09:11, Chris Johns wrote: > > > On 11/5/20 4:55 pm, Christian Mauderer wrote: > > >> On 11/05/2020 06:57, Chris Johns wrote: > > >>> > > >>> > > >>> On 11/5/20 2:03 pm, Niteesh G. S. wrote: > > >>>> On Mon, May 11, 2020 at 4:34 AM Chris Johns > mailto:chr...@rtems.org> > > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>> > > >>>> <mailto:chr...@rtems.org &l
Re: GSoC: RTEMS directory for FreeBSD imports
On 11/05/2020 09:11, Chris Johns wrote: > On 11/5/20 4:55 pm, Christian Mauderer wrote: >> On 11/05/2020 06:57, Chris Johns wrote: >>> >>> >>> On 11/5/20 2:03 pm, Niteesh G. S. wrote: >>>> On Mon, May 11, 2020 at 4:34 AM Chris Johns >>> <mailto:chr...@rtems.org>> wrote: >>>> >>>> On 10/5/20 6:17 pm, Niteesh G. S. wrote: >>>> > This thread is a continuation of "GSoC 2020: Implementation >>>> of OFW >>>> > functions". >>>> > >>>> > A summary of points discussed in that thread is given below. >>>> > >>>> > Below is a short description of my GSoC project. For more >>>> information please >>>> > refer to the wiki. >>>> > >>>> https://devel.rtems.org/wiki/GSoC/2020/Beagle_FDT_initialization >>>> > My GSoC project deals with refactoring the Beagle BSP to add >>>> support for FDT >>>> > based initialization. As part of this process, I will have to >>>> import the >>>> > pin mux driver >>>> > into RTEMS which currently is present in libBSD. >>>> > This would require having support for OFW functions which are >>>> currently >>>> > not implemented >>>> > in RTEMS. Some drivers(eg: imx_iomux.c) which require these >>>> functions >>>> > provide >>>> > a local implementation using libFDT. >>>> >>>> I hope you do not mind if I wind back a couple of steps... >>>> >>>> OFW? Is this http://wiki.laptop.org/go/Open_Firmware? >>>> How does OFW related to FDT? >>>> >>>> >>>> We are only interested in the device tree interface provided by the OF. >>>> Functions like OF_getprop, OF_parent, etc. >>>> >>> >>> Why not call libfdt functions? I am wondering what there is in FreeBSD >>> that is calling these functions? I am not questioning the need, it is a >>> case of not understanding the dependency. >> >> The use case for the OF_... and ofw_... functions is more or less a >> simple import from FreeBSD drivers. Beneath that there are some quite >> nice shortcuts in the OF_... and ofw_... functions that would have to be >> re-implemented in each driver (like ofw_bus_node_status_okay()). >> >> Some drivers already use hacked versions of the functions. For example: >> >> bsps/sparc64/shared/clock/ckinit.c >> bsps/arm/imx/start/imx_iomux.c >> >> A use case where the OF_... stuff would have been handy: >> >> For the imx pin initialization I would have loved to just use the >> fdt_pinctrl_configure_tree() from FreeBSD. But that one had a lot of >> OF_.. stuff. Therefore I had to reimplement that function in a >> imx_pinctrl_configure_children(). My implementation basically does >> exactly the same thing but uses fdt_... functions instead of the OF_... >> functions. > > Thanks. I think I understand. The scope seems to be the low level SoC > type initialisation. This makes sense. And maybe some low level drivers like serial or I2C. I don't think that we should go much further in complexity. Basically everything that is beyond getting the board up and running is more of a libbsd topic. > >>>> You discuss importing drivers from FreeBSD? Do you know which core >>>> FreeBSD pieces would need to also come over for the drivers listed >>>> below? >>>> >>>> >>>> We had discussed this in the previous thread. >>>> https://lists.rtems.org/pipermail/devel/2020-May/059765.html >>>> For OF_* functions we will only have to import the following files. >>>> 1) openfirm.h >>>> 2) ofw_fdt.c >>> >>> You say below some drivers are being imported from FreeBSD, it is these >>> I am asking about. >>> >>>> Is seamless integration with rtems-libbsd required or does it also >>>> include copies of the same code? >>>> >>>> I am sorry. I don't really understand what you are asking :(. >>> >>> I am asking if the changes effect rtems-libbsd? >> >> I think the first step will be copies. It depends a bit on how well the >> functions can be integrated into RTEMS (the "node" parameter maybe is a >> bit difficult) but I'm confident that the OF_..
Re: GSoC: RTEMS directory for FreeBSD imports
t;> > directories for eg >> > a device driver could be placed in its BSP directories than in a >> common >> > folder >> > along with other imports. But it should also be noted that the >> latter >> > makes it >> > difficult to sync and the former. >> >> Gedare covered these issues in the other thread in an excellent post >> [1] >> and I would like to reference that as I agree with it. >> >> When importing from such a large and complex code base like >> FreeBSD we >> need to be careful we do not pull on a thread and pull in large >> pieces >> of FreeBSD. >> >> Gedare's point about making sure all imported pieces are from the >> same >> version is important and I think a base requirement. >> >> I am OK with some code being in rtems.git if there is a clear use >> outside of rtems-libbsd. FDT support is one use, another is the NFS >> client code in FreeBSD being used with the legacy stack (there are >> BSPs >> with only legacy driver support still in use) and the existing >> client is >> only NFSv2. >> >> We need a place to collect the common base parts of FreeBSD that are >> shared by the various imported pieces. Isolated pieces could lead to >> repeated imports common pieces if we do not do this. >> >> I believe Sebastian said the new build system should handle the >> synchronisation? This is a good idea. Could it manage separated >> pieces? >> Could the build system read in all the sync pieces and logically join >> them based on the upstream source and operate on them as a group? >> This >> way we can have drivers in a BSP, NFS in libnfs (or where ever). >> >> >> I am not really familiar with the new build system. So can we please wait >> until Sebastian answers this. > > Sure. Although note that I suggested to see the discussion as a _preparation_ for that import. Doing the import right is quite a bit of work. It would change the target of Niteeshs GSoC project quite a lot. So we should make sure that a good location is selected and that the same rules like in libbsd are used. But I don't think that the actual script will be added in that project. Best regards Christian > > Chris > >> >> >> >> Chris >> >> [1] https://lists.rtems.org/pipermail/devel/2020-May/059807.html >> -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: GSoC 2020: Implementation of OFW functions
On 08/05/2020 23:05, Gedare Bloom wrote: > On Fri, May 8, 2020 at 9:34 AM Christian Mauderer wrote: >> >> >> On 08/05/2020 17:26, Niteesh G. S. wrote: >>> On Fri, May 8, 2020 at 11:43 AM Christian Mauderer >>> >> <mailto:christian.maude...@embedded-brains.de>> wrote: >>> >>> >>> On 07/05/2020 17:19, Niteesh G. S. wrote: >>> > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber >>> > >> <mailto:sebastian.hu...@embedded-brains.de> >>> > <mailto:sebastian.hu...@embedded-brains.de >>> <mailto:sebastian.hu...@embedded-brains.de>>> wrote: >>> > >>> > On 07/05/2020 12:28, Niteesh G. S. wrote: >>> > >>> > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber >>> > > >> <mailto:sebastian.hu...@embedded-brains.de> >>> > <mailto:sebastian.hu...@embedded-brains.de >>> <mailto:sebastian.hu...@embedded-brains.de>> >>> > > <mailto:sebastian.hu...@embedded-brains.de >>> <mailto:sebastian.hu...@embedded-brains.de> >>> > <mailto:sebastian.hu...@embedded-brains.de >>> <mailto:sebastian.hu...@embedded-brains.de>>>> wrote: >>> > > >>> > > On 07/05/2020 09:35, Niteesh G. S. wrote: >>> > > >>> > > > This is what I was trying to convey in one of the previous >>> > mails. >>> > > > >>> https://lists.rtems.org/pipermail/devel/2020-May/059717.html >>> > > > But in that mail, I was planning to replace KOBJLOOKUP. >>> > > > Should I start working on it? From the top of my mind, the >>> > > following has >>> > > > to be done. >>> > > > 1) Import openfirm.c openfirm.h, ofw_fdt.c >>> > > > 2) Add ofw_fdt.h since all the functions in ofw_fdt >>> are static. >>> > > > Should we also import ofw_if.h? Because that is where >>> OFW_* >>> > > functions >>> > > > are defined or just add a ofw_rtems_map.h which >>> redefines them, >>> > > instead >>> > > > of importing ofw_if.h? >>> > > >>> > > The KOBJ stuff in the OFW support enables FreeBSD to >>> have three >>> > > different implementations of the OFW API which can be >>> selected at >>> > > runtime: >>> > > >>> > > sys/powerpc/ofw/ofw_real.c >>> > > sys/dev/ofw/ofw_standard.c >>> > > sys/dev/ofw/ofw_fdt.c >>> > > >>> > > In libbsd this is already short cut to the FDT >>> implementation: >>> > > >>> > > #ifndef __rtems__ >>> > > static ofw_def_t*ofw_def_impl = NULL; >>> > > #else /* __rtems__ */ >>> > > #defineofw_def_impl (_fdt) >>> > > #endif /* __rtems__ */ >>> > > >>> > > To me this looks like the KOBJ stuff was just used to >>> enable some >>> > > sort >>> > > of object oriented programming. Do we need this >>> flexibility at >>> > > runtime >>> > > in RTEMS? I would say no. I would hard wire this to the FDT >>> > > implementation. If someone has a problem with it in the >>> > future, this >>> > > decision can be readdressed. >>> > > >>> > > >>> > > Ok. But what is the neatest way to hardwire this to the FDT >>> > > implementation? >>> > > One way as Christian mentioned would be to redefine OFW_* >>> functions to >>> > > call the functions in ofw_fdt.c directly. Is there any other >>> way? >>> > >>> > I would try to replace the function declarations in openfirm.h >>> with >>> > inline functions which call the ofw_fd
Re: GSoC 2020: Implementation of OFW functions
On 08/05/2020 17:26, Niteesh G. S. wrote: > On Fri, May 8, 2020 at 11:43 AM Christian Mauderer > <mailto:christian.maude...@embedded-brains.de>> wrote: > > > On 07/05/2020 17:19, Niteesh G. S. wrote: > > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber > > <mailto:sebastian.hu...@embedded-brains.de> > > <mailto:sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>>> wrote: > > > > On 07/05/2020 12:28, Niteesh G. S. wrote: > > > > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber > > > <mailto:sebastian.hu...@embedded-brains.de> > > <mailto:sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>> > > > <mailto:sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de> > > <mailto:sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>>>> wrote: > > > > > > On 07/05/2020 09:35, Niteesh G. S. wrote: > > > > > > > This is what I was trying to convey in one of the previous > > mails. > > > > > https://lists.rtems.org/pipermail/devel/2020-May/059717.html > > > > But in that mail, I was planning to replace KOBJLOOKUP. > > > > Should I start working on it? From the top of my mind, the > > > following has > > > > to be done. > > > > 1) Import openfirm.c openfirm.h, ofw_fdt.c > > > > 2) Add ofw_fdt.h since all the functions in ofw_fdt > are static. > > > > Should we also import ofw_if.h? Because that is where > OFW_* > > > functions > > > > are defined or just add a ofw_rtems_map.h which > redefines them, > > > instead > > > > of importing ofw_if.h? > > > > > > The KOBJ stuff in the OFW support enables FreeBSD to > have three > > > different implementations of the OFW API which can be > selected at > > > runtime: > > > > > > sys/powerpc/ofw/ofw_real.c > > > sys/dev/ofw/ofw_standard.c > > > sys/dev/ofw/ofw_fdt.c > > > > > > In libbsd this is already short cut to the FDT > implementation: > > > > > > #ifndef __rtems__ > > > static ofw_def_t *ofw_def_impl = NULL; > > > #else /* __rtems__ */ > > > #define ofw_def_impl (_fdt) > > > #endif /* __rtems__ */ > > > > > > To me this looks like the KOBJ stuff was just used to > enable some > > > sort > > > of object oriented programming. Do we need this > flexibility at > > > runtime > > > in RTEMS? I would say no. I would hard wire this to the FDT > > > implementation. If someone has a problem with it in the > > future, this > > > decision can be readdressed. > > > > > > > > > Ok. But what is the neatest way to hardwire this to the FDT > > > implementation? > > > One way as Christian mentioned would be to redefine OFW_* > functions to > > > call the functions in ofw_fdt.c directly. Is there any other > way? > > > > I would try to replace the function declarations in openfirm.h > with > > inline functions which call the ofw_fdt.c functions. > > > > > > Should I proceed with the above method? or should I wait for others > > to comment? > > If I can proceed, the following is what I will be doing. > > 1) import openfirm.h and ofw_fdt.c into RTEMS. > > 2) Add ofw_fdt.h with functions declarations for functions in > ofw_fdt.c > > 3) Add necessary compile-time guards. This would include using > __rtems__ > > preprocessor directive to avoid FreeBSD stuff and change the function > > definitions in ofw_fdt.c from static to non-static. > > Am I missing something? or is there any other way to do this? > > Maybe wait one or two more days for others to comment. For me the > direction sounds OK. > > You maybe can start thinking about where you want to import the > files to. > > > Since this has scope for future development. I think we should put it in a > separate directory under cpukit/include/ofw for header files and cpukit/ofw > for the source files. What do you think? > > If you plan to prepare a FreeBSD sync (regardless whether you implement it or someone else) another possibility could be to create a similar directory structure like in libbsd. Another directory could be ./cpukit/libmisc/rtems-fdt. But your suggestion is also possible. Maybe wait for some further input. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2020: Implementation of OFW functions
On 07/05/2020 17:19, Niteesh G. S. wrote: > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > > On 07/05/2020 12:28, Niteesh G. S. wrote: > > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber > > <mailto:sebastian.hu...@embedded-brains.de> > > <mailto:sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>>> wrote: > > > > On 07/05/2020 09:35, Niteesh G. S. wrote: > > > > > This is what I was trying to convey in one of the previous > mails. > > > https://lists.rtems.org/pipermail/devel/2020-May/059717.html > > > But in that mail, I was planning to replace KOBJLOOKUP. > > > Should I start working on it? From the top of my mind, the > > following has > > > to be done. > > > 1) Import openfirm.c openfirm.h, ofw_fdt.c > > > 2) Add ofw_fdt.h since all the functions in ofw_fdt are static. > > > Should we also import ofw_if.h? Because that is where OFW_* > > functions > > > are defined or just add a ofw_rtems_map.h which redefines them, > > instead > > > of importing ofw_if.h? > > > > The KOBJ stuff in the OFW support enables FreeBSD to have three > > different implementations of the OFW API which can be selected at > > runtime: > > > > sys/powerpc/ofw/ofw_real.c > > sys/dev/ofw/ofw_standard.c > > sys/dev/ofw/ofw_fdt.c > > > > In libbsd this is already short cut to the FDT implementation: > > > > #ifndef __rtems__ > > static ofw_def_t *ofw_def_impl = NULL; > > #else /* __rtems__ */ > > #define ofw_def_impl (_fdt) > > #endif /* __rtems__ */ > > > > To me this looks like the KOBJ stuff was just used to enable some > > sort > > of object oriented programming. Do we need this flexibility at > > runtime > > in RTEMS? I would say no. I would hard wire this to the FDT > > implementation. If someone has a problem with it in the > future, this > > decision can be readdressed. > > > > > > Ok. But what is the neatest way to hardwire this to the FDT > > implementation? > > One way as Christian mentioned would be to redefine OFW_* functions to > > call the functions in ofw_fdt.c directly. Is there any other way? > > I would try to replace the function declarations in openfirm.h with > inline functions which call the ofw_fdt.c functions. > > > Should I proceed with the above method? or should I wait for others > to comment? > If I can proceed, the following is what I will be doing. > 1) import openfirm.h and ofw_fdt.c into RTEMS. > 2) Add ofw_fdt.h with functions declarations for functions in ofw_fdt.c > 3) Add necessary compile-time guards. This would include using __rtems__ > preprocessor directive to avoid FreeBSD stuff and change the function > definitions in ofw_fdt.c from static to non-static. > Am I missing something? or is there any other way to do this? Maybe wait one or two more days for others to comment. For me the direction sounds OK. You maybe can start thinking about where you want to import the files to. -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: GSoC 2020: Implementation of OFW functions
Hello Niteesh, On 07/05/2020 06:58, Niteesh G. S. wrote: [...] > Is there any chance that we will be working with the new build system > for this GSoC project? I think there is a good chance that the new build system will be added soon. As far as I know, the current plan is to add it right after the release. Especially Chris did an awesome work regarding the release and there are only very few tickets left. Joel is also heavily involved in testing. So I expect the release any day now. > > I have a few doubts regarding the importing part. > > 1) Say we are importing the openfirm code to RTEMS(rtems.git) then we will > also have to bring in its dependencies like KOBJS which in turn has some > other > dependencies. And I am not really sure about this, but after looking at > the libbsd > code. This seems to bring in a huge amount of code into RTEMS. If this > is what > is going to happen then we could dump libbsd right? I don't think that dumping libbsd should be a short term goal and I'm not sure whether it can be a long term one. There is a lot more in libbsd than just the bus system. As a rough direction for now: libbsd was thought as a network and USB stack. So you could say that simple and low-level peripherals (like GPIO handling, serial ports, I2C, ...) are better in RTEMS and high-level stuff and complex peripherals (like a firewall, VPN, TCP/IP, network drivers, USB and SD drivers, ...) are better in libbsd. I'm also not sure whether importing KOBJS is the right way. The alternative would be to do the cut right there: Import the openfirm parts but replace the parts where KOBJS would be used. Maybe you can think about importing the ofw_fdt.c stuff too but add shortcuts. The KOBJS would just look up which ofw_fdt_... functions would be called. We currently don't have any other sources for this kind of information then the FDT. So you could just map for example OFW_GETPROP to the ofw_fdt_getprop function. That would remove the KOBJS dependency (which pulls in a lot of other stuff) but re-use a lot of the already well tested FreeBSD code. > > 2) If we didn't dump libbsd, won't this cause double initialization of > few things. That's a problem that should be addressed by your GSoC project. One reason for the suggested FDT based initialization was the situation that currently is there on the Beagle: Some pin functions are initialized by the RTEMS drivers with a hard coded value and then they are re-initialized by the libbsd pinmux driver based on the FDT. I think it would be optimal if RTEMS would do the initialization based on the FDT and libbsd would just skip that step. You maybe noted: Moving the pinmux stuff from libbsd to RTEMS could be another use case for a FreeBSD code import. Although I don't want to urge you into that direction if you don't want to do it (there are always other solutions) it might has some benefits. > You had already mentioned that libbsd uses some macro magic to avoid name > collisions that's why I am ignoring that and only worried about double > initialization. > -- -------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: GSoC 2020: Implementation of OFW functions
On 06/05/2020 11:31, Niteesh G. S. wrote: > On Wed, May 6, 2020 at 2:20 PM Christian Mauderer > <mailto:christian.maude...@embedded-brains.de>> wrote: > > Hello Niteesh, > > On 06/05/2020 10:42, Niteesh G. S. wrote: > > On Tue, May 5, 2020 at 11:46 PM Vijay Kumar Banerjee > mailto:vi...@rtems.org> > > <mailto:vi...@rtems.org <mailto:vi...@rtems.org>>> wrote: > > > > > > > > On Tue, May 5, 2020 at 10:40 PM Niteesh G. S. > mailto:niteesh...@gmail.com> > > <mailto:niteesh...@gmail.com <mailto:niteesh...@gmail.com>>> > wrote: > > > > This is thread is about implementing OFW functions in > RTEMS as part > > of my GSoC project. I would like to start off with this part > > since the refactoring > > work will somewhat depend on this. > > > > Implementing these functions into RTEMS will make porting > > drivers from > > FreeBSD to RTEMS easy. Currently, the drivers ported from > > freebsd implement > > the functions using libfdt variants but this causes a lot of > > code duplication. > > eg: bsps/arm/imx/start/imx_iomux.c > > > > My initial thoughts were to implement these functions one by > > one. But then > > Christian and Vijay mentioned about porting them from > libbsd. I went > > through the OFW code in libbsd and have described my porting > > process below. > > Please have a look at it and let me know if I have missed > > something or you > > would like to improve things. > > > > The following files will be ported from libbsd > > prefix = freebsd/sys/dev/ofw > > /openfirm.c > > /openfirm.h > > /ofw_fdt.c > > /ofwvar.h > > > > The main idea is to port openfirm.h but the other files > > are dependencies of openfirm.h > > > > Hi Niteesh, > > > > The initial plan of your project was to implement the whole FDT > > support on RTEMS, > > but there's already support through libbsd, so it might be a > better > > solution to port any > > remaining drivers from freebsd through libbsd and adapt the BSP > > drivers to use the > > freebsd FDT stack. This needs some discussion and input from other > > people to form > > the right plan and work accordingly. > > > > > > But this would require even the smallest example to link to > rtems-libbsd. > > Is it okay for this to happen? > > >From my point of view: No. It would mean that none of the RTEMS tests > could be build anymore. And I'm not sure whether it would be a good idea > for applications. There are use cases where you don't need a network > stack. > > But I'm not the only one with an opinion. So please wait for further > comments on that. > > > During the proposal period, Hesham also mentioned about this. I > think the > > comments are still there in the google docs. And also won't this cause > > the drivers > > to initialized only after initialization of libbsd? > > > > I think at least some basic drivers have to work before libbsd. For > example the console. > > Please also take a look at Sebastians suggestion. He mentioned that it > might could be an idea to import some FreeBSD stuff directly into RTEMS > with the new build system. > > > I am going through the new build system docs and code to understand how > this importing works. > https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf > https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf > > But some more guidance from Sebastian will be really helpful. Hello Niteesh, do you have some more specific questions? Do you search for a more general quick start guide? Or some specific topics? By the way: I'm new to the new build system too. But I have to learn it anyway so I'm happy to try to answer questions too. Best regards Christian > > > > > > After going through some open firmware documentation. I > guess as > > far as RTEMS is > > concerned we could avoid many functions like OF_init, > > OF_putchar,
Re: GSoC 2020: Implementation of OFW functions
. So it could mean that adding stuff to RTEMS means that it should be removed from libbsd. > > > To help you understand the structure of the libbsd: > * The files in freebsd/ directory are already ported to RTEMS. > * The freebsd-org/ is the git submodule that has the original source > of the freebsd. > * The rtemsbsd/ has the codes that we added to adapt the freebsd codes. > > The *_if.h files are generally automatically generated from the > *_if.m files. > The ofw_if.h has already been ported, you can find the generated header > file in rtemsbsd/include/rtems/bsd/local/ofw_if.h so there's no need > to do it > again. If future if there's a need to do it, we generally add a > recipe to build > the h files from the .m files in the Makefile.todo . You can have a > look at it > if you want, it's simple to follow. > > I had just spent a few hours going through the code. If I had > missed something > please let me know. > > You're in the right direction. We need to wait a bit to get some > input from > the community and progress accordingly. > > Best regards, > Vijay > > Thanks, > Niteesh. > -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: GSoC 2020: Implementation of OFW functions
On 06/05/2020 06:58, Sebastian Huber wrote: > Hello Niteesh, > > On 05/05/2020 19:10, Niteesh G. S. wrote: >> This is thread is about implementing OFW functions in RTEMS as part >> of my GSoC project. I would like to start off with this part since the >> refactoring >> work will somewhat depend on this. >> >> Implementing these functions into RTEMS will make porting drivers from >> FreeBSD to RTEMS easy. Currently, the drivers ported from freebsd >> implement >> the functions using libfdt variants but this causes a lot of code >> duplication. >> eg: bsps/arm/imx/start/imx_iomux.c > yes, what we have currently is a series of hacks and I am glad that we > have now the opportunity to fix this. >> >> My initial thoughts were to implement these functions one by one. But >> then >> Christian and Vijay mentioned about porting them from libbsd. I went >> through the OFW code in libbsd and have described my porting process >> below. >> Please have a look at it and let me know if I have missed something or >> you >> would like to improve things. >> >> The following files will be ported from libbsd >> prefix = freebsd/sys/dev/ofw >> /openfirm.c >> /openfirm.h >> /ofw_fdt.c >> /ofwvar.h >> >> The main idea is to port openfirm.h but the other files >> are dependencies of openfirm.h >> >> After going through some open firmware documentation. I guess as far >> as RTEMS is >> concerned we could avoid many functions like OF_init, OF_putchar, OF_test >> and only care about functions defined under openfirm.h:105-142 >> >> But these functions have dependency on the automatically generated >> ofw_if.h and KOBJS. >> But after a close inspection, I guess the KOBJSLOOKUP macro in >> ofw_if.h can be >> redefined or replaced for RTEMS. Since all it does is call the >> respective functions defined in ofw_fdt_methods(ofw_fdt.c). >> >> I had just spent a few hours going through the code. If I had missed >> something >> please let me know. > > This is a good analysis. > > I am not sure if it is a good idea to replace the KOBJS support. This > mechanism may be used in device drivers. I would try to make it optional. > > I am strongly opposed to reinvent the wheel in this area. If an existing > library with the right license fits our needs, then we should use and > improve it. FreeBSD has an active community and from my experience it is > easy to integrate changes. With the libbsd we have the ability to stay > in synchronization with the FreeBSD upstream. This is done through the > import/export script freebsd-to-rtems.py and a Git rebase in the FreeBSD > Git clone. If you want to include bigger chunks of code from FreeBSD in > RTEMS, then we should add this ability also to RTEMS. With the new build > system, this would be easy. We could add an attribute (for example > "synchronize-with: freebsd") to the objects items, e.g. > > https://git.rtems.org/sebh/rtems.git/tree/spec/build/cpukit/libjffs2.yml?h=build > > > A script could load the build items and pick up the ones with > synchronize-with == freebsd and then perform the import/export job. This > could be also used for other areas, e.g. JFFS2, the dtc, the libcrypto > stuff, etc. That could be a really nice functionality. Especially seeing that we already have quite some imported files. For example https://git.rtems.org/rtems/tree/bsps/arm/imx/start/imx_iomux.c -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: GSoC 2020: Implementation of OFW functions
On 06/05/2020 09:16, Niteesh G. S. wrote: > On Tue, May 5, 2020 at 11:44 PM Christian Mauderer <mailto:o...@c-mauderer.de>> wrote: > > Hello Niteesh, > > On 05/05/2020 19:10, Niteesh G. S. wrote: > > This is thread is about implementing OFW functions in RTEMS as part > > of my GSoC project. I would like to start off with this part since the > > refactoring > > work will somewhat depend on this. > > I'm not sure whether everyone on the list is already fully aware of what > your project is. For some of us the GSoC preparation phase is more of a > background noise. So maybe you want to give a short (only a few > sentences) overview of your target and what is the gain for the RTEMS > project. > > > I am sorry. I'll make sure that I do that from the next mail onwards. > No reason to be sorry. As soon as you introduced your project once - now that it officially starts - you can assume that everyone knows about it. I'm just not sure whether everyone watched the whole GSoC preparation mails. > > > > > > Implementing these functions into RTEMS will make porting drivers from > > FreeBSD to RTEMS easy. Currently, the drivers ported from freebsd > implement > > the functions using libfdt variants but this causes a lot of code > > duplication. > > eg: bsps/arm/imx/start/imx_iomux.c > > > > My initial thoughts were to implement these functions one by one. > But then > > Christian and Vijay mentioned about porting them from libbsd. > > Yes, there has been an offlist discussion whether the approach of a > reimplementing them is a good idea. > > Can you forward those mails if possible? Maybe I could gather some ideas > from it. No, because it hasn't been mails. And it have been only a few comments about the direction without any relevant content. But you just did everything necessary: Re-started a discussion whether that direction is OK. > > > > I went > > through the OFW code in libbsd and have described my porting > process below. > > If that can be ported, it would be a better approach then > reimplementing. > > > Please have a look at it and let me know if I have missed > something or you > > would like to improve things. > > > > The following files will be ported from libbsd > > prefix = freebsd/sys/dev/ofw > > /openfirm.c > > /openfirm.h > > /ofw_fdt.c > > /ofwvar.h > > > > The main idea is to port openfirm.h but the other files > are dependencies > > of openfirm.h > > > > After going through some open firmware documentation. I guess as > far as > > RTEMS is > > concerned we could avoid many functions like OF_init, OF_putchar, > OF_test > > and only care about functions defined under openfirm.h:105-142 > > OK. Note that these functions often have a "node". Think about what that > is and from where you would get it in an RTEMS driver. I think a lot of > FreeBSD drivers get it from their (logical) bus system like ofwbus. > > > Yes, the FreeBSD drivers do get their node handles from the buses. > One way(hackish) to accomplish this would be to create a dummy dev > structure which will be initialized during driver initialization. And > then the > drivers could query the node handles from it. But as mentioned this would > be hackish and I don't think will scale well. > > Another approach will be to import ofwbus itself, but then it would be a > huge > diversion from my current project. I don't mind working on this if this > is the > cleanest way to do it. But then we should also consider re-working on the > objectives. Let's just wait for some further comments on that. From my view importing ofwbus isn't really the best idea because it most likely has a lot of dependencies. And I'm really not sure whether we want all these during system start. > > > > > But these functions have dependency on the automatically generated > > ofw_if.h and KOBJS. > > But after a close inspection, I guess the KOBJSLOOKUP macro in > ofw_if.h > > can be > > redefined or replaced for RTEMS. Since all it does is call the > > respective functions defined in ofw_fdt_methods(ofw_fdt.c). > > Note that the automatically generated interface is used for the FreeBSD > device driver structure (or rather the bus interface). If you port the > stuff to RTEMS you should think about whether > > > > a) it should replace the libbsd stu
Re: GSoC 2020: Implementation of OFW functions
Hello Niteesh, On 05/05/2020 19:10, Niteesh G. S. wrote: > This is thread is about implementing OFW functions in RTEMS as part > of my GSoC project. I would like to start off with this part since the > refactoring > work will somewhat depend on this. I'm not sure whether everyone on the list is already fully aware of what your project is. For some of us the GSoC preparation phase is more of a background noise. So maybe you want to give a short (only a few sentences) overview of your target and what is the gain for the RTEMS project. > > Implementing these functions into RTEMS will make porting drivers from > FreeBSD to RTEMS easy. Currently, the drivers ported from freebsd implement > the functions using libfdt variants but this causes a lot of code > duplication. > eg: bsps/arm/imx/start/imx_iomux.c > > My initial thoughts were to implement these functions one by one. But then > Christian and Vijay mentioned about porting them from libbsd. Yes, there has been an offlist discussion whether the approach of a reimplementing them is a good idea. > I went > through the OFW code in libbsd and have described my porting process below. If that can be ported, it would be a better approach then reimplementing. > Please have a look at it and let me know if I have missed something or you > would like to improve things. > > The following files will be ported from libbsd > prefix = freebsd/sys/dev/ofw > /openfirm.c > /openfirm.h > /ofw_fdt.c > /ofwvar.h > > The main idea is to port openfirm.h but the other files are dependencies > of openfirm.h > > After going through some open firmware documentation. I guess as far as > RTEMS is > concerned we could avoid many functions like OF_init, OF_putchar, OF_test > and only care about functions defined under openfirm.h:105-142 OK. Note that these functions often have a "node". Think about what that is and from where you would get it in an RTEMS driver. I think a lot of FreeBSD drivers get it from their (logical) bus system like ofwbus. > > But these functions have dependency on the automatically generated > ofw_if.h and KOBJS. > But after a close inspection, I guess the KOBJSLOOKUP macro in ofw_if.h > can be > redefined or replaced for RTEMS. Since all it does is call the > respective functions defined in ofw_fdt_methods(ofw_fdt.c). Note that the automatically generated interface is used for the FreeBSD device driver structure (or rather the bus interface). If you port the stuff to RTEMS you should think about whether a) it should replace the libbsd stuff. In that case: What changes would be necessary to libbsd. b) or whether it should live side by side. > > I had just spent a few hours going through the code. If I had missed > something > please let me know. > > Thanks, > Niteesh. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: fdt_rw.c: Unchecked return value (CID #1047324) (#3947)
On 21/04/2020 11:57, Utkarsh Rai wrote: > As is suggested in the ticket <https://devel.rtems.org/ticket/3947> I > checked for return value checking in the upstream and it is not present. > Should I send a patch that checks for the error value (FDT_END)? > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > Hello Utkarsh, libfdt is an imported package. Therefore it might would be a good idea to take a look at the upstream code whether it has been fixed and pull in that fix (assuming it still has a compatible license). If it isn't fixed upstream: Feel free to send patches that improve the code base. Again a special case: Maybe think about sending the same patch to the upstream sources if the problem still exists there. Best regards Christian -- ---- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: [PATCH rtems-libbsd] imx6_usbphy: Fix regulator (vbus-supply)
On 17/04/2020 19:27, Gedare Bloom wrote:
> push after testing, thanks
Thanks. I tested and pushed it.
>
> On Fri, Apr 17, 2020 at 7:08 AM Christian Mauderer
> wrote:
>>
>> Update #3869.
>> ---
>> freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
>> b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
>> index 7df2e124..508e49c8 100644
>> --- a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
>> +++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
>> @@ -134,7 +134,7 @@ usbphy_attach(device_t dev)
>> #ifdef __rtems__
>> node = ofw_bus_get_node(dev);
>> if (OF_hasprop(node, "vbus-supply")) {
>> - rv = regulator_get_by_ofw_property(sc->dev, 0, "vbus-supply",
>> + rv = regulator_get_by_ofw_property(sc->dev, node,
>> "vbus-supply",
>> >supply_vbus);
>> if (rv != 0) {
>> device_printf(sc->dev,
>> --
>> 2.16.4
>>
>> _______
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
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
Re: [PATCH rtems v2] bsps/arm: Fix uninitialized value in generic timer
On 17/04/2020 19:34, Gedare Bloom wrote: > OK I would prefer to have it close a ticket on 5.1 that addresses the > fact it was a latent bug. I'm not sure how to feel about having > commits made prior to cutting a release, that update tickets for > milestones after the release. I suppose it is just a minor annoyance > to me. I created a separate ticket, closed that ticket with the commit and pushed it. Best regards Christian > > On Fri, Apr 17, 2020 at 12:35 AM Christian Mauderer > wrote: >> >> Hello Gedare, >> >> On 16/04/2020 21:16, Gedare Bloom wrote: >>> You can push this to 5.1, update the ticket milestone if you do. >> >> Thanks. In that case I most likely should create an extra ticket. I'm >> not sure whether Sebastian sees that one as close enough to finished to >> be a 5.1 ticket. For me it was a fix for the feature in progress and >> therefore I updated that ticket. >> >> Best regards >> >> Christian >> >>> >>> On Thu, Apr 16, 2020 at 9:27 AM Sebastian Huber >>> wrote: >>>> >>>> On 16/04/2020 15:29, Christian Mauderer wrote: >>>>> _CPU_Counter_frequency() can be called by the rtems_counter >>>>> initialization before arm_gt_clock_initialize() initializes the value >>>>> used in _CPU_Counter_frequency(). >>>>> >>>>> Update #3456. >>>> Thanks, looks good. >>>> ___ >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel >> >> -- >> >> embedded brains GmbH >> Herr Christian Mauderer >> Dornierstr. 4 >> D-82178 Puchheim >> Germany >> email: christian.maude...@embedded-brains.de >> Phone: +49-89-18 94 741 - 18 >> Fax: +49-89-18 94 741 - 08 >> PGP: Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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 rtems-libbsd] imx6_usbphy: Fix regulator (vbus-supply)
Update #3869.
---
freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
index 7df2e124..508e49c8 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
@@ -134,7 +134,7 @@ usbphy_attach(device_t dev)
#ifdef __rtems__
node = ofw_bus_get_node(dev);
if (OF_hasprop(node, "vbus-supply")) {
- rv = regulator_get_by_ofw_property(sc->dev, 0, "vbus-supply",
+ rv = regulator_get_by_ofw_property(sc->dev, node, "vbus-supply",
>supply_vbus);
if (rv != 0) {
device_printf(sc->dev,
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd v2] regulator: Disable FDT parts for non-FDT targets
On 17/04/2020 15:04, jan.som...@dlr.de wrote: > I can confirm, that the current 5-freebsd-12 branch builds now for pc686-BSP. > Thanks. Thanks for testing and sorry for introducing these bugs. It seems I had very bad luck with this patch set. It already broke two builds and I just found another bug that only affects my special board configuration but still needs a fix commit. I'll send that to the list soon but I definitively will not push that fix commit before re-testing it on Monday... Best Regards Christian > >> -Original Message- >> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Christian >> Mauderer >> Sent: Friday, April 17, 2020 2:49 PM >> To: Sebastian Huber; devel@rtems.org >> Subject: Re: [PATCH rtems-libbsd v2] regulator: Disable FDT parts for non-FDT >> targets >> >> On 17/04/2020 14:42, Sebastian Huber wrote: >>> Please push it, if it fixes the build. >>> >> >> Thanks. Pushed. >> >> -- >> >> embedded brains GmbH >> Herr Christian Mauderer >> Dornierstr. 4 >> D-82178 Puchheim >> Germany >> email: christian.maude...@embedded-brains.de >> Phone: +49-89-18 94 741 - 18 >> Fax: +49-89-18 94 741 - 08 >> 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 -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: [PATCH rtems-libbsd v2] regulator: Disable FDT parts for non-FDT targets
On 17/04/2020 14:42, Sebastian Huber wrote: > Please push it, if it fixes the build. > Thanks. Pushed. -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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 rtems-libbsd v2] regulator: Disable FDT parts for non-FDT targets
---
freebsd/sys/dev/extres/regulator/regulator.c | 2 ++
freebsd/sys/dev/gpio/gpioregulator.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/freebsd/sys/dev/extres/regulator/regulator.c
b/freebsd/sys/dev/extres/regulator/regulator.c
index ca2de6c4..49020bdb 100644
--- a/freebsd/sys/dev/extres/regulator/regulator.c
+++ b/freebsd/sys/dev/extres/regulator/regulator.c
@@ -51,7 +51,9 @@ __FBSDID("$FreeBSD$");
#endif
#include
+#if !defined(__rtems__) || defined(FDT)
#include
+#endif /* !__rtems__ || FDT */
SYSCTL_NODE(_hw, OID_AUTO, regulator, CTLFLAG_RD, NULL, "Regulators");
diff --git a/freebsd/sys/dev/gpio/gpioregulator.c
b/freebsd/sys/dev/gpio/gpioregulator.c
index 7573c558..8ca35bfe 100644
--- a/freebsd/sys/dev/gpio/gpioregulator.c
+++ b/freebsd/sys/dev/gpio/gpioregulator.c
@@ -43,6 +43,7 @@ __FBSDID("$FreeBSD$");
#include
#include
+#if !defined(__rtems__) || defined(FDT)
#include
#include
@@ -348,3 +349,4 @@ static devclass_t gpioregulator_devclass;
EARLY_DRIVER_MODULE(gpioregulator, simplebus, gpioregulator_driver,
gpioregulator_devclass, 0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LAST);
MODULE_VERSION(gpioregulator, 1);
+#endif /* !__rtems__ || FDT */
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd] regulator: Disable FDT parts for non-FDT targets
On 17/04/2020 14:15, Sebastian Huber wrote: > > On 17/04/2020 14:03, Christian Mauderer wrote: >> just noted that the logic isn't entirely correct: Should it be the >> following? >> >> #if (defined(__rtems__) && defined(FDT)) || !defined(__rtems__) >> >> The conditionals with some second define are always a bit tricky in >> libbsd. > > What about > > #if !defined(__rtems__) || defined(FDT) > > ? > Sounds more correct. I'll try it and send a second version. -- ---- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: [PATCH rtems-libbsd] regulator: Disable FDT parts for non-FDT targets
On 17/04/2020 13:21, Sebastian Huber wrote: > Thanks, please push it. > Hello Sebastian, just noted that the logic isn't entirely correct: Should it be the following? #if (defined(__rtems__) && defined(FDT)) || !defined(__rtems__) The conditionals with some second define are always a bit tricky in libbsd. Best regards Christian -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: [PATCH rtems-libbsd v2 06/14] regulator: Import from FreeBSD.
Hello Jan, On 17/04/2020 10:11, jan.som...@dlr.de wrote: > Hi Christian, > > Yes, with this patch my build works again. > Thank you very much. Thanks for testing. Best regards Christian > > Best regards, > >Jan > >> -Ursprüngliche Nachricht- >> Von: Christian Mauderer [mailto:christian.maude...@embedded-brains.de] >> Gesendet: Freitag, 17. April 2020 09:17 >> An: Sommer, Jan; devel@rtems.org >> Betreff: Re: [PATCH rtems-libbsd v2 06/14] regulator: Import from FreeBSD. >> >> Hello Jan, >> >> can you please try this patch: >> >>https://lists.rtems.org/pipermail/devel/2020-April/059419.html >> >> I've still seen quite some linker errors in if_em.c. But as far as I can >> tell they doesn't seem to be related. Are they? >> >> Best regards >> >> Christian >> >> On 17/04/2020 08:17, Christian Mauderer wrote: >>> Hello Jan, >>> >>> On 16/04/2020 22:27, jan.som...@dlr.de wrote: >>>> I have a question: >>>> I just rebased my working tree for the i386 target to the current 5- >> freebsd-12 branch. >>>> The compilation now fails in regulator related files. >>>> It seems that I am missing the FDT define and that comments out some >> includes. >>>> Could you tell me what FDT means in this context and do you know where >> I can activate it? >>> >>> FDT is a flattened device tree. That's something that isn't used on >>> i386. So most likely quite some more BSPs will have that problem. >>> >>> It's some code that I took over quite unchanged from FreeBSD. I would >>> have expected that it is used in FreeBSD for a lot of different cases >>> and therefore didn't expect a problem like that. I'll have a look at it. >>> >>> Best regards >>> >>> Christian >>> >>>> >>>> Cheers, >>>> >>>>Jan >>>> >>>>> -Ursprüngliche Nachricht- >>>>> Von: devel [mailto:devel-boun...@rtems.org] Im Auftrag von Christian >>>>> Mauderer >>>>> Gesendet: Dienstag, 14. April 2020 16:51 >>>>> An: devel@rtems.org >>>>> Betreff: [PATCH rtems-libbsd v2 06/14] regulator: Import from FreeBSD. >>>>> >>>>> Update #3869. >>>>> --- >>>>> freebsd/sys/dev/extres/regulator/regulator.c | 1321 >>>>> >>>>> freebsd/sys/dev/extres/regulator/regulator.h | 156 +++ >>>>> freebsd/sys/dev/extres/regulator/regulator_bus.c | 89 ++ >>>>> freebsd/sys/dev/extres/regulator/regulator_fixed.c | 502 >>>>> freebsd/sys/dev/extres/regulator/regulator_fixed.h | 44 + >>>>> freebsd/sys/dev/gpio/gpioregulator.c | 350 ++ >>>>> 6 files changed, 2462 insertions(+) >>>>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator.c >>>>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator.h >>>>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator_bus.c >>>>> create mode 100644 >> freebsd/sys/dev/extres/regulator/regulator_fixed.c >>>>> create mode 100644 >> freebsd/sys/dev/extres/regulator/regulator_fixed.h >>>>> create mode 100644 freebsd/sys/dev/gpio/gpioregulator.c >>>>> >>>>> diff --git a/freebsd/sys/dev/extres/regulator/regulator.c >>>>> b/freebsd/sys/dev/extres/regulator/regulator.c >>>>> new file mode 100644 >>>>> index ..4ad6e94a >>>>> --- /dev/null >>>>> +++ b/freebsd/sys/dev/extres/regulator/regulator.c >>>>> @@ -0,0 +1,1321 @@ >>>>> +#include >>>>> + >>>>> +/*- >>>>> + * Copyright 2016 Michal Meloun >>>>> + * All rights reserved. >>>>> + * >>>>> + * 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/
Re: [PATCH rtems-libbsd v2 06/14] regulator: Import from FreeBSD.
Hello Jan,
can you please try this patch:
https://lists.rtems.org/pipermail/devel/2020-April/059419.html
I've still seen quite some linker errors in if_em.c. But as far as I can
tell they doesn't seem to be related. Are they?
Best regards
Christian
On 17/04/2020 08:17, Christian Mauderer wrote:
> Hello Jan,
>
> On 16/04/2020 22:27, jan.som...@dlr.de wrote:
>> I have a question:
>> I just rebased my working tree for the i386 target to the current
>> 5-freebsd-12 branch.
>> The compilation now fails in regulator related files.
>> It seems that I am missing the FDT define and that comments out some
>> includes.
>> Could you tell me what FDT means in this context and do you know where I can
>> activate it?
>
> FDT is a flattened device tree. That's something that isn't used on
> i386. So most likely quite some more BSPs will have that problem.
>
> It's some code that I took over quite unchanged from FreeBSD. I would
> have expected that it is used in FreeBSD for a lot of different cases
> and therefore didn't expect a problem like that. I'll have a look at it.
>
> Best regards
>
> Christian
>
>>
>> Cheers,
>>
>>Jan
>>
>>> -Ursprüngliche Nachricht-
>>> Von: devel [mailto:devel-boun...@rtems.org] Im Auftrag von Christian
>>> Mauderer
>>> Gesendet: Dienstag, 14. April 2020 16:51
>>> An: devel@rtems.org
>>> Betreff: [PATCH rtems-libbsd v2 06/14] regulator: Import from FreeBSD.
>>>
>>> Update #3869.
>>> ---
>>> freebsd/sys/dev/extres/regulator/regulator.c | 1321
>>>
>>> freebsd/sys/dev/extres/regulator/regulator.h | 156 +++
>>> freebsd/sys/dev/extres/regulator/regulator_bus.c | 89 ++
>>> freebsd/sys/dev/extres/regulator/regulator_fixed.c | 502
>>> freebsd/sys/dev/extres/regulator/regulator_fixed.h | 44 +
>>> freebsd/sys/dev/gpio/gpioregulator.c | 350 ++
>>> 6 files changed, 2462 insertions(+)
>>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator.c
>>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator.h
>>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator_bus.c
>>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator_fixed.c
>>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator_fixed.h
>>> create mode 100644 freebsd/sys/dev/gpio/gpioregulator.c
>>>
>>> diff --git a/freebsd/sys/dev/extres/regulator/regulator.c
>>> b/freebsd/sys/dev/extres/regulator/regulator.c
>>> new file mode 100644
>>> index ..4ad6e94a
>>> --- /dev/null
>>> +++ b/freebsd/sys/dev/extres/regulator/regulator.c
>>> @@ -0,0 +1,1321 @@
>>> +#include
>>> +
>>> +/*-
>>> + * Copyright 2016 Michal Meloun
>>> + * All rights reserved.
>>> + *
>>> + * 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 AUTHOR 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 AUTHOR 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.
>>> + */
>>> +
>>> +#include
>>> +__FBSDID("$FreeBSD$");
>>> +
>>>
[PATCH rtems-libbsd] regulator: Disable FDT parts for non-FDT targets
---
freebsd/sys/dev/extres/regulator/regulator.c | 2 ++
freebsd/sys/dev/gpio/gpioregulator.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/freebsd/sys/dev/extres/regulator/regulator.c
b/freebsd/sys/dev/extres/regulator/regulator.c
index ca2de6c4..53e45ee7 100644
--- a/freebsd/sys/dev/extres/regulator/regulator.c
+++ b/freebsd/sys/dev/extres/regulator/regulator.c
@@ -51,7 +51,9 @@ __FBSDID("$FreeBSD$");
#endif
#include
+#if defined(__rtems__) && defined(FDT)
#include
+#endif /* __rtems__ && FDT */
SYSCTL_NODE(_hw, OID_AUTO, regulator, CTLFLAG_RD, NULL, "Regulators");
diff --git a/freebsd/sys/dev/gpio/gpioregulator.c
b/freebsd/sys/dev/gpio/gpioregulator.c
index 7573c558..bdee96d5 100644
--- a/freebsd/sys/dev/gpio/gpioregulator.c
+++ b/freebsd/sys/dev/gpio/gpioregulator.c
@@ -43,6 +43,7 @@ __FBSDID("$FreeBSD$");
#include
#include
+#if defined(__rtems__) && defined(FDT)
#include
#include
@@ -348,3 +349,4 @@ static devclass_t gpioregulator_devclass;
EARLY_DRIVER_MODULE(gpioregulator, simplebus, gpioregulator_driver,
gpioregulator_devclass, 0, 0, BUS_PASS_INTERRUPT + BUS_PASS_ORDER_LAST);
MODULE_VERSION(gpioregulator, 1);
+#endif /* __rtems__ && FDT */
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems v2] bsps/arm: Fix uninitialized value in generic timer
Hello Gedare, On 16/04/2020 21:16, Gedare Bloom wrote: > You can push this to 5.1, update the ticket milestone if you do. Thanks. In that case I most likely should create an extra ticket. I'm not sure whether Sebastian sees that one as close enough to finished to be a 5.1 ticket. For me it was a fix for the feature in progress and therefore I updated that ticket. Best regards Christian > > On Thu, Apr 16, 2020 at 9:27 AM Sebastian Huber > wrote: >> >> On 16/04/2020 15:29, Christian Mauderer wrote: >>> _CPU_Counter_frequency() can be called by the rtems_counter >>> initialization before arm_gt_clock_initialize() initializes the value >>> used in _CPU_Counter_frequency(). >>> >>> Update #3456. >> Thanks, looks good. >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
Re: [PATCH rtems-libbsd v2 06/14] regulator: Import from FreeBSD.
Hello Jan,
On 16/04/2020 22:27, jan.som...@dlr.de wrote:
> I have a question:
> I just rebased my working tree for the i386 target to the current
> 5-freebsd-12 branch.
> The compilation now fails in regulator related files.
> It seems that I am missing the FDT define and that comments out some includes.
> Could you tell me what FDT means in this context and do you know where I can
> activate it?
FDT is a flattened device tree. That's something that isn't used on
i386. So most likely quite some more BSPs will have that problem.
It's some code that I took over quite unchanged from FreeBSD. I would
have expected that it is used in FreeBSD for a lot of different cases
and therefore didn't expect a problem like that. I'll have a look at it.
Best regards
Christian
>
> Cheers,
>
>Jan
>
>> -Ursprüngliche Nachricht-
>> Von: devel [mailto:devel-boun...@rtems.org] Im Auftrag von Christian
>> Mauderer
>> Gesendet: Dienstag, 14. April 2020 16:51
>> An: devel@rtems.org
>> Betreff: [PATCH rtems-libbsd v2 06/14] regulator: Import from FreeBSD.
>>
>> Update #3869.
>> ---
>> freebsd/sys/dev/extres/regulator/regulator.c | 1321
>>
>> freebsd/sys/dev/extres/regulator/regulator.h | 156 +++
>> freebsd/sys/dev/extres/regulator/regulator_bus.c | 89 ++
>> freebsd/sys/dev/extres/regulator/regulator_fixed.c | 502
>> freebsd/sys/dev/extres/regulator/regulator_fixed.h | 44 +
>> freebsd/sys/dev/gpio/gpioregulator.c | 350 ++
>> 6 files changed, 2462 insertions(+)
>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator.c
>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator.h
>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator_bus.c
>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator_fixed.c
>> create mode 100644 freebsd/sys/dev/extres/regulator/regulator_fixed.h
>> create mode 100644 freebsd/sys/dev/gpio/gpioregulator.c
>>
>> diff --git a/freebsd/sys/dev/extres/regulator/regulator.c
>> b/freebsd/sys/dev/extres/regulator/regulator.c
>> new file mode 100644
>> index ..4ad6e94a
>> --- /dev/null
>> +++ b/freebsd/sys/dev/extres/regulator/regulator.c
>> @@ -0,0 +1,1321 @@
>> +#include
>> +
>> +/*-
>> + * Copyright 2016 Michal Meloun
>> + * All rights reserved.
>> + *
>> + * 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 AUTHOR 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 AUTHOR 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.
>> + */
>> +
>> +#include
>> +__FBSDID("$FreeBSD$");
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#ifdef FDT
>> +#include
>> +#include
>> +#include
>> +#endif
>> +#include
>> +
>> +#include
>> +
>> +SYSCTL_NODE(_hw, OID_AUTO, regulator, CTLFLAG_RD, NULL,
>> "Regulators");
>> +
>> +MALLOC_DEFINE(M_REGULATOR, "regulator", "Regulator framework");
>> +
>> +#define DIV_ROUND_UP(n,d) howmany(n, d)
>
[PATCH rtems v2] bsps/arm: Fix uninitialized value in generic timer
_CPU_Counter_frequency() can be called by the rtems_counter
initialization before arm_gt_clock_initialize() initializes the value
used in _CPU_Counter_frequency().
Update #3456.
---
bsps/arm/shared/clock/clock-generic-timer.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/bsps/arm/shared/clock/clock-generic-timer.c
b/bsps/arm/shared/clock/clock-generic-timer.c
index 1f39632ba6..072583473e 100644
--- a/bsps/arm/shared/clock/clock-generic-timer.c
+++ b/bsps/arm/shared/clock/clock-generic-timer.c
@@ -148,7 +148,8 @@ static void arm_gt_clock_initialize(void)
uint64_t cval;
struct timecounter *tc;
- frequency = arm_gt_clock_instance.interval;
+ tc = _gt_clock_instance.tc;
+ frequency = tc->tc_frequency;
us_per_tick = rtems_configuration_get_microseconds_per_tick();
interval = (uint32_t) ((frequency * us_per_tick) / 100);
cval = arm_gt_clock_get_count();
@@ -158,10 +159,8 @@ static void arm_gt_clock_initialize(void)
arm_gt_clock_gt_init(cval);
arm_gt_clock_secondary_initialization(cval);
- tc = _gt_clock_instance.tc;
tc->tc_get_timecount = arm_gt_clock_get_timecount;
tc->tc_counter_mask = 0x;
- tc->tc_frequency = frequency;
tc->tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
rtems_timecounter_install(tc);
}
@@ -178,12 +177,19 @@ CPU_Counter_ticks _CPU_Counter_read(void)
static void arm_gt_clock_early_init(void)
{
+ uint32_t frequency;
arm_gt_clock_set_control(0x3);
arm_generic_timer_get_config(
-_gt_clock_instance.interval,
+,
_gt_clock_instance.irq
);
+
+ /*
+ * Used by _CPU_Counter_frequency() before arm_gt_clock_initialize() is
+ * called.
+ */
+ arm_gt_clock_instance.tc.tc_frequency = frequency;
}
RTEMS_SYSINIT_ITEM(
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems] bsps/arm: Fix uninitialized value in generic timer
_CPU_Counter_frequency() can be called by the rtems_counter
initialization before arm_gt_clock_initialize() initializes the value
used in _CPU_Counter_frequency().
Update #3456.
---
bsps/arm/shared/clock/clock-generic-timer.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/bsps/arm/shared/clock/clock-generic-timer.c
b/bsps/arm/shared/clock/clock-generic-timer.c
index 1f39632ba6..a0efb9c7ed 100644
--- a/bsps/arm/shared/clock/clock-generic-timer.c
+++ b/bsps/arm/shared/clock/clock-generic-timer.c
@@ -161,7 +161,6 @@ static void arm_gt_clock_initialize(void)
tc = _gt_clock_instance.tc;
tc->tc_get_timecount = arm_gt_clock_get_timecount;
tc->tc_counter_mask = 0x;
- tc->tc_frequency = frequency;
tc->tc_quality = RTEMS_TIMECOUNTER_QUALITY_CLOCK_DRIVER;
rtems_timecounter_install(tc);
}
@@ -178,12 +177,19 @@ CPU_Counter_ticks _CPU_Counter_read(void)
static void arm_gt_clock_early_init(void)
{
+ uint32_t frequency;
arm_gt_clock_set_control(0x3);
arm_generic_timer_get_config(
-_gt_clock_instance.interval,
+,
_gt_clock_instance.irq
);
+
+ /* Used by _CPU_Counter_frequency before arm_gt_clock_initialize is called */
+ arm_gt_clock_instance.tc.tc_frequency = frequency;
+
+ /* overwritten with the calculated interval by arm_gt_clock_initialize */
+ arm_gt_clock_instance.interval = frequency;
}
RTEMS_SYSINIT_ITEM(
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd] imx: Fix build for all other BSPs.
Hello Vijay and Sebastian,
thanks for the review and test. I pushed the patch and updated RSB.
Sorry for breaking stuff in the first place.
Best regards
Christian
On 16/04/2020 10:45, Vijay Kumar Banerjee wrote:
> Hi,
>
> I could successfully build libbsd for arm/beagleboneblack with this path.
>
> Thanks and regards,
> Vijay
>
> On Thu, Apr 16, 2020 at 2:08 PM Christian Mauderer
> <mailto:christian.maude...@embedded-brains.de>> wrote:
>
> ---
> freebsd/sys/arm/freescale/imx/imx6_ccm.c | 7 +++
> freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 4
> freebsd/sys/dev/usb/controller/ehci_imx.c | 2 ++
> 3 files changed, 13 insertions(+)
>
> diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
> b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
> index cef79933..78bbd5c1 100644
> --- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
> +++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
> @@ -51,7 +51,14 @@ __FBSDID("$FreeBSD$");
> #include
> #include
> #include
> +#ifndef __rtems__
> +#include
> +#else /* __rtems__ */
> +#include
> +#ifdef LIBBSP_ARM_IMX_BSP_H
> #include
> +#endif /* LIBBSP_ARM_IMX_BSP_H */
> +#endif /* __rtems__ */
>
> #ifndef CCGR_CLK_MODE_ALWAYS
> #define CCGR_CLK_MODE_OFF 0
> diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
> b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
> index 7df2e124..3a3495bb 100644
> --- a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
> +++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
> @@ -49,7 +49,11 @@ __FBSDID("$FreeBSD$");
>
> #include
>
> +#ifndef __rtems__
> #include
> +#else /* __rtems__ */
> +void imx_ccm_usbphy_enable(device_t _phydev);
> +#endif /* __rtems__ */
> #include
> #include
> #ifdef __rtems__
> diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c
> b/freebsd/sys/dev/usb/controller/ehci_imx.c
> index 544a63b5..23f7e3a9 100644
> --- a/freebsd/sys/dev/usb/controller/ehci_imx.c
> +++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
> @@ -67,7 +67,9 @@ __FBSDID("$FreeBSD$");
> #include
> #include
>
> +#ifndef __rtems__
> #include
> +#endif /* __rtems__ */
>
> #include
>
> --
> 2.16.4
>
--
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
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
Re: [PATCH rtems-libbsd v2 12/14] ehci_imx: Add to build.
On 16/04/2020 10:44, Vijay Kumar Banerjee wrote: > > > On Thu, Apr 16, 2020 at 2:08 PM Christian Mauderer > <mailto:christian.maude...@embedded-brains.de>> wrote: > > On 16/04/2020 10:27, Vijay Kumar Banerjee wrote: > > > > > > On Thu, Apr 16, 2020 at 1:51 PM Christian Mauderer > > <mailto:christian.maude...@embedded-brains.de> > > <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>>> wrote: > > > > > > > > On 16/04/2020 09:41, Christian Mauderer wrote: > > > On 16/04/2020 09:21, Vijay Kumar Banerjee wrote: > > >> > > >> > > >> On Thu, Apr 16, 2020 at 12:41 PM Christian Mauderer > > >> <mailto:christian.maude...@embedded-brains.de> > > <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>> > > >> <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de> > > <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>>>> wrote: > > >> > > >> Hello Vijay, > > >> > > >> On 16/04/2020 09:04, Vijay Kumar Banerjee wrote: > > >> > Hi Christian, > > >> > > > >> > I'm not able to build libbsd with this patch. I'm > getting the > > >> following > > >> > error: > > >> > ``` > > >> > ../../freebsd/sys/dev/usb/controller/ehci_imx.c:70:10: > > fatal error: > > >> > arm/freescale/imx/imx_ccmvar.h: No such file or directory > > >> > #include > > >> > ``` > > >> > From git blame I got to know that this file was > introduced > > by the > > >> commit > > >> > from this patch. > > >> > Am I missing something or is it really a bug? > > >> > > >> Thanks for the report. On what BSP and which exact > commit did > > you try to > > >> build? I had no trouble building the patch set from a clean > > checkout > > >> yesterday before committing it. > > >> > > >> I did a pull from the upstream master and tried the build on > > >> arm/beagleboneblack > > >> I see that the header file is not present in the freebsd/ > directory > > >> ``` > > >> rtems-libbsd $>find -iname imx_ccmvar.h > > >> ./freebsd-org/sys/arm/freescale/imx/imx_ccmvar.h > > >> ``` > > > > > > Hello Vijay, > > > > > > that's quite clearly a bug that I introduced. I'll create a > patch. > > > > > > The imx_ccmvar.h is a file that is provided by the BSP I > used for > > testing. > > > > > > Best regards > > > > > > Christian > > > > I've sent a patch. Can you test it? > > > > Sure. I don't see the patch on the list yet, I'll test it as soon > as it > > comes :) > > Odd. It's already sent out and I CCd you directly. But the archive > hasn't seen it either. To be sure, I attached the patch here. > > This patch fixed the issue and the build completes successfully. Thanks. > I'll also comment on the patch when it hits the list. Should have reached the list now: https://lists.rtems.org/pipermail/devel/2020-April/059395.html > > > > > > > > >> > > >> > > > >> > Sorry for commenting on the patch that has already been > > committed, > > >> > please let me know of > > >> > the preferred way to comment on a commit if this is > not the > > right way. > > >> > > >> No problem. That's exactly the right way to do it. If there > > is a bug it > > >> has to be solved and everyone should know that someone is > >
Re: [PATCH rtems-libbsd v2 12/14] ehci_imx: Add to build.
On 16/04/2020 10:27, Vijay Kumar Banerjee wrote:
>
>
> On Thu, Apr 16, 2020 at 1:51 PM Christian Mauderer
> <mailto:christian.maude...@embedded-brains.de>> wrote:
>
>
>
> On 16/04/2020 09:41, Christian Mauderer wrote:
> > On 16/04/2020 09:21, Vijay Kumar Banerjee wrote:
> >>
> >>
> >> On Thu, Apr 16, 2020 at 12:41 PM Christian Mauderer
> >> <mailto:christian.maude...@embedded-brains.de>
> >> <mailto:christian.maude...@embedded-brains.de
> <mailto:christian.maude...@embedded-brains.de>>> wrote:
> >>
> >> Hello Vijay,
> >>
> >> On 16/04/2020 09:04, Vijay Kumar Banerjee wrote:
> >> > Hi Christian,
> >> >
> >> > I'm not able to build libbsd with this patch. I'm getting the
> >> following
> >> > error:
> >> > ```
> >> > ../../freebsd/sys/dev/usb/controller/ehci_imx.c:70:10:
> fatal error:
> >> > arm/freescale/imx/imx_ccmvar.h: No such file or directory
> >> > #include
> >> > ```
> >> > From git blame I got to know that this file was introduced
> by the
> >> commit
> >> > from this patch.
> >> > Am I missing something or is it really a bug?
> >>
> >> Thanks for the report. On what BSP and which exact commit did
> you try to
> >> build? I had no trouble building the patch set from a clean
> checkout
> >> yesterday before committing it.
> >>
> >> I did a pull from the upstream master and tried the build on
> >> arm/beagleboneblack
> >> I see that the header file is not present in the freebsd/ directory
> >> ```
> >> rtems-libbsd $>find -iname imx_ccmvar.h
> >> ./freebsd-org/sys/arm/freescale/imx/imx_ccmvar.h
> >> ```
> >
> > Hello Vijay,
> >
> > that's quite clearly a bug that I introduced. I'll create a patch.
> >
> > The imx_ccmvar.h is a file that is provided by the BSP I used for
> testing.
> >
> > Best regards
> >
> > Christian
>
> I've sent a patch. Can you test it?
>
> Sure. I don't see the patch on the list yet, I'll test it as soon as it
> comes :)
Odd. It's already sent out and I CCd you directly. But the archive
hasn't seen it either. To be sure, I attached the patch here.
>
> >
> >>
> >> >
> >> > Sorry for commenting on the patch that has already been
> committed,
> >> > please let me know of
> >> > the preferred way to comment on a commit if this is not the
> right way.
> >>
> >> No problem. That's exactly the right way to do it. If there
> is a bug it
> >> has to be solved and everyone should know that someone is
> having a look
> >> at it.
> >>
> >> Best regards
> >>
> >> Christian
> >>
[...]
--
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>From cc3ab6266ef0e0d037f45016e35190631177dd80 Mon Sep 17 00:00:00 2001
From: Christian Mauderer
Date: Thu, 16 Apr 2020 09:52:12 +0200
Subject: [PATCH rtems-libbsd] imx: Fix build for all other BSPs.
---
freebsd/sys/arm/freescale/imx/imx6_ccm.c| 7 +++
freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 4
freebsd/sys/dev/usb/controller/ehci_imx.c | 2 ++
3 files changed, 13 insertions(+)
diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
index cef79933..78bbd5c1 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
@@ -51,7 +51,14 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#ifndef __rtems__
+#include
+#else /* __rtems__ */
+#include
+#ifdef LIBBSP_ARM_IMX_BSP_H
#include
+#endif /* LIBBSP_ARM_IMX_BSP_H */
+#endif /* __rtems__ */
#ifndef CCGR_CLK_MODE_ALWAYS
#define CCGR_CLK_MODE_OFF 0
diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
index 7df2e124..3a3495bb 100644
--- a/freebsd
[PATCH rtems-libbsd] imx: Fix build for all other BSPs.
---
freebsd/sys/arm/freescale/imx/imx6_ccm.c| 7 +++
freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 4
freebsd/sys/dev/usb/controller/ehci_imx.c | 2 ++
3 files changed, 13 insertions(+)
diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
index cef79933..78bbd5c1 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
@@ -51,7 +51,14 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#ifndef __rtems__
+#include
+#else /* __rtems__ */
+#include
+#ifdef LIBBSP_ARM_IMX_BSP_H
#include
+#endif /* LIBBSP_ARM_IMX_BSP_H */
+#endif /* __rtems__ */
#ifndef CCGR_CLK_MODE_ALWAYS
#defineCCGR_CLK_MODE_OFF 0
diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
index 7df2e124..3a3495bb 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
@@ -49,7 +49,11 @@ __FBSDID("$FreeBSD$");
#include
+#ifndef __rtems__
#include
+#else /* __rtems__ */
+void imx_ccm_usbphy_enable(device_t _phydev);
+#endif /* __rtems__ */
#include
#include
#ifdef __rtems__
diff --git a/freebsd/sys/dev/usb/controller/ehci_imx.c
b/freebsd/sys/dev/usb/controller/ehci_imx.c
index 544a63b5..23f7e3a9 100644
--- a/freebsd/sys/dev/usb/controller/ehci_imx.c
+++ b/freebsd/sys/dev/usb/controller/ehci_imx.c
@@ -67,7 +67,9 @@ __FBSDID("$FreeBSD$");
#include
#include
+#ifndef __rtems__
#include
+#endif /* __rtems__ */
#include
--
2.16.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
