[PATCH] closes #3889
---
cpukit/include/rtems/posix/timer.h | 1 +
cpukit/posix/src/psxtimercreate.c | 1 +
cpukit/posix/src/timergettime.c| 61 +++---
3 files changed, 41 insertions(+), 22 deletions(-)
diff --git a/cpukit/include/rtems/posix/timer.h
b/cpukit/include/rtems/posix/timer.h
index bcbf07a65a..7ae089173a 100644
--- a/cpukit/include/rtems/posix/timer.h
+++ b/cpukit/include/rtems/posix/timer.h
@@ -48,6 +48,7 @@ typedef struct {
uint32_t ticks; /* Number of ticks of the initialization */
uint32_t overrun;/* Number of expirations of the timer*/
struct timespec time; /* Time at which the timer was started */
+ clockid_t clock_type; /* The type of timer */
} POSIX_Timer_Control;
/**
diff --git a/cpukit/posix/src/psxtimercreate.c
b/cpukit/posix/src/psxtimercreate.c
index a63cf1d100..804c7a41e7 100644
--- a/cpukit/posix/src/psxtimercreate.c
+++ b/cpukit/posix/src/psxtimercreate.c
@@ -91,6 +91,7 @@ int timer_create(
ptimer->timer_data.it_value.tv_nsec= 0;
ptimer->timer_data.it_interval.tv_sec = 0;
ptimer->timer_data.it_interval.tv_nsec = 0;
+ ptimer->clock_type = clock_id;
_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
diff --git a/cpukit/posix/src/timergettime.c b/cpukit/posix/src/timergettime.c
index ee2a566f0e..ff2176ac60 100644
--- a/cpukit/posix/src/timergettime.c
+++ b/cpukit/posix/src/timergettime.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/*
* - When a timer is initialized, the value of the time in
@@ -35,39 +36,55 @@
* - When this function is called, it returns the difference
*between the current time and the initialization time.
*/
-
int timer_gettime(
timer_ttimerid,
struct itimerspec *value
-)
+)
{
POSIX_Timer_Control *ptimer;
- ISR_lock_Context lock_context;
- uint64_t now;
- uint32_t remaining;
+ ISR_lock_Context lock_context;
+ uint32_t remaining;
+ Per_CPU_Control *cpu;
+ struct timespec *now;
+ struct timespec *expire;
+ struct timespec *result;
- if ( !value )
-rtems_set_errno_and_return_minus_one( EINVAL );
+ if (!value)
+rtems_set_errno_and_return_minus_one(EINVAL);
- ptimer = _POSIX_Timer_Get( timerid, _context );
- if ( ptimer != NULL ) {
-Per_CPU_Control *cpu;
+ ptimer = _POSIX_Timer_Get(timerid, _context);
+ if (ptimer == NULL) {
+rtems_set_errno_and_return_minus_one(EINVAL);
+ }
-cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
-now = cpu->Watchdog.ticks;
+ cpu = _POSIX_Timer_Acquire_critical(ptimer, _context);
+ rtems_timespec_from_ticks(ptimer->Timer.expire, expire);
-if ( now < ptimer->Timer.expire ) {
- remaining = (uint32_t) ( ptimer->Timer.expire - now );
+ if (ptimer->clock_type == CLOCK_MONOTONIC) {
+ _Timecounter_Nanouptime(now);
+ }
+ if (ptimer->clock_type == CLOCK_REALTIME) {
+_TOD_Get(now);
+ }
+
+
+ if( rtems_timespec_less_than( now, expire )) {
+ rtems_timespec_subtract(now, expire, result);
} else {
- remaining = 0;
+ result->tv_nsec=0;
+ result->tv_sec=0;
}
+
+ (*value).it_value=*result;
+ value->it_interval = ptimer->timer_data.it_interval;
+
+ _POSIX_Timer_Release(cpu, _context);
+ return 0;
+}
+
+
+
+
-_Timespec_From_ticks( remaining, >it_value );
-value->it_interval = ptimer->timer_data.it_interval;
-_POSIX_Timer_Release( cpu, _context );
-return 0;
- }
- rtems_set_errno_and_return_minus_one( EINVAL );
-}
--
2.32.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hi all, On Thu, Jul 22, 2021 at 4:12 PM Pavel Pisa wrote: > > Hello Joel, > > On Thursday 22 of July 2021 22:19:21 Joel Sherrill wrote: > > On Thu, Jul 22, 2021 at 12:25 PM Robin Müller > > > The current version of the rtems-lwip support after I added STM32H7 can > > > still be found here: > > > https://github.com/rmspacefish/rtems-lwip/tree/mueller/master and > > > includes the TMS570 code as well. > > > > > > There is also a LPC port here: > > > https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/drive > > >r/lpc_emac But that one still appears to use Makefiles, and needs to be > > > updated to waf if it is integrated. > > > > Very nice. Updating to waf should be a lot easier than writing the driver. > > :) > > > > Vijay.. it's your call but if adding drivers with status of "compile > > only" is OK with you, that at least lays the groundwork for someone > > else to test later. I'm just thinking that compiles and untested makes > > it easy for someone to push it across the goal line. > > That is surprise, I forgot that port of our sysless LPC driver to RTEMS > exists. The code in sysless mode is used by Alvat company http://alvat.cz/ > (founded by our alumni Pavel Nemecek ) to provide Pick to Light system > gateway and embedded web on LPC. Our robotic control systems LX_RoCoN > use it in daily operation in selfbuild interferometer of Czech Academy > of Sciences aspherical lens production etc. So the core of the driver > should be functional. I have newer used it on RTEMS but I have > there LX_RoCoN running on table before me exactly now. Not > with RTEMS, but I have tested RTEMS on it, so I can give it > a try if I learn again WAF stuff. > This is amazing! I can help with the waf integration. I'm working on making the waf system in rtems-lwip better, so that it doesn't take much effort to integrate a new set of drivers like this. > I am adding Roman Bartosnsky to CC, he is main author > of LPC driver and LwIP OMK port done under my company > funding and then on some Alvat budget. He woks on more > ESA projects at his company https://www.daiteq.com/ , > an actual one is NOEL-V related. He worked with me for years > on our RTEMS based medical infusion systems, so he knew > RTEMS and CPU architectures well. > Great! It would be great to get it tested on a hardware after it's ported on rtems-lwip. > So there are people who have strong insight into the code. > So if it has been located again it would worth to collect > in on one place. We have some enhancements of the LPC > driver in our OMK repo, so we can merge updates. > I expect that they do not collide with changes for > RTEMS build. > I'm following the OMK repository for TMS570. After the waf support is added with the STM32 and LPC, It should be possible to merge the driver updates from omk. Best regards, Vijay > Best wishes, > > Pavel Pisa > > == > PiKRON s.r.o. Phone/Fax: +420 284684676 > Kankovskeho 1235Phone: +420 234697622 > 182 00 Praha 8 WWW: http://www.pikron.com/ > Czech Republic e-mail: pik...@pikron.com > == ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hello Joel, On Thursday 22 of July 2021 22:19:21 Joel Sherrill wrote: > On Thu, Jul 22, 2021 at 12:25 PM Robin Müller > > The current version of the rtems-lwip support after I added STM32H7 can > > still be found here: > > https://github.com/rmspacefish/rtems-lwip/tree/mueller/master and > > includes the TMS570 code as well. > > > > There is also a LPC port here: > > https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/drive > >r/lpc_emac But that one still appears to use Makefiles, and needs to be > > updated to waf if it is integrated. > > Very nice. Updating to waf should be a lot easier than writing the driver. > :) > > Vijay.. it's your call but if adding drivers with status of "compile > only" is OK with you, that at least lays the groundwork for someone > else to test later. I'm just thinking that compiles and untested makes > it easy for someone to push it across the goal line. That is surprise, I forgot that port of our sysless LPC driver to RTEMS exists. The code in sysless mode is used by Alvat company http://alvat.cz/ (founded by our alumni Pavel Nemecek ) to provide Pick to Light system gateway and embedded web on LPC. Our robotic control systems LX_RoCoN use it in daily operation in selfbuild interferometer of Czech Academy of Sciences aspherical lens production etc. So the core of the driver should be functional. I have newer used it on RTEMS but I have there LX_RoCoN running on table before me exactly now. Not with RTEMS, but I have tested RTEMS on it, so I can give it a try if I learn again WAF stuff. I am adding Roman Bartosnsky to CC, he is main author of LPC driver and LwIP OMK port done under my company funding and then on some Alvat budget. He woks on more ESA projects at his company https://www.daiteq.com/ , an actual one is NOEL-V related. He worked with me for years on our RTEMS based medical infusion systems, so he knew RTEMS and CPU architectures well. So there are people who have strong insight into the code. So if it has been located again it would worth to collect in on one place. We have some enhancements of the LPC driver in our OMK repo, so we can merge updates. I expect that they do not collide with changes for RTEMS build. Best wishes, Pavel Pisa == PiKRON s.r.o. Phone/Fax: +420 284684676 Kankovskeho 1235Phone: +420 234697622 182 00 Praha 8 WWW: http://www.pikron.com/ Czech Republic e-mail: pik...@pikron.com == ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
On Thu, Jul 22, 2021 at 12:25 PM Robin Müller wrote: > > Hello, > > I am still waiting on STM32 reply because of the licensing issue. Might still > take weeks/months.. The Ultimate Liberty license is a bit of a misnomer. Quite a few restrictions on liberty there. > > Another solution would be to write some scripts to copy the code from the > Cube sources.. > But I would prefer to avoid them, because I also had to merge some of the > files provided by STM so that I could use/test all three APIs. > > I was able to test and use all major APIs on a STM32H7 board with RTEMS, > including the Socket API.. Although I disliked about the Socket API that it's > easy to forget the cache invalidation on the TX/RX buffers (forgot which one > it was) if they are not protected via MPU but that's also a STM32H7 specific > issue. I remember this long discussion. Is this something that might show up again on other drivers? I'm just wondering if this is really a one-off or something we need a pattern for. > The current version of the rtems-lwip support after I added STM32H7 can still > be found here: https://github.com/rmspacefish/rtems-lwip/tree/mueller/master > and includes the TMS570 code as well. > > There is also a LPC port here: > https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/driver/lpc_emac > But that one still appears to use Makefiles, and needs to be updated to waf > if it is integrated. Very nice. Updating to waf should be a lot easier than writing the driver. :) Vijay.. it's your call but if adding drivers with status of "compile only" is OK with you, that at least lays the groundwork for someone else to test later. I'm just thinking that compiles and untested makes it easy for someone to push it across the goal line. --joel > Kind Regards > Robin > > > > On Thu, 22 Jul 2021 at 00:10, Vijay Kumar Banerjee wrote: >> >> Hi, >> >> >> On Wed, Jul 21, 2021 at 2:25 AM Pavel Pisa wrote: >> > >> > Hello Vijay, >> > >> > thanks of the status. >> > >> >> I added a note in the devel page: https://devel.rtems.org/wiki/Packages/LWIP >> >> >> >> > On Wednesday 21 of July 2021 07:16:51 Vijay Kumar Banerjee wrote: >> > > Hi Pavel, >> > > >> > > On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa >> > > wrote: >> > > > Is it devel branch of Vijay Kumar Banerjee's >> > > > repo >> > > > >> > > > https://git.rtems.org/vijay/rtems-lwip.git/ >> > > >> > > Right now yes. Once this is mature, it will probably be pushed to the >> > > top directory. >> > > >> > > > If so, it would worth to put that on the top >> > > > of LwIP RTEMS info page to guide people interested >> > > > to live work and not lose time in another >> > > > abandonned attempts >> > > > >> > > > https://devel.rtems.org/wiki/Packages/LWIP >> > > >> > > Thanks, I'll add a note there. >> > > >> > > > Addition of pointers to STM WIP to some >> > > > central place would worth too with >> > > > pointer to the instructions or instructions >> > > > included... >> > > >> > > I haven't tested it myself. Robin is working on this one and might be >> > > able to add the instructions. But this is supposed to be merged into >> > > the repo you mentioned above. >> > >> > Great that there is the common merge place. >> > >> > >> > > > Generally I am curious what works and where >> > > > are problems. I do not expect to have time or >> > > > find students this summer but I try to offer >> > > > project as theses and next summer and there >> > > > chance (small) that I find some studnet >> > > > to participate. >> > > >> > > I am currently actively working on the lwip port to get it working >> > > with at least a few boards, along with a streamlined build system. I >> > > could only get the BBB running with a telnetd application that I added >> > > in the test/ directory in the rtems-lwip repository. I used the >> > > drivers from TI for BBB. >> > >> > OK, I have some access to BBB so when my or some studnet >> > time allows we can test it on this target. >> Thanks. Any feedback would be really appreciated. >> >> > I am more personally interested to TMS570. >> > I think that I can find some time for testing on TMS570LS3137 >> > if the instructions and code is declared to worth to test. >> > I hope that I have all tools for this setup. >> > >> This has not been tested yet, I'm working on the build system to >> streamline the process further. It would be great to get this port >> tested. Please ping me if you have any build issues when testing (if >> you happen to test before the build system update :) ). >> >> >> > = >> > Side note to TMS570 FEE CTU code (if there is interest, >> > I it would worth to move to separate thread) >> > >> > By the way, the way my former colleagues who left faculty >> > stopped blocking (after many years) TMS570 Rapid Prototyping >> > Platform code >> > http://rtime.felk.cvut.cz/rpp-tms570/ >> > and changed master branch license to MIT (The work has been >> >
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hello, I am still waiting on STM32 reply because of the licensing issue. Might still take weeks/months.. Another solution would be to write some scripts to copy the code from the Cube sources.. But I would prefer to avoid them, because I also had to merge some of the files provided by STM so that I could use/test all three APIs. I was able to test and use all major APIs on a STM32H7 board with RTEMS, including the Socket API.. Although I disliked about the Socket API that it's easy to forget the cache invalidation on the TX/RX buffers (forgot which one it was) if they are not protected via MPU but that's also a STM32H7 specific issue. The current version of the rtems-lwip support after I added STM32H7 can still be found here: https://github.com/rmspacefish/rtems-lwip/tree/mueller/master and includes the TMS570 code as well. There is also a LPC port here: https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/driver/lpc_emac But that one still appears to use Makefiles, and needs to be updated to waf if it is integrated. Kind Regards Robin On Thu, 22 Jul 2021 at 00:10, Vijay Kumar Banerjee wrote: > Hi, > > > On Wed, Jul 21, 2021 at 2:25 AM Pavel Pisa wrote: > > > > Hello Vijay, > > > > thanks of the status. > > > > I added a note in the devel page: > https://devel.rtems.org/wiki/Packages/LWIP > > > > > On Wednesday 21 of July 2021 07:16:51 Vijay Kumar Banerjee wrote: > > > Hi Pavel, > > > > > > On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa > wrote: > > > > Is it devel branch of Vijay Kumar Banerjee's > > > > repo > > > > > > > > https://git.rtems.org/vijay/rtems-lwip.git/ > > > > > > Right now yes. Once this is mature, it will probably be pushed to the > > > top directory. > > > > > > > If so, it would worth to put that on the top > > > > of LwIP RTEMS info page to guide people interested > > > > to live work and not lose time in another > > > > abandonned attempts > > > > > > > > https://devel.rtems.org/wiki/Packages/LWIP > > > > > > Thanks, I'll add a note there. > > > > > > > Addition of pointers to STM WIP to some > > > > central place would worth too with > > > > pointer to the instructions or instructions > > > > included... > > > > > > I haven't tested it myself. Robin is working on this one and might be > > > able to add the instructions. But this is supposed to be merged into > > > the repo you mentioned above. > > > > Great that there is the common merge place. > > > > > > > > Generally I am curious what works and where > > > > are problems. I do not expect to have time or > > > > find students this summer but I try to offer > > > > project as theses and next summer and there > > > > chance (small) that I find some studnet > > > > to participate. > > > > > > I am currently actively working on the lwip port to get it working > > > with at least a few boards, along with a streamlined build system. I > > > could only get the BBB running with a telnetd application that I added > > > in the test/ directory in the rtems-lwip repository. I used the > > > drivers from TI for BBB. > > > > OK, I have some access to BBB so when my or some studnet > > time allows we can test it on this target. > Thanks. Any feedback would be really appreciated. > > > I am more personally interested to TMS570. > > I think that I can find some time for testing on TMS570LS3137 > > if the instructions and code is declared to worth to test. > > I hope that I have all tools for this setup. > > > This has not been tested yet, I'm working on the build system to > streamline the process further. It would be great to get this port > tested. Please ping me if you have any build issues when testing (if > you happen to test before the build system update :) ). > > > > = > > Side note to TMS570 FEE CTU code (if there is interest, > > I it would worth to move to separate thread) > > > > By the way, the way my former colleagues who left faculty > > stopped blocking (after many years) TMS570 Rapid Prototyping > > Platform code > > http://rtime.felk.cvut.cz/rpp-tms570/ > > and changed master branch license to MIT (The work has been > > exploited to gain money from their industrial partners and has > > little value for them now). Code was and is licensed under our > > faculty name and I can legally show it to third parties now > > and try to find arrangement to share my and my students effort > > with community. > > > > There is XCP https://en.wikipedia.org/wiki/XCP_(protocol) > > loader implemented on FreeRTOS base which allows to update > > firmware over ETHERNET so it can be used as boot block for > > RTEMS. It can make RTEMS support testing and even continuous > > integration much easier. When RTEMS is run from SDRAM it > > would prevent Flash wear-out, important for TMS570, > > because guaranteed erase cycles are limited. > > > > Then there is support for lot of the TMS570 peripherals > > in the state twisted with HalCoGen, not directly usable, > >
Re: [PATCH 04/41] rtems: Add rtems_interrupt_cause_on()
On 21/07/2021 20:10, Gedare Bloom wrote: One more thing, should we specifically say "on_processor" or something, to make it clear what this means? When I first read the function name, I thought it is "cause on a condition" so I was confused. Another thought with this "cause_on" directive, should we have an opaque type for the cpu_index? In the RTEMS API we use uint32_t currently. I think this is in line with other numbers such as a pending message count. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
> On 22 Jul 2021, at 6:53 pm, Sebastian Huber > wrote: >> On 22/07/2021 10:47, Chris Johns wrote: >>> On 22/7/21 6:37 pm, Sebastian Huber wrote: >>> On 22/07/2021 10:33, Chris Johns wrote: >> and so the arch part is not >> really needed. My concern is this type code ... >> >> https://git.rtems.org/rtems_waf/tree/rtems.py#n758 >> >> that breaks. Is this an issue? I think a single `/` in a BSP or family is >> cleaner. > Why is this an issue? This BSP family stuff is local to the RTEMS build > system. Currently. It is about the symmetry of the naming and how it would look from outside. Nothing more. >>> You mean that maybe someone wants to build an application or library for a >>> BSP >>> family? I guess this is currently not supported, but you could do this with >>> the >>> "bsps/powerpc/motorola_powerpc" approach. >> Yes it could happen and this is where the symmetry and the existing code >> matters. For example with `bsps/motorola_powerpc` the code can be easily or >> cleanly extended by looking for `bsps` as an arch and knowing that is a >> `family`. Otherwise the error is `invalid arch/bsp` and then you need check >> two >> lengths etc etc. > > If you want to add this feature, then you have to update the code anyway. You > have to figure out which BSPs belong to a family for example. Yeap. It is a detail but I am looking ahead. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/07/2021 10:47, Chris Johns wrote: On 22/7/21 6:37 pm, Sebastian Huber wrote: On 22/07/2021 10:33, Chris Johns wrote: and so the arch part is not really needed. My concern is this type code ... https://git.rtems.org/rtems_waf/tree/rtems.py#n758 that breaks. Is this an issue? I think a single `/` in a BSP or family is cleaner. Why is this an issue? This BSP family stuff is local to the RTEMS build system. Currently. It is about the symmetry of the naming and how it would look from outside. Nothing more. You mean that maybe someone wants to build an application or library for a BSP family? I guess this is currently not supported, but you could do this with the "bsps/powerpc/motorola_powerpc" approach. Yes it could happen and this is where the symmetry and the existing code matters. For example with `bsps/motorola_powerpc` the code can be easily or cleanly extended by looking for `bsps` as an arch and knowing that is a `family`. Otherwise the error is `invalid arch/bsp` and then you need check two lengths etc etc. If you want to add this feature, then you have to update the code anyway. You have to figure out which BSPs belong to a family for example. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/7/21 6:37 pm, Sebastian Huber wrote: > On 22/07/2021 10:33, Chris Johns wrote: and so the arch part is not really needed. My concern is this type code ... https://git.rtems.org/rtems_waf/tree/rtems.py#n758 that breaks. Is this an issue? I think a single `/` in a BSP or family is cleaner. >>> Why is this an issue? This BSP family stuff is local to the RTEMS build >>> system. >> Currently. It is about the symmetry of the naming and how it would look from >> outside. Nothing more. > > You mean that maybe someone wants to build an application or library for a BSP > family? I guess this is currently not supported, but you could do this with > the > "bsps/powerpc/motorola_powerpc" approach. Yes it could happen and this is where the symmetry and the existing code matters. For example with `bsps/motorola_powerpc` the code can be easily or cleanly extended by looking for `bsps` as an arch and knowing that is a `family`. Otherwise the error is `invalid arch/bsp` and then you need check two lengths etc etc. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
libbsd kernel namespace generation
Hello, Libbsd uses the pre-processor to map all the kernel calls into a libbsd kernel name space by prepending _bsd_ to each symbol. The script ... https://git.rtems.org/rtems-libbsd/tree/create-kernel-namespace.sh?h=6-freebsd-12 ... generates the list and the result is pushed into the repo. The symbols need to be regenerated when new sources are added into the `freebsd` tree. The script has a few issues: 1. Objdump does not work on FreeBSD for different archs. 2. Binutils is being removed from FreeBSD base. 3. A number of BSPs need to be built to cover all the possible symbols I would like to document the list of BSPs a generate needs to cover. I propose: arm/xilinx_zynq_a9_qemu aarch64/xilinx_versal_lp64_qemu i386/pc686 powerpc/mvme2307 sparc/erc32 Also the documentation says to use `git add -p` to add the changes. How does an interactive add help? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/07/2021 10:33, Chris Johns wrote: and so the arch part is not really needed. My concern is this type code ... https://git.rtems.org/rtems_waf/tree/rtems.py#n758 that breaks. Is this an issue? I think a single `/` in a BSP or family is cleaner. Why is this an issue? This BSP family stuff is local to the RTEMS build system. Currently. It is about the symmetry of the naming and how it would look from outside. Nothing more. You mean that maybe someone wants to build an application or library for a BSP family? I guess this is currently not supported, but you could do this with the "bsps/powerpc/motorola_powerpc" approach. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/7/21 4:44 pm, Sebastian Huber wrote: > On 22/07/2021 08:37, Chris Johns wrote: >> On 22/7/21 4:20 pm, Sebastian Huber wrote: >>> On 22/07/2021 02:39, Chris Johns wrote: On 22/7/21 5:22 am, Sebastian Huber wrote: > BSP family and BSP variant names may be equal. This prefix avoids > ambiguity in the enabled-by expressions. > --- > wscript | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/wscript b/wscript > index f27dba6831..b7a0412150 100755 > --- a/wscript > +++ b/wscript > @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, > top_group, variant): > conf.env["ENABLE"] = [ > get_compiler(conf, cp, variant), > arch, > - arch_family, > + "family/" + arch_family, "bsps/" + arch_family, ... as discussed in the other thread? If you are happy with the change as shown please push. >>> >>> Yes, this is good and matches with our directory layout. I checked it in >>> with >>> this change. >>> >>> We could also merge the default-by-family and default-by-variant lists with >>> this >>> approach, >> >> I am not sure. My initial reaction was "yes" but how would different settings >> for a BSP and a family be handled? I am assuming a BSP variant setting is >> able >> to override a family setting. Is that possible if they are merged? > > Yes, a BSP variant would have higher priority, this is enforced by the search > order: > > for default in self.data["default-by-variant"]: > if OptionItem._is_variant(default["variants"], variant): > value = default["value"] > break > for default in self.data["default-by-family"]: > if OptionItem._is_variant(default["families"], family): > value = default["value"] > break Then I am fine with the merging back to a single default-by-variant. >>> for example: >>> >>> diff --git a/spec/build/bsps/optconsolebaud.yml >>> b/spec/build/bsps/optconsolebaud.yml >>> index 4b0869beca..0233fdd61b 100644 >>> --- a/spec/build/bsps/optconsolebaud.yml >>> +++ b/spec/build/bsps/optconsolebaud.yml >>> @@ -6,13 +6,10 @@ build-type: option >>> copyrights: >>> - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) >>> default: 115200 >>> -default-by-family: >>> -- value: 9600 >>> - families: >>> - - powerpc/motorola_powerpc >>> default-by-variant: >>> - value: 9600 >>> variants: >>> + - bsps/powerpc/motorola_powerpc >> >> Oh I think my patch piece may have been wrong. This has two `/` and so three >> components. We _must_ have unique family names > > The BSP family names are just names in an architecture directory, so this rule > would be not enforced by the directory layout. Sure and that fine. >> and so the arch part is not >> really needed. My concern is this type code ... >> >> https://git.rtems.org/rtems_waf/tree/rtems.py#n758 >> >> that breaks. Is this an issue? I think a single `/` in a BSP or family is >> cleaner. > > Why is this an issue? This BSP family stuff is local to the RTEMS build > system. Currently. It is about the symmetry of the naming and how it would look from outside. Nothing more. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 20/41] sparc/irq: Implement new interrupt directives
On 22/07/2021 08:43, Chris Johns wrote: On 22/7/21 5:08 am, Sebastian Huber wrote: On 21/07/2021 21:04, Gedare Bloom wrote: On Wed, Jul 21, 2021 at 12:31 PM Sebastian Huber wrote: On 21/07/2021 20:28, Gedare Bloom wrote: Why not throw an error here instead? In production, you wouldn't want this code... The main issue is the bad chip design. If we don't have this code, we can't test the extended interrupts. In production, you want tested code. ok, thanks. My comments are all pretty minor, except for the terminology issues of "cause" but that wording already exists. post the v2 series, but I probably won't review it and you can check it in if no one complains. It's up to you if you want to work a different wording than "cause" -- I prefer "raise" Thanks a lot for the review. Joel, what is your opinion with respect to "cause" vs. "raise"? I think `raise`. Ok, great. I will replace "cause" with "raise" and send a v3 version of the patch set. I think we should remove the unimplemented rtems_interrupt_cause(). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/07/2021 08:37, Chris Johns wrote: On 22/7/21 4:20 pm, Sebastian Huber wrote: On 22/07/2021 02:39, Chris Johns wrote: On 22/7/21 5:22 am, Sebastian Huber wrote: BSP family and BSP variant names may be equal. This prefix avoids ambiguity in the enabled-by expressions. --- wscript | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wscript b/wscript index f27dba6831..b7a0412150 100755 --- a/wscript +++ b/wscript @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, top_group, variant): conf.env["ENABLE"] = [ get_compiler(conf, cp, variant), arch, - arch_family, + "family/" + arch_family, "bsps/" + arch_family, ... as discussed in the other thread? If you are happy with the change as shown please push. Yes, this is good and matches with our directory layout. I checked it in with this change. We could also merge the default-by-family and default-by-variant lists with this approach, I am not sure. My initial reaction was "yes" but how would different settings for a BSP and a family be handled? I am assuming a BSP variant setting is able to override a family setting. Is that possible if they are merged? Yes, a BSP variant would have higher priority, this is enforced by the search order: for default in self.data["default-by-variant"]: if OptionItem._is_variant(default["variants"], variant): value = default["value"] break for default in self.data["default-by-family"]: if OptionItem._is_variant(default["families"], family): value = default["value"] break for example: diff --git a/spec/build/bsps/optconsolebaud.yml b/spec/build/bsps/optconsolebaud.yml index 4b0869beca..0233fdd61b 100644 --- a/spec/build/bsps/optconsolebaud.yml +++ b/spec/build/bsps/optconsolebaud.yml @@ -6,13 +6,10 @@ build-type: option copyrights: - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) default: 115200 -default-by-family: -- value: 9600 - families: - - powerpc/motorola_powerpc default-by-variant: - value: 9600 variants: + - bsps/powerpc/motorola_powerpc Oh I think my patch piece may have been wrong. This has two `/` and so three components. We _must_ have unique family names The BSP family names are just names in an architecture directory, so this rule would be not enforced by the directory layout. and so the arch part is not really needed. My concern is this type code ... https://git.rtems.org/rtems_waf/tree/rtems.py#n758 that breaks. Is this an issue? I think a single `/` in a BSP or family is cleaner. Why is this an issue? This BSP family stuff is local to the RTEMS build system. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 20/41] sparc/irq: Implement new interrupt directives
On 22/7/21 5:08 am, Sebastian Huber wrote: > On 21/07/2021 21:04, Gedare Bloom wrote: >> On Wed, Jul 21, 2021 at 12:31 PM Sebastian Huber >> wrote: >>> On 21/07/2021 20:28, Gedare Bloom wrote: Why not throw an error here instead? In production, you wouldn't want this code... >>> The main issue is the bad chip design. If we don't have this code, we >>> can't test the extended interrupts. In production, you want tested code. >>> >> ok, thanks. My comments are all pretty minor, except for the >> terminology issues of "cause" but that wording already exists. post >> the v2 series, but I probably won't review it and you can check it in >> if no one complains. It's up to you if you want to work a different >> wording than "cause" -- I prefer "raise" > > Thanks a lot for the review. > > Joel, what is your opinion with respect to "cause" vs. "raise"? > I think `raise`. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/7/21 4:20 pm, Sebastian Huber wrote: > On 22/07/2021 02:39, Chris Johns wrote: >> On 22/7/21 5:22 am, Sebastian Huber wrote: >>> BSP family and BSP variant names may be equal. This prefix avoids >>> ambiguity in the enabled-by expressions. >>> --- >>> wscript | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/wscript b/wscript >>> index f27dba6831..b7a0412150 100755 >>> --- a/wscript >>> +++ b/wscript >>> @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, >>> top_group, variant): >>> conf.env["ENABLE"] = [ >>> get_compiler(conf, cp, variant), >>> arch, >>> - arch_family, >>> + "family/" + arch_family, >> "bsps/" + arch_family, >> >> ... as discussed in the other thread? If you are happy with the change as >> shown >> please push. > > Yes, this is good and matches with our directory layout. I checked it in with > this change. > > We could also merge the default-by-family and default-by-variant lists with > this > approach, I am not sure. My initial reaction was "yes" but how would different settings for a BSP and a family be handled? I am assuming a BSP variant setting is able to override a family setting. Is that possible if they are merged? > for example: > > diff --git a/spec/build/bsps/optconsolebaud.yml > b/spec/build/bsps/optconsolebaud.yml > index 4b0869beca..0233fdd61b 100644 > --- a/spec/build/bsps/optconsolebaud.yml > +++ b/spec/build/bsps/optconsolebaud.yml > @@ -6,13 +6,10 @@ build-type: option > copyrights: > - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) > default: 115200 > -default-by-family: > -- value: 9600 > - families: > - - powerpc/motorola_powerpc > default-by-variant: > - value: 9600 > variants: > + - bsps/powerpc/motorola_powerpc Oh I think my patch piece may have been wrong. This has two `/` and so three components. We _must_ have unique family names and so the arch part is not really needed. My concern is this type code ... https://git.rtems.org/rtems_waf/tree/rtems.py#n758 that breaks. Is this an issue? I think a single `/` in a BSP or family is cleaner. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add "family/" prefix to BSP familiy enable
On 22/07/2021 02:39, Chris Johns wrote: On 22/7/21 5:22 am, Sebastian Huber wrote: BSP family and BSP variant names may be equal. This prefix avoids ambiguity in the enabled-by expressions. --- wscript | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wscript b/wscript index f27dba6831..b7a0412150 100755 --- a/wscript +++ b/wscript @@ -1394,7 +1394,7 @@ def configure_variant(conf, cp, bsp_map, path_list, top_group, variant): conf.env["ENABLE"] = [ get_compiler(conf, cp, variant), arch, -arch_family, +"family/" + arch_family, "bsps/" + arch_family, ... as discussed in the other thread? If you are happy with the change as shown please push. Yes, this is good and matches with our directory layout. I checked it in with this change. We could also merge the default-by-family and default-by-variant lists with this approach, for example: diff --git a/spec/build/bsps/optconsolebaud.yml b/spec/build/bsps/optconsolebaud.yml index 4b0869beca..0233fdd61b 100644 --- a/spec/build/bsps/optconsolebaud.yml +++ b/spec/build/bsps/optconsolebaud.yml @@ -6,13 +6,10 @@ build-type: option copyrights: - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) default: 115200 -default-by-family: -- value: 9600 - families: - - powerpc/motorola_powerpc default-by-variant: - value: 9600 variants: + - bsps/powerpc/motorola_powerpc - m68k/m5484FireEngine - powerpc/hsc_cm01 - powerpc/beatnik -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
