Re: bsps/xilinx-zynqmp : Add BSP for RPU

2023-06-14 Thread Aaron Nyholm 
This looks exciting.

As for Versal support from Xilinx's Docs "RPU

The real-time processing unit (RPU) Arm Cortex-R5F processor has faster 
clocking frequencies than the Zynq UltraScale+ MPSoC. The Versal Arm Cortex-R5F 
processor supports Vector Floating-Point v3 (VFPv3) whereas the Zynq 
UltraScale+ MPSoC Arm Cortex-R5F processor supports VFPv2." 
https://docs.xilinx.com/r/en-US/ug1273-versal-acap-design/RPU

VFPv3 is backwards compatible with VFPv2 
(https://developer.arm.com/documentation/ddi0344/d/programmer-s-model/vfpv3-architecture?lang=en).

So hopefully reuse for the Versal should relativity straight forward.

Side note, even though Xilinx says the R5F in the ZynqMP has VFPv2, ARM says to 
compile with vfpv3_d16 like what is already in the BSP 
(https://developer.arm.com/documentation/dui0472/i/CIHGDBHC).

Thanks, Aaron


--- Original Message ---
On Thursday, June 15th, 2023 at 9:17 AM, Chris Johns  wrote:


> 
> 
> On 14/6/2023 6:08 pm, Philip Kirkpatrick wrote:
> 
> > This patch adds support for running RTEMS on the RPU (cortex R5) cores of 
> > the
> > ZynqMP.
> 
> 
> Thanks for submitting this BSP. It is exciting to see this work and support
> being added.
> 
> How different are the ZynqMP RPU cores and the ones on the Versal?
> 
> I have not looked in detail but I know they are both R5 devices and I think we
> should be able to reuse this support. Is placing the RPU pieces under the 
> ZynqMP
> sources what we want or should we consider how we would reuse the RPU BSP on
> other Xilinx devices?
> 
> I am leading with this question without reviewing the sources in detail so I
> apologise for this. I am happy to look at Versal support so I am not asking 
> that
> to be done.
> 
> Chris
> ___
> 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] rtemsbsd/versal_slcr: Fix Versal GEM clock set

2023-06-14 Thread aaron . nyholm 
From: Aaron Nyholm 

---
 rtemsbsd/sys/arm64/xilinx/versal_slcr.c | 34 ++---
 rtemsbsd/sys/arm64/xilinx/versal_slcr.h |  6 +
 2 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/rtemsbsd/sys/arm64/xilinx/versal_slcr.c 
b/rtemsbsd/sys/arm64/xilinx/versal_slcr.c
index 74ebde91..1f4d48bc 100644
--- a/rtemsbsd/sys/arm64/xilinx/versal_slcr.c
+++ b/rtemsbsd/sys/arm64/xilinx/versal_slcr.c
@@ -78,10 +78,13 @@ SYSCTL_NODE(_hw, OID_AUTO, versal, CTLFLAG_RD, 0, "Xilinx 
Versal ACAP SLCR");
 int
 cgem_set_ref_clk(int unit, int frequency)
 {
+
struct versal_slcr_softc *sc = versal_slcr_softc_p;
int div, last_error = 0;
-   uint64_t clk_ctrl, pll_ctrl;
+   uint64_t clk_ctrl, pll_ctrl, to_xpd_ctrl;
uint32_t clk_ctrl_val, pll_ctrl_val, pll_freq, pll_reset, pll_bypass;
+   uint32_t clk_src_sel, to_xpd_ctrl_val, to_xpd_div, to_xpd_freq;
+
 
if (!sc)
return (-1);
@@ -126,15 +129,38 @@ cgem_set_ref_clk(int unit, int frequency)
}
 
/* Apply divider */
-  pll_freq >>= (pll_ctrl_val & VERSAL_SLCR_PLL_CTRL_DIV_MASK) >> 
VERSAL_SLCR_PLL_CTRL_DIV_SHIFT;
+   pll_freq >>= (pll_ctrl_val & VERSAL_SLCR_PLL_CTRL_DIV_MASK) >> 
VERSAL_SLCR_PLL_CTRL_DIV_SHIFT;
+
+   /* Check if routed through {X}PLL_TO_XPD_CLK to GEM{unit}_REF_CLK and 
adjust */
+   clk_src_sel = (clk_ctrl_val & VERSAL_SLCR_GEM_CLK_CTRL_SRCSEL_MASK);
+   to_xpd_ctrl = 0;
+   if (clk_src_sel == VERSAL_SLCR_GEM_CLK_CTRL_SRCSEL_P_PLL)
+   {
+   to_xpd_ctrl = VERSAL_SLCR_PPLL_TO_XPD_CTRL;
+   } else if (clk_src_sel == VERSAL_SLCR_GEM_CLK_CTRL_SRCSEL_N_PLL)
+   {
+   to_xpd_ctrl = VERSAL_SLCR_NPLL_TO_XPD_CTRL;
+   }
+
+   if (to_xpd_ctrl != 0) {
+   to_xpd_ctrl_val = RD4(sc, to_xpd_ctrl);
+   to_xpd_div = (to_xpd_ctrl_val & 
VERSAL_SLCR_XPD_CLK_CTRL_DIVISOR_MASK);
+   to_xpd_div = to_xpd_div >> VERSAL_SLCR_XPD_CTRL_DIV_SHIFT;
+   if (to_xpd_div == 0) {
+   to_xpd_div = 1;
+   }
+   to_xpd_freq = pll_freq / to_xpd_div;
+   } else {
+   to_xpd_freq = pll_freq;
+   }
 
/* Find suitable divisor. Linear search, not the fastest method but hey.
 */
for (div = 1; div <= VERSAL_SLCR_GEM_CLK_CTRL_DIVISOR_MAX; div++) {
-int div_freq = pll_freq / div;
+   int div_freq = to_xpd_freq / div;
int error = abs(frequency - div_freq);
if (error >= last_error && last_error != 0) {
-  div--;
+   div--;
break;
}
last_error = error;
diff --git a/rtemsbsd/sys/arm64/xilinx/versal_slcr.h 
b/rtemsbsd/sys/arm64/xilinx/versal_slcr.h
index e1c967ac..121c1e0a 100644
--- a/rtemsbsd/sys/arm64/xilinx/versal_slcr.h
+++ b/rtemsbsd/sys/arm64/xilinx/versal_slcr.h
@@ -78,6 +78,12 @@
 #define   VERSAL_SLCR_GEM_CLK_CTRL_SRCSEL_R_PLL(1<<0)
 #define   VERSAL_SLCR_GEM_CLK_CTRL_SRCSEL_N_PLL(3<<0)
 
+#define VERSAL_SLCR_PPLL_TO_XPD_CTRL   (VERSAL_SLCR_CRF_OFFSET + 0x100)
+#define VERSAL_SLCR_NPLL_TO_XPD_CTRL   (VERSAL_SLCR_CRF_OFFSET + 0x104)
+#define   VERSAL_SLCR_XPD_CLK_CTRL_DIVISOR_MAX 0x3ff
+#define   VERSAL_SLCR_XPD_CLK_CTRL_DIVISOR_MASK
(VERSAL_SLCR_XPD_CLK_CTRL_DIVISOR_MAX<<8)
+#define   VERSAL_SLCR_XPD_CTRL_DIV_SHIFT   8
+
 #define VERSAL_DEFAULT_PS_CLK_FREQUENCY 
 
 #ifdef _KERNEL
-- 
2.25.1

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

rtemsbsd/versal_slcr: Fix Versal GEM clock set

2023-06-14 Thread aaron . nyholm 
On the Versal when the GEM clock is routed from a PLL in another domain
it goes through another clock divider. This check accounts for this
extra clock divider when setting the clock.

Thanks, Aaron.


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

Re: bsps/xilinx-zynqmp : Add BSP for RPU

2023-06-14 Thread Chris Johns 
On 14/6/2023 6:08 pm, Philip Kirkpatrick wrote:
> This patch adds support for running RTEMS on the RPU (cortex R5) cores of the
> ZynqMP. 

Thanks for submitting this BSP. It is exciting to see this work and support
being added.

How different are the ZynqMP RPU cores and the ones on the Versal?

I have not looked in detail but I know they are both R5 devices and I think we
should be able to reuse this support. Is placing the RPU pieces under the ZynqMP
sources what we want or should we consider how we would reuse the RPU BSP on
other Xilinx devices?

I am leading with this question without reviewing the sources in detail so I
apologise for this. I am happy to look at Versal support so I am not asking that
to be done.

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

Re: BSP-Specific Testing was: [PATCH 00/34] Integrate pre-qualified LEON3 BSP

2023-06-14 Thread Gedare Bloom 
On Wed, Jun 14, 2023 at 11:59 AM Sebastian Huber
 wrote:
>
> On 14.06.23 18:13, Gedare Bloom wrote:
> >>> I think we should have some of the BSP-specific tests under some other
> >>> location in testsuites, while others would be under validation where
> >>> they are used for pre-qualification?
> >>>
> >>> Maybe it is sensible to introduce testsuites/bsps/ also.
> >> For the unit tests I would use testsuites/unit/bsps and 
> >> testsuites/unit/cpu.
> >>
> > I like this.
>
> Should the test programs be placed in a "bsps", "bsp", or "cpu"
> directory also:
>
'bsps' and 'cpu' are consistent with other parts of the tree. So that
would be my preference. It can be renamed if really needed later.

> [666/671] Linking
> build/sparc/gr740/testsuites/validation/ts-validation-timecounter-0.exe
> [667/671] Linking
> build/sparc/gr740/testsuites/validation/ts-validation-timecounter-smp-0.exe
> [668/671] Linking
> build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-cache-snooping-disabled-boot.exe
> [669/671] Linking
> build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-cache-snooping-disabled-secondary.exe
> [670/671] Linking
> build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-clock-initialization.exe
> [671/671] Linking
> build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-shutdown.exe
>
> vs.
>
> [666/671] Linking
> build/sparc/gr740/testsuites/validation/ts-validation-timecounter-0.exe
> [667/671] Linking
> build/sparc/gr740/testsuites/validation/ts-validation-timecounter-smp-0.exe
> [668/671] Linking
> build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-cache-snooping-disabled-boot.exe
> [669/671] Linking
> build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-cache-snooping-disabled-secondary.exe
> [670/671] Linking
> build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-clock-initialization.exe
> [671/671] Linking
> build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-shutdown.exe
>
>
> --
> 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: BSP-Specific Testing was: [PATCH 00/34] Integrate pre-qualified LEON3 BSP

2023-06-14 Thread Sebastian Huber 

On 14.06.23 18:13, Gedare Bloom wrote:

I think we should have some of the BSP-specific tests under some other
location in testsuites, while others would be under validation where
they are used for pre-qualification?

Maybe it is sensible to introduce testsuites/bsps/ also.

For the unit tests I would use testsuites/unit/bsps and testsuites/unit/cpu.


I like this.


Should the test programs be placed in a "bsps", "bsp", or "cpu" 
directory also:


[666/671] Linking 
build/sparc/gr740/testsuites/validation/ts-validation-timecounter-0.exe
[667/671] Linking 
build/sparc/gr740/testsuites/validation/ts-validation-timecounter-smp-0.exe
[668/671] Linking 
build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-cache-snooping-disabled-boot.exe
[669/671] Linking 
build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-cache-snooping-disabled-secondary.exe
[670/671] Linking 
build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-clock-initialization.exe
[671/671] Linking 
build/sparc/gr740/testsuites/validation/bsps/ts-fatal-sparc-leon3-shutdown.exe


vs.

[666/671] Linking 
build/sparc/gr740/testsuites/validation/ts-validation-timecounter-0.exe
[667/671] Linking 
build/sparc/gr740/testsuites/validation/ts-validation-timecounter-smp-0.exe
[668/671] Linking 
build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-cache-snooping-disabled-boot.exe
[669/671] Linking 
build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-cache-snooping-disabled-secondary.exe
[670/671] Linking 
build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-clock-initialization.exe
[671/671] Linking 
build/sparc/gr740/testsuites/validation/ts-fatal-sparc-leon3-shutdown.exe



--
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: bsps/xilinx-zynqmp : Add BSP for RPU

2023-06-14 Thread mbenson 
This is great.  I will carve out time to check this out on the ZU3EG and 
provide feedback if needed.  Good job.

Sent from my iPhone

> On Jun 14, 2023, at 08:49, Joel Sherrill  wrote:
> 
> 
> Thanks for submitting this. It has been on the wish list for a while.
> 
> My first comment is that information needs to be added to the Users Guide on 
> this BSP. Guidance on capabilities, use, and debug is always appreciated by 
> the
> next user. Remember that often this is where search engines and other humans
> find out if something is supported.
> 
> Comments inline. Hoping others who know this hardware better do a more
> technical review.
> 
>> On Wed, Jun 14, 2023 at 3:08 AM Philip Kirkpatrick 
>>  wrote:
>> This patch adds support for running RTEMS on the RPU (cortex R5) cores of 
>> the ZynqMP.  This is only a basic BSP and does not yet support the following:
>> - SMP
>> - Cache
>> - MPU
>> 
>> Also, everything except for the startup and exception vectors runs out of 
>> DRAM, which is slow without cache.  At some point in the future, I plan to 
>> move some of the fast memory sections to ATCM and BTCM and enable cache.
>> 
>> Lastly, credit to Stanislav (s.pankev...@gmail.com, also on this mailing 
>> list), for internal reviews and feedback.
>> 
>> The steps done to implement this BSP are as follows:
>> - to xilinx_zynqmp_ultra96 bsp (spec/build/bsps/arm/xilinx-zynqmp/*)
>>   - Added optprocunitapu.yml to pass C define ZYNQMP_PROC_UNIT_APU
>> - Copied xilinx_zynqmp_ultra96 bsp to xilinx_zynqmp_mercuryxu5_rpu in 
>> spec/build/bsps/arm/xilinx-zynqmp-rpu/*
>> - In new BSP
>>   - changed optprocunitapu.yml to optprocunitrpu.yml to pass C define 
>> ZYNQMP_PROC_UNIT_RPU
>>   - Removed all things regarding MMU, and SMP
>>   - Changed source: bsps/arm/shared/cache/cache-cp15.c to 
>> bsps/shared/cache/nocache.c
>>   - Removed all other references to cache
>>   - Changed abi flags
>>   - Updated the linkcmds to remove MMU and cache sections.
>>   - Updated optint0len, optint0ori, optint1len, and optint1ori to target 
>> ATCM and BTCM.
>>   - Updated linkcmds to place START and VECTOR regions in ATCM
>> - In BSP C sources
>>   - Used ZYNQMP_PROC_UNIT_APU and ZYNQMP_PROC_UNIT_RPU to enable/disable 
>> MPU, SMP, and cache.
>>   - Used PROC_UNIT flags to control GIC address.
>>   - Added hook0 code for RPU code to make sure SCTLR[M, I, A, C, V] are 
>> cleared
>>   - Created a timer driver for the Triple Timer Counter (TTC) module since 
>> the RPU doesn't have an ARM generic timer
>> 
>> ---
>> diff --git a/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c 
>> b/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
>> new file mode 100644
>> index 00..dd0bc3a3c9
>> --- /dev/null
>> +++ b/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
>> @@ -0,0 +1,219 @@
>> +/**
>> + * @file
>> + *
>> + * @ingroup RTEMSBSPsARMZynqMP
>> + *
>> + * @brief Triple Timer Counter clock functions definitions.
>> + */
>> +
>> +/*
>> + * SPDX-License-Identifier: BSD-2-Clause
>> + *
>> + * Copyright (C) 2023 Reflex Aerospace GmbH
>> + *
>> + * Written by Philip Kirkpatrick 
>> + *
>> + * 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 
>> +
>> +static struct timecounter zynqmp_ttc_tc;
>> +
>> +#define TTC_REFERENCE_CLOCK 1
>> +
>> +/* This is defined in dev/clock/clockimpl.h */
>> +void Clock_isr(rtems_irq_hdl_param arg);
>> +
>> +static uint32_t irq_match_interval;
>> +
>> +static uint32_t zynqmp_ttc_get_timecount(struct timecounter *tc)
>> +{
>> +  uint32_t time;
>> +  time = XTtcPs_ReadReg(ZYNQMP_TTC0, XTTCPS_COUNT_VALUE_O

Re: bsps/xilinx-zynqmp : Add BSP for RPU

2023-06-14 Thread Kinsey Moore 
Overall, this looks like great work! Thanks for contributing!

Just a couple of addons to Joel's comments below.

On Wed, Jun 14, 2023 at 8:49 AM Joel Sherrill  wrote:

>
> On Wed, Jun 14, 2023 at 3:08 AM Philip Kirkpatrick <
> p.kirkpatr...@reflexaerospace.com> wrote:
>
> diff --git a/bsps/arm/xilinx-zynqmp/include/bsp/xttcps_hw.h
>> b/bsps/arm/xilinx-zynqmp/include/bsp/xttcps_hw.h
>> new file mode 100644
>> index 00..ba0d559b07
>> --- /dev/null
>> +++ b/bsps/arm/xilinx-zynqmp/include/bsp/xttcps_hw.h
>> @@ -0,0 +1,223 @@
>>
>> +/**
>> +* Copyright (C) 2010 - 2021 Xilinx, Inc.  All rights reserved.
>> +* SPDX-License-Identifier: MIT
>>
>> +**/
>>
>
> Someone else should comment on whether this Xilinx file should be in
> a location where it is shareable by other BSPs.
>

This should definitely be moved into a shared location. It's theoretically
usable by ARM, AArch64, and Microblaze on this platform.

>
> Is this file unmodified from the Xilinx provided version? Changes for
> RTEMS should be inside conditional like "#ifdef __rtems__" or
> "#ifndef __rtems__"
>
>
>> +#ifndef LIBBSP_ARM_ZYNQMP
>> +#define LIBBSP_ARM_ZYNQMP
>> +
>> +/* Data derived from
>> https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/PS-I/O-Peripherals-Registers
>> */
>> +
>> +/* LPD IO Peripherals */
>> +#define ZYNQMP_UART0 (0xFF00)
>>
>
> I'm assuming that these constants do not need to be marked as unsigned.
>
>
>> +#define ZYNQMP_UART1 (0xFF01)
>> +#define ZYNQMP_I2C0 (0xFF02)
>> +#define ZYNQMP_I2C1 (0xFF03)
>> +#define ZYNQMP_SPI0 (0xFF04)
>> +#define ZYNQMP_SPI1 (0xFF05)
>> +#define ZYNQMP_CAN0 (0xFF06)
>> +#define ZYNQMP_CAN1 (0xFF07)
>> +#define ZYNQMP_GPIO (0xFF0A)
>> +#define ZYNQMP_GEM0 (0xFF0B)
>> +#define ZYNQMP_GEM1 (0xFF0C)
>> +#define ZYNQMP_GEM2 (0xFF0D)
>> +#define ZYNQMP_GEM3 (0xFF0E)
>> +#define ZYNQMP_QSPI (0xFF0F)
>> +#define ZYNQMP_NAND (0xFF10)
>> +#define ZYNQMP_SD0 (0xFF16)
>> +#define ZYNQMP_SD1 (0xFF17)
>> +#define ZYNQMP_IPI_MSG (0xFF99)
>> +#define ZYNQMP_USB0 (0xFF9D)
>> +#define ZYNQMP_USB1 (0xFF9E)
>> +#define ZYNQMP_AMS (0xFFA5)
>> +#define ZYNQMP_PSSYSMON (0xFFA50800)
>> +#define ZYNQMP_PLSYSMON (0xFFA50C00)
>> +#define ZYNQMP_CSU_SWDT (0xFFCB)
>> +
>> +/* FPD IO Peripherals */
>> +#define ZYNQMP_SATA (0xFD0C)
>> +#define ZYNQMP_PCIE (0xFD0E)
>> +#define ZYNQMP_PCIE_IN (0xFD0E0800)
>> +#define ZYNQMP_PCIE_EG (0xFD0E0C00)
>> +#define ZYNQMP_PCIE_DMA (0xFD0F)
>> +#define ZYNQMP_SIOU (0xFD3D)
>> +#define ZYNQMP_GTR (0xFD40)
>> +#define ZYNQMP_PCIE_ATTR (0xFD48)
>> +#define ZYNQMP_DP (0xFD4A)
>> +#define ZYNQMP_GPU (0xFD4B)
>> +#define ZYNQMP_DP_DMA (0xFD4C)
>> +
>> +/* LPD System Registers */
>> +#define ZYNQMP_IPI (0xFF30)
>> +#define ZYNQMP_TTC0 (0xFF11)
>> +#define ZYNQMP_TTC1 (0xFF12)
>> +#define ZYNQMP_TTC2 (0xFF13)
>> +#define ZYNQMP_TTC3 (0xFF14)
>> +#define ZYNQMP_LPD_SWDT (0xFF15)
>> +#define ZYNQMP_XPPU (0xFF98)
>> +#define ZYNQMP_XPPU_SINK (0xFF9C)
>> +#define ZYNQMP_PL_LPD (0xFF9B)
>> +#define ZYNQMP_OCM (0xFFA0)
>> +#define ZYNQMP_LPD_FPD (0xFFA1)
>> +#define ZYNQMP_RTC (0xFFA6)
>> +#define ZYNQMP_OCM_XMPU (0xFFA7)
>> +#define ZYNQMP_LPD_DMA (0xFFA8)
>> +#define ZYNQMP_CSU_DMA (0xFFC8)
>> +#define ZYNQMP_CSU (0xFFCA)
>> +#define ZYNQMP_BBRAM (0xFFCD)
>> +
>> +#endif /* LIBBSP_ARM_ZYNQMP */
>>
>
> If we're going to have a list of peripheral addresses for the platform, it
might be useful to have in a shared space for the same reason as the TTC.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSP-Specific Testing was: [PATCH 00/34] Integrate pre-qualified LEON3 BSP

2023-06-14 Thread Gedare Bloom 
On Tue, Jun 13, 2023 at 8:56 AM Sebastian Huber
 wrote:
>
>
>
> On 12.06.23 17:58, Gedare Bloom wrote:
> > On Mon, Jun 12, 2023 at 12:56 AM Sebastian Huber
> >  wrote:
> >>
> >>
> >>
> >> On 01.06.23 22:06, Gedare Bloom wrote:
> >>> On Thu, Jun 1, 2023 at 2:00 PM Gedare Bloom  wrote:
>  -- Forwarded message -
>  From: Sebastian Huber
>  Date: Wed, May 31, 2023 at 10:31 AM
> 
>  The existing tests in the RTEMS test suite are basically BSP
>  independent. This patch set introduces BSP-specific validation tests.
>  These tests are disabled for other BSPs through the build system, for
>  example:
> 
>  spec/build/testsuites/validation/bsp-sparc-leon3-gr712rc.yml
>  [...]
>  cxxflags: []
>  enabled-by: sparc/gr712rc
>  features: c cprogram
>  [...]
> >>> The use of the enabled-by: field to control the BSP-specific tests
> >>> looks reasonable. However, we should decide where/how any BSP-specific
> >>> tests should reside. It looks to me like the current approach is to
> >>> dump all test files in a single monolithic 'validation' directory, and
> >>> let the user/script sort it out. This results in a mix of tests
> >>> intended for all targets, and some for specific targets. This is
> >>> pretty much non-maintainable from my point-of-view without some
> >>> additional tool support. Correct me if I'm wrong.
> >>
> >> Yes, this is the current approach. There is no strict one-to-one
> >> relationship of test cases and test suites. The file names are somewhat
> >> descriptive, for example:
> >>
> >> ls -l *leon3*
> >> -rw-r--r-- 1 sebastian_h domain users 3739 31. Mai 10:44
> >> tc-bsp-sparc-leon3-gr712rc.c
> >> -rw-r--r-- 1 sebastian_h domain users 6138 31. Mai 10:44
> >> tc-fatal-bsp-sparc-leon3-shutdown.c
> >> -rw-r--r-- 1 sebastian_h domain users 5135 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.c
> >> -rw-r--r-- 1 sebastian_h domain users 2723 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.h
> >> -rw-r--r-- 1 sebastian_h domain users 5406 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.c
> >> -rw-r--r-- 1 sebastian_h domain users 2753 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.h
> >> -rw-r--r-- 1 sebastian_h domain users 5270 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-clock-initialization.c
> >> -rw-r--r-- 1 sebastian_h domain users 2681 31. Mai 10:44
> >> tr-fatal-bsp-sparc-leon3-clock-initialization.h
> >> -rw-r--r-- 1 sebastian_h domain users 2488 31. Mai 10:44
> >> ts-bsp-sparc-leon3-gr712rc.c
> >> -rw-r--r-- 1 sebastian_h domain users 2845 31. Mai 10:44
> >> ts-fatal-bsp-sparc-leon3-cache-snooping-disabled-boot.c
> >> -rw-r--r-- 1 sebastian_h domain users 2919 31. Mai 10:44
> >> ts-fatal-bsp-sparc-leon3-cache-snooping-disabled-secondary.c
> >> -rw-r--r-- 1 sebastian_h domain users 2797 31. Mai 10:44
> >> ts-fatal-bsp-sparc-leon3-clock-initialization.c
> >> -rw-r--r-- 1 sebastian_h domain users 3148 31. Mai 10:45
> >> ts-fatal-bsp-sparc-leon3-shutdown-response.c
> >> -rw-r--r-- 1 sebastian_h domain users 4909 31. Mai 10:44
> >> ts-fatal-bsp-sparc-leon3-shutdown.c
> >>
> >> We could also introduce subdirectories to organize things. The test
> >> framework prints out the file name in messages, so it would be nice if
> >> they remain unique. With subdirectories this would lead to longer path
> >> names, for example
> >>
> >> testsuites/validation/sparc/leon3/tc-bsp-sparc-leon3-gr712rc.c
> >>
> > I see. Maybe it makes sense to have all BSP-specific tests in a bsps
> > subdirectory, with the unique names encoded to ensure the arch/bsp
> > combination appears in the filename, such as:
> > testsuites/validation/bsps/tc-bsp-sparc-leon3-gr712rc.c
> > If so, 'bsp-' can probably be omitted from the filename. This way,
> > architecture-specific testing may also be easily possible, like
> > tc-sparc-something.c
>
> This is a nicely balanced and easy approach. Place BSP-specific tests in
> a "bsps" directory. Place architecture-specific tests in a "cpu" directory.
>
> >
> >>>
> >>> I would like to discuss possible ways to manage the integration of
> >>> tests that are conditionally-built based on the arch/bsp tuple. We
> >>> should have clear guidance for others who want to add such tests in
> >>> the future, or who would modify existing tests.
> >>
> >> Yes, this makes sense. We could add a new section for BSP-specific tests 
> >> to:
> >>
> >> https://docs.rtems.org/branches/master/eng/req/howto.html
> >>
> >> For a pre-qualified BSP you have to specify the fatal errors and write
> >> validation tests for it. Other BSP-specific specification and validation
> >> may be necessary for the kernel IO device driver, cache controller
> >> support, memory management unit initialization, memory protection unit
> >> initialization, etc.
> >>
> > Good, that would definitely be important to document.
>
> Ok, I will add something to this s

Re: style question: breaking inline assembly lines

2023-06-14 Thread Gedare Bloom 
On Tue, Jun 13, 2023 at 7:41 PM Chris Johns  wrote:
>
> On 14/6/2023 10:20 am, Joel Sherrill wrote:
> >
> >
> > On Tue, Jun 13, 2023, 4:43 PM Chris Johns  > > wrote:
> >
> > On 14/6/2023 5:47 am, Joel Sherrill wrote:
> > >
> > >
> > > On Tue, Jun 13, 2023 at 9:51 AM Sebastian Huber
> > >  > 
> >  > >>
> > > wrote:
> > >
> > > On 13.06.23 00:04, Gedare Bloom wrote:
> > > >   "b _ARM_Exception_default\n"
> > > >   :
> > > > -: [cpufsz] "i" (sizeof(CPU_Exception_frame)),
> > > > -  [cpuspoff] "i" (offsetof(CPU_Exception_frame, 
> > register_sp)),
> > > > -  [v7mlroff] "i" (offsetof(ARMV7M_Exception_frame, 
> > register_lr)),
> > > > -  [cpuvecoff] "J" (offsetof(CPU_Exception_frame, vector)),
> > > > -  [cpuvfpoff] "i" (ARM_EXCEPTION_FRAME_VFP_CONTEXT_OFFSET),
> > > > -  [cpacr] "i" (ARMV7M_CPACR),
> > > > -  [vfpsz] "i" (ARM_VFP_CONTEXT_SIZE)
> > > > +: [cpufsz] "i"( sizeof( CPU_Exception_frame ) ),
> > >
> > > If we place operators (e.g. &&, ||, ...) at the end of a broken 
> > line,
> > > then we should do this for the : as well.
> > >
> > >
> > > OK.
> > >
> > >
> > >
> > > My current preference would be to format all non-third-party 
> > sources
> > > with a standard clang-format selection. I guess in the long run, 
> > this
> > > will be the easiest approach to maintain. If we use exotic 
> > options, then
> > > we may up ending as clang-format maintainers.
> > >
> > >
> > > I think this is the thing we have to keep in mind and I even said I 
> > would
> > > go along with compromises when we started. Get as close as you can
> > > and we will have to accept that -- for now. We should definitely file 
> > tickets
> > > with clang-format and ourselves to track things we don't like. If we 
> > get an
> > > option in the future whether we or someone else implements it, we can
> > > use it and reformat again. Those hopefully are not that invasive.
> >
> > Sounds like a plan.
> >
> > I am a little concerned about the version of clang-format I need as some
> > machines I work on are no at current OS versions.
> >
> >
> > I am finding myself experimenting with it for a customer's C++ project. So 
> > far,
> > I have not matched the style. But I am now on Rocky 9 since I built it from
> > source and needed cmake 3 at least. So you can't be on an old distribution 
> > and
> > build from source.
>
> I use clang-format on a couple projects with something close the standard
> format. It works well.
>
> > And Doxygen has and three different major versions between RHEL 7, 8, and 9.
> > Using a configuration file from one on another seems to give you warnings 
> > about
> > unknown options or obsolete options.
> >
> > Mixing new and old systems is a pain.
>
> It is but we have to for reasons specific to local sites.
>
As a developer tool that can be used also by CI tools to automate
style fixes, I view the availability of clang-format as less of a
concern (than say a specific version of gcc). People can still create
and send commits without having the tool.

If someone ends up proposing a requirement for clang-format clean
patch submissions, then it becomes a problem.

> Chris
> ___
> 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: style question: breaking inline assembly lines

2023-06-14 Thread Gedare Bloom 
On Tue, Jun 13, 2023 at 8:51 AM Sebastian Huber
 wrote:
>
> On 13.06.23 00:04, Gedare Bloom wrote:
> >   "b _ARM_Exception_default\n"
> >   :
> > -: [cpufsz] "i" (sizeof(CPU_Exception_frame)),
> > -  [cpuspoff] "i" (offsetof(CPU_Exception_frame, register_sp)),
> > -  [v7mlroff] "i" (offsetof(ARMV7M_Exception_frame, register_lr)),
> > -  [cpuvecoff] "J" (offsetof(CPU_Exception_frame, vector)),
> > -  [cpuvfpoff] "i" (ARM_EXCEPTION_FRAME_VFP_CONTEXT_OFFSET),
> > -  [cpacr] "i" (ARMV7M_CPACR),
> > -  [vfpsz] "i" (ARM_VFP_CONTEXT_SIZE)
> > +: [cpufsz] "i"( sizeof( CPU_Exception_frame ) ),
>
> If we place operators (e.g. &&, ||, ...) at the end of a broken line,
> then we should do this for the : as well.
>
> My current preference would be to format all non-third-party sources
> with a standard clang-format selection. I guess in the long run, this
> will be the easiest approach to maintain. If we use exotic options, then
> we may up ending as clang-format maintainers.
>

The options supported since clang-16 are  what I suggested:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#breakbeforeinlineasmcolon

Breaking a newline after the : is not directly supported. It would
seem to be easy to add to clang-format if that's what we want.

I think I'm about 20% of the way toward being a clang-format maintainer already.

> --
> 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: bsps/xilinx-zynqmp : Add BSP for RPU

2023-06-14 Thread Joel Sherrill 
Thanks for submitting this. It has been on the wish list for a while.

My first comment is that information needs to be added to the Users Guide
on
this BSP. Guidance on capabilities, use, and debug is always appreciated by
the
next user. Remember that often this is where search engines and other humans
find out if something is supported.

Comments inline. Hoping others who know this hardware better do a more
technical review.

On Wed, Jun 14, 2023 at 3:08 AM Philip Kirkpatrick <
p.kirkpatr...@reflexaerospace.com> wrote:

> This patch adds support for running RTEMS on the RPU (cortex R5) cores of
> the ZynqMP.  This is only a basic BSP and does not yet support the
> following:
> - SMP
> - Cache
> - MPU
>
> Also, everything except for the startup and exception vectors runs out of
> DRAM, which is slow without cache.  At some point in the future, I plan to
> move some of the fast memory sections to ATCM and BTCM and enable cache.
>
> Lastly, credit to Stanislav (s.pankev...@gmail.com, also on this mailing
> list), for internal reviews and feedback.
>
> The steps done to implement this BSP are as follows:
> - to xilinx_zynqmp_ultra96 bsp (spec/build/bsps/arm/xilinx-zynqmp/*)
>   - Added optprocunitapu.yml to pass C define ZYNQMP_PROC_UNIT_APU
> - Copied xilinx_zynqmp_ultra96 bsp to xilinx_zynqmp_mercuryxu5_rpu in
> spec/build/bsps/arm/xilinx-zynqmp-rpu/*
> - In new BSP
>   - changed optprocunitapu.yml to optprocunitrpu.yml to pass C define
> ZYNQMP_PROC_UNIT_RPU
>   - Removed all things regarding MMU, and SMP
>   - Changed source: bsps/arm/shared/cache/cache-cp15.c to
> bsps/shared/cache/nocache.c
>   - Removed all other references to cache
>   - Changed abi flags
>   - Updated the linkcmds to remove MMU and cache sections.
>   - Updated optint0len, optint0ori, optint1len, and optint1ori to target
> ATCM and BTCM.
>   - Updated linkcmds to place START and VECTOR regions in ATCM
> - In BSP C sources
>   - Used ZYNQMP_PROC_UNIT_APU and ZYNQMP_PROC_UNIT_RPU to enable/disable
> MPU, SMP, and cache.
>   - Used PROC_UNIT flags to control GIC address.
>   - Added hook0 code for RPU code to make sure SCTLR[M, I, A, C, V] are
> cleared
>   - Created a timer driver for the Triple Timer Counter (TTC) module since
> the RPU doesn't have an ARM generic timer
>
> ---
> diff --git a/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
> b/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
> new file mode 100644
> index 00..dd0bc3a3c9
> --- /dev/null
> +++ b/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
> @@ -0,0 +1,219 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSBSPsARMZynqMP
> + *
> + * @brief Triple Timer Counter clock functions definitions.
> + */
> +
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (C) 2023 Reflex Aerospace GmbH
> + *
> + * Written by Philip Kirkpatrick 
> + *
> + * 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 
> +
> +static struct timecounter zynqmp_ttc_tc;
> +
> +#define TTC_REFERENCE_CLOCK 1
> +
> +/* This is defined in dev/clock/clockimpl.h */
> +void Clock_isr(rtems_irq_hdl_param arg);
> +
> +static uint32_t irq_match_interval;
> +
> +static uint32_t zynqmp_ttc_get_timecount(struct timecounter *tc)
> +{
> +  uint32_t time;
> +  time = XTtcPs_ReadReg(ZYNQMP_TTC0, XTTCPS_COUNT_VALUE_OFFSET);
> +  return time;
> +}
> +
> +/**
> + *  @brief Initialize the HW peripheral for clock driver
> + *
> + *  Clock driver is implemented by RTI module
> + *
> + * @retval Void
> + */
> +static void zynqmp_ttc_clock_driver_support_initialize_hardware( void )
> +{
> +
> +  uint32_t microsec_per_tick;
>

bsps/xilinx-zynqmp : Add BSP for RPU

2023-06-14 Thread Philip Kirkpatrick 
This patch adds support for running RTEMS on the RPU (cortex R5) cores of
the ZynqMP.  This is only a basic BSP and does not yet support the
following:
- SMP
- Cache
- MPU

Also, everything except for the startup and exception vectors runs out of
DRAM, which is slow without cache.  At some point in the future, I plan to
move some of the fast memory sections to ATCM and BTCM and enable cache.

Lastly, credit to Stanislav (s.pankev...@gmail.com, also on this mailing
list), for internal reviews and feedback.

The steps done to implement this BSP are as follows:
- to xilinx_zynqmp_ultra96 bsp (spec/build/bsps/arm/xilinx-zynqmp/*)
  - Added optprocunitapu.yml to pass C define ZYNQMP_PROC_UNIT_APU
- Copied xilinx_zynqmp_ultra96 bsp to xilinx_zynqmp_mercuryxu5_rpu in
spec/build/bsps/arm/xilinx-zynqmp-rpu/*
- In new BSP
  - changed optprocunitapu.yml to optprocunitrpu.yml to pass C define
ZYNQMP_PROC_UNIT_RPU
  - Removed all things regarding MMU, and SMP
  - Changed source: bsps/arm/shared/cache/cache-cp15.c to
bsps/shared/cache/nocache.c
  - Removed all other references to cache
  - Changed abi flags
  - Updated the linkcmds to remove MMU and cache sections.
  - Updated optint0len, optint0ori, optint1len, and optint1ori to target
ATCM and BTCM.
  - Updated linkcmds to place START and VECTOR regions in ATCM
- In BSP C sources
  - Used ZYNQMP_PROC_UNIT_APU and ZYNQMP_PROC_UNIT_RPU to enable/disable
MPU, SMP, and cache.
  - Used PROC_UNIT flags to control GIC address.
  - Added hook0 code for RPU code to make sure SCTLR[M, I, A, C, V] are
cleared
  - Created a timer driver for the Triple Timer Counter (TTC) module since
the RPU doesn't have an ARM generic timer

---
diff --git a/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
b/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
new file mode 100644
index 00..dd0bc3a3c9
--- /dev/null
+++ b/bsps/arm/xilinx-zynqmp/clock/clock-ttc.c
@@ -0,0 +1,219 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSBSPsARMZynqMP
+ *
+ * @brief Triple Timer Counter clock functions definitions.
+ */
+
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2023 Reflex Aerospace GmbH
+ *
+ * Written by Philip Kirkpatrick 
+ *
+ * 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 
+
+static struct timecounter zynqmp_ttc_tc;
+
+#define TTC_REFERENCE_CLOCK 1
+
+/* This is defined in dev/clock/clockimpl.h */
+void Clock_isr(rtems_irq_hdl_param arg);
+
+static uint32_t irq_match_interval;
+
+static uint32_t zynqmp_ttc_get_timecount(struct timecounter *tc)
+{
+  uint32_t time;
+  time = XTtcPs_ReadReg(ZYNQMP_TTC0, XTTCPS_COUNT_VALUE_OFFSET);
+  return time;
+}
+
+/**
+ *  @brief Initialize the HW peripheral for clock driver
+ *
+ *  Clock driver is implemented by RTI module
+ *
+ * @retval Void
+ */
+static void zynqmp_ttc_clock_driver_support_initialize_hardware( void )
+{
+
+  uint32_t microsec_per_tick;
+  uint16_t clock_ratio;
+  uint8_t  index;
+  uint32_t frequency;
+  uint32_t prescaler;
+  uint32_t tmp_reg_val;
+
+  microsec_per_tick = rtems_configuration_get_microseconds_per_tick();
+
+  /* Check the TTC is OFF before reconfiguring */
+  XTtcPs_WriteReg(ZYNQMP_TTC0, XTTCPS_CNT_CNTRL_OFFSET,
XTTCPS_CNT_CNTRL_DIS_MASK |
+XTTCPS_CNT_CNTRL_EN_WAVE_MASK);  // Don't enable waveform output
(active low)
+
+  /* Prescaler value is 2^(N + 1) */
+  /* Divide down the clock as much as possible while still retaining a */
+  /* frequency that is an integer multiple of 1MHz.  This maximizes time
to */
+  /* overflow while minimizing rounding errors in 1us periods */
+  clock_ratio = TTC_REFERENCE_CLOCK / 100;
+  /* Search for the highest set bit.  This is effective