Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers
On 2/6/21 4:20 am, Christian Mauderer wrote: > On 01/06/2021 19:24, Gedare Bloom wrote: >> On Mon, May 10, 2021 at 11:26 AM Jan Sommer wrote: >>> >>> Hello, >>> >>> This is a follow-up on this discussion regarding the installed header files >>> in libbsd: https://lists.rtems.org/pipermail/devel/2021-April/066211.html >>> >>> The current situation is, that for example for all machines the bus.h is >>> installed from >>> within the rtemsbsd directory >>> (https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/bus.h). >>> >>> According to the file docu it originates from the amd64 version of this >>> file. >>> It also has the following section in it which we ran into when compiling >>> Chris' ptpd2 archive: >>> >>> #ifdef __i386__ >>> #error "your include paths are wrong" >>> #endif >>> >>> This patchset does the following: >>> - Add the target dependent machine include directory to 'header-paths' in >>> libbsd.py >>> - Import (mostly) '_bus.h', 'bus.h' and 'cpufunc.h' for the targets from >>> freebsd-org >>> - Remove those header files from rtemsbsd directory >>> >>> As a result the matching versions for machine dependent header files are now >>> installed >>> for each BSP. >>> Would this be an acceptable solution? >>> >>> So far I compiled some BSPs for i386, arm, aarch64, powerpc, riscv, sparc >>> and >>> sparc64 to check that they still compile after the changes. >>> Are there any other architectures which should be included? > > I think the best starting point to find out the minimum supported platforms is > the nexus-devices.h. At least the officially supported BSPs should have an > entry > there. That is: > > #if defined(LIBBSP_ARM_REALVIEW_PBX_A9_BSP_H) > #elif defined(LIBBSP_ARM_BEAGLE_BSP_H) > #elif defined(LIBBSP_ARM_LPC32XX_BSP_H) > #elif defined(LIBBSP_M68K_GENMCF548X_BSP_H) > #elif defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) > #elif defined(LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H) > #elif defined(LIBBSP_ARM_ATSAM_BSP_H) > #elif defined(LIBBSP_ARM_ALTERA_CYCLONE_V_BSP_H) > #elif defined(LIBBSP_ARM_IMX_BSP_H) > #elif defined(LIBBSP_ARM_IMXRT_BSP_H) > #elif defined(LIBBSP_ARM_LPC24XX_BSP_H) > #elif defined(LIBBSP_ARM_STM32H7_BSP_H) > #elif defined(LIBBSP_I386_PC386_BSP_H) > #elif defined(LIBBSP_POWERPC_QORIQ_BSP_H) > #elif defined(LIBBSP_POWERPC_TQM8XX_BSP_H) > #elif defined(LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H) > > So I think you should have a look at m68k too. > > Did you try to run it on any of the platforms? > >>> >>> I ran into one problem regarding the compilation of >>> rtemsbsd/sys/dev/dw_mmc/dw_mmc.c:105 >>> return (bus_space_read_4(0, sc->bushandle, off)); >>> >>> The first parameter creates an error for riscv (I think because >>> dereferencing >>> a NULL pointer). >>> Are there any suggestion how to solve it (I am not familiar with the bus >>> space and there is a lot of macro magic going on)? >>> >> It looks like this will be a problem for any architecture. so should >> the function that calls bus_space_write_4(0 ...) >> The macro trail goes... >> >> #define __bs_rs(sz, t, h, o) >> \ >> (*(t)->__bs_opname(r,sz))((t)->bs_cookie, h, o) >> >> #define bus_space_read_4(t, h, o) __bs_rs(4,(t),(h),(o)) >> >> so t is dereferenced. It appears to be an error in the API usage by >> the dw_mmc.c code to not specify a valid bus space. > > dw_mmc is only relevant for very few platforms. So in theory it could be > limited > to these. But most likely that won't really solve the problem. > > The right answer is that dw_mmc doesn't use the API like intended (like Gedare > said). That could be a problem for more drivers that use stuff from bus.h in > rtemsbsd. They never had to use that API correctly. Even worse: Some of the > __rtems__ hacks in freebsd could have that problem too. > > I think for this patch set we either need to have a thorough look at these > locations or run (not only build) it on a number of platforms, especially the > ones with special drivers in rtemsbsd or with heavily adapted drivers. The only arch that supports a tag we current have is the x86 and that is for IO vs mem space. I posted some patches earlier this year I need to revisit for the powerpc (mvme2700). If possible we prefer no tags and a single flat address space that is cache coherent. In the x86 tags cannot be avoided and supported drivers handle the tags correctly. Be-careful reviewing FreeBSD's bus space implementations. For example the PowerPC support uses tables of calls and we do not need that overhead. The issue here is using this driver on the x86 platform. Until that happens I am fine with the tag being 0. The API requires something even if it is not used. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
POSIX Issue 8 Draft and _POSIX_VERSION
Hi Over in RTEMS, we have a GSoC student looking at adding the new methods called out in the draft Issue 8. The first step would be adding prototypes for these. I assume these would be guarded by _POSIX_VERSION with the appropriate value. If all this much is correct, then the stumbling block is... Unfortunately, the actual value for _POSIX_VERSION is 20yymmL.in the current draft. Any suggestions on what to set it if we submit patches before the standard is finalized? Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers
On 01/06/2021 19:24, Gedare Bloom wrote: On Mon, May 10, 2021 at 11:26 AM Jan Sommer wrote: Hello, This is a follow-up on this discussion regarding the installed header files in libbsd: https://lists.rtems.org/pipermail/devel/2021-April/066211.html The current situation is, that for example for all machines the bus.h is installed from within the rtemsbsd directory (https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/bus.h). According to the file docu it originates from the amd64 version of this file. It also has the following section in it which we ran into when compiling Chris' ptpd2 archive: #ifdef __i386__ #error "your include paths are wrong" #endif This patchset does the following: - Add the target dependent machine include directory to 'header-paths' in libbsd.py - Import (mostly) '_bus.h', 'bus.h' and 'cpufunc.h' for the targets from freebsd-org - Remove those header files from rtemsbsd directory As a result the matching versions for machine dependent header files are now installed for each BSP. Would this be an acceptable solution? So far I compiled some BSPs for i386, arm, aarch64, powerpc, riscv, sparc and sparc64 to check that they still compile after the changes. Are there any other architectures which should be included? I think the best starting point to find out the minimum supported platforms is the nexus-devices.h. At least the officially supported BSPs should have an entry there. That is: #if defined(LIBBSP_ARM_REALVIEW_PBX_A9_BSP_H) #elif defined(LIBBSP_ARM_BEAGLE_BSP_H) #elif defined(LIBBSP_ARM_LPC32XX_BSP_H) #elif defined(LIBBSP_M68K_GENMCF548X_BSP_H) #elif defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H) #elif defined(LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H) #elif defined(LIBBSP_ARM_ATSAM_BSP_H) #elif defined(LIBBSP_ARM_ALTERA_CYCLONE_V_BSP_H) #elif defined(LIBBSP_ARM_IMX_BSP_H) #elif defined(LIBBSP_ARM_IMXRT_BSP_H) #elif defined(LIBBSP_ARM_LPC24XX_BSP_H) #elif defined(LIBBSP_ARM_STM32H7_BSP_H) #elif defined(LIBBSP_I386_PC386_BSP_H) #elif defined(LIBBSP_POWERPC_QORIQ_BSP_H) #elif defined(LIBBSP_POWERPC_TQM8XX_BSP_H) #elif defined(LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H) So I think you should have a look at m68k too. Did you try to run it on any of the platforms? I ran into one problem regarding the compilation of rtemsbsd/sys/dev/dw_mmc/dw_mmc.c:105 return (bus_space_read_4(0, sc->bushandle, off)); The first parameter creates an error for riscv (I think because dereferencing a NULL pointer). Are there any suggestion how to solve it (I am not familiar with the bus space and there is a lot of macro magic going on)? It looks like this will be a problem for any architecture. so should the function that calls bus_space_write_4(0 ...) The macro trail goes... #define__bs_rs(sz, t, h, o)\ (*(t)->__bs_opname(r,sz))((t)->bs_cookie, h, o) #definebus_space_read_4(t, h, o) __bs_rs(4,(t),(h),(o)) so t is dereferenced. It appears to be an error in the API usage by the dw_mmc.c code to not specify a valid bus space. dw_mmc is only relevant for very few platforms. So in theory it could be limited to these. But most likely that won't really solve the problem. The right answer is that dw_mmc doesn't use the API like intended (like Gedare said). That could be a problem for more drivers that use stuff from bus.h in rtemsbsd. They never had to use that API correctly. Even worse: Some of the __rtems__ hacks in freebsd could have that problem too. I think for this patch set we either need to have a thorough look at these locations or run (not only build) it on a number of platforms, especially the ones with special drivers in rtemsbsd or with heavily adapted drivers. Also, I am not sure if I always added the header files in the right module in libbsd.py. Any suggestions where to put them instead would be welcome. Best regards, Jan Jan Sommer (2): rtemsbd: Remove machine dependent files and use the ones from freebsd machine: Add machine dependent header files to libbsd.py freebsd/sys/arm/include/machine/_bus.h| 47 + freebsd/sys/arm/include/machine/bus.h | 769 freebsd/sys/arm64/include/machine/_bus.h | 46 + freebsd/sys/arm64/include/machine/bus.h | 469 ++ freebsd/sys/powerpc/include/machine/_bus.h| 50 + freebsd/sys/powerpc/include/machine/bus.h | 467 ++ freebsd/sys/riscv/include/machine/_bus.h | 46 + freebsd/sys/riscv/include/machine/bus.h | 469 ++ freebsd/sys/riscv/include/machine/cpufunc.h | 135 +++ freebsd/sys/riscv/include/machine/riscvreg.h | 246 + .../sys/sparc}/include/machine/_bus.h | 0 .../sys/sparc}/include/machine/bus.h | 0 freebsd/sys/sparc/include/machine/cpufunc.h | 0 freebsd/sys/sparc64/include/machine/_bus.h| 41 + freebsd/sys/sparc64/include/machine/bus.h | 852 ++
Re: [PATCH] cpukit/libdebugger: Fix for sockaddr_in not being initialized
This looks like it should fix the issue.
OK to push.
On Tue, Jun 1, 2021 at 1:06 PM Harrison Edward Gerber
wrote:
> From: Harrison Edward Gerber
>
> See also CID 1468684
>
> Closes #4445
> ---
> cpukit/libdebugger/rtems-debugger-remote-tcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/libdebugger/rtems-debugger-remote-tcp.c
> b/cpukit/libdebugger/rtems-debugger-remote-tcp.c
> index 696e2deb8c..440baa9b66 100644
> --- a/cpukit/libdebugger/rtems-debugger-remote-tcp.c
> +++ b/cpukit/libdebugger/rtems-debugger-remote-tcp.c
> @@ -122,7 +122,7 @@ static int
> tcp_remote_connect(rtems_debugger_remote* remote)
> {
>intld;
> - struct sockaddr_in addr;
> + struct sockaddr_in addr = {0};
>socklen_t opt;
>socklen_t len;
>bool running;
> --
> 2.25.1
>
> ___
> 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
[PATCH] cpukit/libdebugger: Fix for sockaddr_in not being initialized
From: Harrison Edward Gerber
See also CID 1468684
Closes #4445
---
cpukit/libdebugger/rtems-debugger-remote-tcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libdebugger/rtems-debugger-remote-tcp.c
b/cpukit/libdebugger/rtems-debugger-remote-tcp.c
index 696e2deb8c..440baa9b66 100644
--- a/cpukit/libdebugger/rtems-debugger-remote-tcp.c
+++ b/cpukit/libdebugger/rtems-debugger-remote-tcp.c
@@ -122,7 +122,7 @@ static int
tcp_remote_connect(rtems_debugger_remote* remote)
{
intld;
- struct sockaddr_in addr;
+ struct sockaddr_in addr = {0};
socklen_t opt;
socklen_t len;
bool running;
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers
On Mon, May 10, 2021 at 11:26 AM Jan Sommer wrote:
>
> Hello,
>
> This is a follow-up on this discussion regarding the installed header files
> in libbsd: https://lists.rtems.org/pipermail/devel/2021-April/066211.html
>
> The current situation is, that for example for all machines the bus.h is
> installed from
> within the rtemsbsd directory
> (https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/bus.h).
>
> According to the file docu it originates from the amd64 version of this file.
> It also has the following section in it which we ran into when compiling
> Chris' ptpd2 archive:
>
> #ifdef __i386__
> #error "your include paths are wrong"
> #endif
>
> This patchset does the following:
> - Add the target dependent machine include directory to 'header-paths' in
> libbsd.py
> - Import (mostly) '_bus.h', 'bus.h' and 'cpufunc.h' for the targets from
> freebsd-org
> - Remove those header files from rtemsbsd directory
>
> As a result the matching versions for machine dependent header files are now
> installed
> for each BSP.
> Would this be an acceptable solution?
>
> So far I compiled some BSPs for i386, arm, aarch64, powerpc, riscv, sparc and
> sparc64 to check that they still compile after the changes.
> Are there any other architectures which should be included?
>
> I ran into one problem regarding the compilation of
> rtemsbsd/sys/dev/dw_mmc/dw_mmc.c:105
>
> > return (bus_space_read_4(0, sc->bushandle, off));
>
> The first parameter creates an error for riscv (I think because dereferencing
> a NULL pointer).
> Are there any suggestion how to solve it (I am not familiar with the bus
> space and there is a lot of macro magic going on)?
>
It looks like this will be a problem for any architecture. so should
the function that calls bus_space_write_4(0 ...)
The macro trail goes...
#define__bs_rs(sz, t, h, o)\
(*(t)->__bs_opname(r,sz))((t)->bs_cookie, h, o)
#definebus_space_read_4(t, h, o) __bs_rs(4,(t),(h),(o))
so t is dereferenced. It appears to be an error in the API usage by
the dw_mmc.c code to not specify a valid bus space.
> Also, I am not sure if I always added the header files in the right
> module in libbsd.py. Any suggestions where to put them instead would be
> welcome.
>
> Best regards,
>
> Jan
>
> Jan Sommer (2):
> rtemsbd: Remove machine dependent files and use the ones from freebsd
> machine: Add machine dependent header files to libbsd.py
>
> freebsd/sys/arm/include/machine/_bus.h| 47 +
> freebsd/sys/arm/include/machine/bus.h | 769
> freebsd/sys/arm64/include/machine/_bus.h | 46 +
> freebsd/sys/arm64/include/machine/bus.h | 469 ++
> freebsd/sys/powerpc/include/machine/_bus.h| 50 +
> freebsd/sys/powerpc/include/machine/bus.h | 467 ++
> freebsd/sys/riscv/include/machine/_bus.h | 46 +
> freebsd/sys/riscv/include/machine/bus.h | 469 ++
> freebsd/sys/riscv/include/machine/cpufunc.h | 135 +++
> freebsd/sys/riscv/include/machine/riscvreg.h | 246 +
> .../sys/sparc}/include/machine/_bus.h | 0
> .../sys/sparc}/include/machine/bus.h | 0
> freebsd/sys/sparc/include/machine/cpufunc.h | 0
> freebsd/sys/sparc64/include/machine/_bus.h| 41 +
> freebsd/sys/sparc64/include/machine/bus.h | 852 ++
> libbsd.py | 26 +-
> rtemsbsd/include/machine/cpufunc.h| 1 -
> waf_libbsd.py | 2 -
> 18 files changed, 3660 insertions(+), 6 deletions(-)
> create mode 100644 freebsd/sys/arm/include/machine/_bus.h
> create mode 100644 freebsd/sys/arm/include/machine/bus.h
> create mode 100644 freebsd/sys/arm64/include/machine/_bus.h
> create mode 100644 freebsd/sys/arm64/include/machine/bus.h
> create mode 100644 freebsd/sys/powerpc/include/machine/_bus.h
> create mode 100644 freebsd/sys/powerpc/include/machine/bus.h
> create mode 100644 freebsd/sys/riscv/include/machine/_bus.h
> create mode 100644 freebsd/sys/riscv/include/machine/bus.h
> create mode 100644 freebsd/sys/riscv/include/machine/cpufunc.h
> create mode 100644 freebsd/sys/riscv/include/machine/riscvreg.h
> rename {rtemsbsd => freebsd/sys/sparc}/include/machine/_bus.h (100%)
> rename {rtemsbsd => freebsd/sys/sparc}/include/machine/bus.h (100%)
> create mode 100644 freebsd/sys/sparc/include/machine/cpufunc.h
> create mode 100644 freebsd/sys/sparc64/include/machine/_bus.h
> create mode 100644 freebsd/sys/sparc64/include/machine/bus.h
> delete mode 100644 rtemsbsd/include/machine/cpufunc.h
>
> --
> 2.17.1
>
> ___
> 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 - Code Formatting and Style Checking for RTEMS score
On Mon, May 31, 2021 at 2:59 PM Ida Delphine wrote:
>
> Hi Gedare,
>
> With regards to your comment on discord on me looking for a tool that works
> on both patches and source files, it turns out clang-format has that
> functionality already. Here's what I found -
> https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting
>
> Does it match what you have in mind?
>
Yes. I think we would want to not use the `-i` option but instead pass
through and check the changes. I don't think we should rewrite the
patches themselves, but instead we want to use a tool that can be used
to check and approve the style of submitted patches. You might need to
write a modified version of the clang-format-diff.py to use as a
"checker" with ability to provide exceptions to the rules.
Gedare
> On Thu, May 13, 2021 at 3:49 PM Gedare Bloom wrote:
>>
>> On Wed, May 12, 2021 at 2:18 PM Ida Delphine wrote:
>> >
>> > Hello everyone,
>> > Still waiting for some feedback :)
>> >
>> > Cheers,
>> > Ida.
>> >
>> > On Mon, 10 May 2021, 5:59 am Ida Delphine, wrote:
>> >>
>> >> Hello everyone,
>> >> Went through some previous emails and it turns out Sebastian already came
>> >> up with a configuration for clang format which works well for RTEMS
>> >> except for the fact that some configurations haven't been implemented
>> >> into clang-format yet. Using
>> >>
>> >> AlignConsecutiveDeclarations: false
>> >> PointerAlignment: Right
>> >>
>> >> Doesn't seem to work.
>> >> For example in the cpukit/score/src/threadq.c file, something like
>> >>
>> >> RTEMS_STATIC_ASSERT(
>> >> offsetof( Thread_queue_Syslock_queue, Queue.name )
>> >> == offsetof( struct _Thread_queue_Queue, _name ),
>> >> THREAD_QUEUE_SYSLOCK_QUEUE_NAME
>> >> );
>> >>
>> >> RTEMS_STATIC_ASSERT(
>> >> sizeof( Thread_queue_Syslock_queue )
>> >> == sizeof( struct _Thread_queue_Queue ),
>> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE
>> >> );
>> >>
>> >> #if defined(RTEMS_SMP)
>> >> void _Thread_queue_Do_acquire_critical(
>> >> Thread_queue_Control *the_thread_queue,
>> >> ISR_lock_Context *lock_context
>> >> )
>> >> {
>> >> _Thread_queue_Queue_acquire_critical(
>> >> _thread_queue->Queue,
>> >> _thread_queue->Lock_stats,
>> >> lock_context
>> >> );
>> >>
>> >> becomes this after using the given configuration
>> >>
>> >> RTEMS_STATIC_ASSERT(sizeof(Thread_queue_Syslock_queue) ==
>> >> sizeof(struct _Thread_queue_Queue),
>> >> THREAD_QUEUE_SYSLOCK_QUEUE_SIZE);
>> >>
>> >> #if defined(RTEMS_SMP)
>> >> void _Thread_queue_Do_acquire_critical(Thread_queue_Control
>> >> *the_thread_queue,
>> >> ISR_lock_Context *lock_context) {
>> >> _Thread_queue_Queue_acquire_critical(
>> >> _thread_queue->Queue, _thread_queue->Lock_stats, lock_context);
>> >>
>> >> Everything seems manageable except for this alignment issue...
>> >> This also throws more light on the changes using clang-format
>> >> (https://lists.rtems.org/pipermail/devel/2018-December/024145.html)
>> >>
>> I think we're willing to concede the pointer alignment. However, it
>> would be worth spending some time to see if
>> https://reviews.llvm.org/D27651 can be made to work. The current state
>> of the code would need to be compared to the patch on that review
>> board.
>>
>> Beyond that, documenting the clang-format options to use is next, and
>> then identifying a plan how to invoke clang-format during a git
>> workflow is needed.
>>
>> >> On Thu, May 6, 2021 at 8:05 PM Joel Sherrill wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Thu, May 6, 2021 at 12:47 PM Christian Mauderer
>> >>> wrote:
>>
>> Hello Ida and Gedare,
>>
>> On 06/05/2021 06:26, Gedare Bloom wrote:
>> > hi Ida,
>> >
>> > On Wed, May 5, 2021 at 3:21 PM Ida Delphine wrote:
>> >>
>> >> Hello everyone,
>> >>
>> >> Regarding this project (https://devel.rtems.org/ticket/3860) I went
>> >> with clang-format as we all agreed. I have tested it on some "score"
>> >> files and it made some changes which I don't think are very much in
>> >> line with the RTEMS coding style. However, it wasn't really clear if
>> >> we will chage the RTEMS coding style or try to make changes to
>> >> clang-format to fit the style.
>> >> Please will love to know the best option.
>> >>
>> > We will likely need to consider our choices carefully. If we can find
>> > a suitably close style that is already well-supported by clang, and
>> > get consensus from the maintainers on a change, then that might be the
>> > best route forward.
>>
>> +1
>>
>> > I think the first thing to do is take the examples
>> > that have been shown by Sebastian that are "close" but not quite
>> > perfect, and identify the cases where they differ with RTEMS style in
>> > order to present for discussion here. If consensus can't be reached to
>> > change the style, then we would need to have a plan for how to improve
>> > the existing tools for what we have.
Improve SMP support for PC BSP
Hello, Currently the pc BSP in SMP mode uses a timer interrupt on cpu0 which is then distributed to all other cores via an IPI for the scheduler tick. This means, if cpu0 locally disables its interrupts (e.g. in a driver), all schedulers lose their sense of time. Worst case this could lead to a hanging system, e.g. like in the test smpclock01 (https://devel.rtems.org/ticket/4008). The clockdriver uses the PIT and as far as I understand it, it is only possible to create a global timer interrupt with the PIT and not simultaneous interrupts for each core (please correct me if I am wrong). I started reading into possible solutions and as with everything x86-related, it is a bit messy. So my propsed steps forward would be the following: 1. Update the CPU feature recognition: - The next steps need to know about the availability of more modern features. So, I would port the identcpu.c (and possibly the tsc.c) from FreeBSD to RTEMS. I have done this for testing already and seems to be quite straight forward. 2. For RTEMS_SMP: Implement clockdriver for the Local APIC with TSC_DEADLINE mode - If the TSC_DEADLINE mode is available (i.e. on newer Intel processors (2013+)) this is probably the easiest and most accurate method. The TSC rate on these processors is invariant and synchronized across all cores during reset (unless the BIOS does something stupid after reset). Creating a clock driver for that using the Local APIC should be fairly straight forward. Maybe the TSC calibration routine could be improved a bit. We also have corresponding hardware here for testing. In general I think for SMP we should require invariant TSCs, so that rtems_get_uptime and similar methods are in line across cores. 3. For RTEMS_SMP: Implement clockdriver for Local APIC without TSC_DEADLINE mode - For older or non-Intel processors the TSC_DEADLINE mode is not available. As far as I see it, the most reasonable option would be to use the LAPIC timer in periodic mode. To do that, I would first need to calibrate the rate of the Local APIC timer with the PIT, similar to the TSC. The rate of the LAPIC is the same across all cpu cores, the trouble is then the sychronization of the timer interrupt between all LAPICs of all cores. I found this Master thesis which discusses synchronization via atomic variables with formulas derived from PTP: https://core.ac.uk/download/pdf/302914733.pdf It looks like this could synchronize the LAPIC timers across the cores reasonably well. At the very least it should be an improvement compared to the distribution using the IPIs. However, this work would not be required by our projects, so I have to see how to find some spare time for the implementation. Anyways, would you see this as a viable solution? Or do you see any pitfalls I might have overlooked? Best regards, Jan Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace Center Institute for Software Technology | Software for Space Systems and Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
