Re: [PATCH] posix: Only check shm_unlink obj_err if necessary

[Will]

Ticket 4016 opened for 5.1 and patch sent with appropriate close tag.

On Sat, Jun 27, 2020 at 4:30 PM Gedare Bloom  wrote:

> This needs a ticket now to apply to 5, and we'll want to apply to 6 also.
> Can you open a ticket and post a patch for 5.1?
>
> On Thu, Jun 25, 2020, 5:49 PM Kinsey Moore 
> wrote:
>
>> Hey Gedare,
>> Setting obj_err to 0 would get the desired outcome, but the logic as it
>> exists now is faulty. Setting obj_err to a value that can't be produced by
>> _POSIX_Shm_Get_by_name would be a better option, but it would still be
>> checking an error value after successful execution. _POSIX_Shm_Get_by_name
>> relies on _Objects_Get_by_name internally which states about obj_err: The
>> error indication in case of failure. If _POSIX_Shm_Get_by_name returns
>> OBJECTS_GET_BY_NAME_NO_OBJECT (which it can), the current logic treats that
>> as a success and operates on a NULL pointer.
>>
>> -Original Message-
>> From: Gedare Bloom 
>> Sent: Thursday, June 25, 2020 16:49
>> To: Kinsey Moore 
>> Cc: devel@rtems.org
>> Subject: Re: [PATCH] posix: Only check shm_unlink obj_err if necessary
>>
>> Hi Kinsey,
>>
>> I missed seeing this. Two quick questions for you.
>>
>> 1. does it also work to initialize obj_err to 0? that would be simpler
>> code.
>>
>> 2. I see the error handling logic changes slightly, with
>> OBJECTS_GET_BY_NAME_NO_OBJECT now returning ENOENT. I guess if it works to
>> init obj_err to 0, this case should be merged back to the
>> OBJECTS_GET_BY_NAME_INVALID_NAME case?
>>
>> On Thu, Jun 25, 2020 at 2:21 PM Kinsey Moore 
>> wrote:
>> >
>> > Is there anything stopping this from being merged? I just ran into this
>> bug again on the current project I'm working on.
>> >
>> > Kinsey
>> >
>> > -Original Message-
>> > From: Kinsey Moore 
>> > Sent: Tuesday, January 28, 2020 12:37
>> > To: devel@rtems.org
>> > Cc: Kinsey Moore 
>> > Subject: [PATCH] posix: Only check shm_unlink obj_err if necessary
>> >
>> > In the nominal case checked by spsysinit01, obj_err is unmodified if
>> _POSIX_Shm_Get_by_name returns non-NULL. In the case of shm_unlink, this
>> means an uninitialized value is passed into the switch and it appears this
>> test was passing by virtue of the stack having the right value on it in
>> most cases. This now checks obj_err only if _POSIX_Shm_Get_by_name returns
>> NULL.
>> > ---
>> >  cpukit/posix/src/shmunlink.c | 45
>> > ++--
>> >  1 file changed, 23 insertions(+), 22 deletions(-)
>> >
>> > diff --git a/cpukit/posix/src/shmunlink.c
>> > b/cpukit/posix/src/shmunlink.c index 00d743ac80..39c2ba0d87 100644
>> > --- a/cpukit/posix/src/shmunlink.c
>> > +++ b/cpukit/posix/src/shmunlink.c
>> > @@ -29,28 +29,29 @@ int shm_unlink( const char *name )
>> >_Objects_Allocator_lock();
>> >
>> >shm = _POSIX_Shm_Get_by_name( name, 0, &obj_err );
>> > -  switch ( obj_err ) {
>> > -case OBJECTS_GET_BY_NAME_INVALID_NAME:
>> > -  err = ENOENT;
>> > -  break;
>> > -
>> > -case OBJECTS_GET_BY_NAME_NAME_TOO_LONG:
>> > -  err = ENAMETOOLONG;
>> > -  break;
>> > -
>> > -case OBJECTS_GET_BY_NAME_NO_OBJECT:
>> > -default:
>> > -  _Objects_Namespace_remove_string(
>> > -&_POSIX_Shm_Information,
>> > -&shm->Object
>> > -  );
>> > -
>> > -  if ( shm->reference_count == 0 ) {
>> > -/* Only remove the shm object if no references exist to it.
>> Otherwise,
>> > - * the shm object will be freed later in
>> _POSIX_Shm_Attempt_delete */
>> > -_POSIX_Shm_Free( shm );
>> > -  }
>> > -  break;
>> > +  if ( shm ) {
>> > +_Objects_Namespace_remove_string(
>> > +  &_POSIX_Shm_Information,
>> > +  &shm->Object
>> > +);
>> > +
>> > +if ( shm->reference_count == 0 ) {
>> > +  /* Only remove the shm object if no references exist to it.
>> Otherwise,
>> > +   * the shm object will be freed later in
>> _POSIX_Shm_Attempt_delete */
>> > +  _POSIX_Shm_Free( shm );
>> > +}
>> > +  } else {
>> > +switch ( obj_err ) {
>> > +  case OBJECTS_GET_BY_NAME_NAME_TOO_LONG:
>> > +err = ENAMETOOLONG;
>> > +break;
>> > +
>> > +  case OBJECTS_GET_BY_NAME_INVALID_NAME:
>> > +  case OBJECTS_GET_BY_NAME_NO_OBJECT:
>> > +  default:
>> > +err = ENOENT;
>> > +break;
>> > +}
>> >}
>> >
>> >_Objects_Allocator_unlock();
>> > --
>> > 2.20.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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

.rtemsstack location on ARM

[Will]

I've been working on a Cortex-M4 BSP and its Qemu model has some
peculiarities requiring me to relocate the vector table to the end of the
available storage, at least temporarily. In the process of doing this, I
noticed that .rtemsstack is placed in REGION_VECTOR in the shared
linkcmds.base instead of REGION_WORK like it is for or1k and epiphany. This
complicates relocation of the vector table a bit and while I can hack
around it for now, I was wondering if this was intentional on ARM.

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

Re: .rtemsstack location on ARM

[Will]

Hi Sebastian,
The relocated vector table is also present in REGION_VECTOR as long as
bsp_vector_table_in_start_section is not defined in the linker script. It
sounds like this is expected behavior, though, so I'll adjust accordingly.

Thanks,
William

On Wed, Jan 8, 2020 at 11:58 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> the region name REGION_VECTOR is a bit misleading. For ARMv-7M the
> vector table is in the .bsp_start_text section, see
> "bsps/arm/shared/start/start.S". In the REGION_VECTOR there is only the
> interrupt stack.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 1/3] freebsd/cgem: Add phy address to read it from device tree

[Will]

On Tue, Feb 28, 2023 at 11:57 PM Padmarao Begari <
padmarao.beg...@microchip.com> wrote:

> Read the phy address from the device tree and use it to
> find the phy device if not found then search in the
> range of 0 to 31.
> ---
>  freebsd/sys/dev/cadence/if_cgem.c | 41 ---
>  1 file changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> b/freebsd/sys/dev/cadence/if_cgem.c
> index 689c3611..2888a085 100644
> --- a/freebsd/sys/dev/cadence/if_cgem.c
> +++ b/freebsd/sys/dev/cadence/if_cgem.c
> @@ -1217,6 +1217,27 @@ cgem_intr(void *arg)
> CGEM_UNLOCK(sc);
>  }
>
> +static int
> +cgem_get_phyaddr(phandle_t node, int *phy_addr)
> +{
> +   phandle_t phy_node;
> +   pcell_t phy_handle, phy_reg;
> +
> +   if (OF_getencprop(node, "phy-handle", (void *)&phy_handle,
> +   sizeof(phy_handle)) <= 0)
> +   return (ENXIO);
> +
> +   phy_node = OF_node_from_xref(phy_handle);
> +
> +   if (OF_getencprop(phy_node, "reg", (void *)&phy_reg,
> +   sizeof(phy_reg)) <= 0)
> +   return (ENXIO);
> +
> +   *phy_addr = phy_reg;
> +
> +   return (0);
> +}
> +
>
All changes should be gated behind #ifdef __rtems__, even if they're
backports from upstream.


>  /* Reset hardware. */
>  static void
>  cgem_reset(struct cgem_softc *sc)
> @@ -2003,6 +2024,7 @@ cgem_attach(device_t dev)
> pcell_t cell;
> int rid, err;
> u_char eaddr[ETHER_ADDR_LEN];
> +   int phy_addr;
>
Same here.


>
> sc->dev = dev;
> CGEM_LOCK_INIT(sc);
> @@ -2091,10 +2113,21 @@ cgem_attach(device_t dev)
> cgem_reset(sc);
> CGEM_UNLOCK(sc);
>
> -   /* Attach phy to mii bus. */
> -   err = mii_attach(dev, &sc->miibus, ifp,
> -cgem_ifmedia_upd, cgem_ifmedia_sts,
> -BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 0);
> +   err = cgem_get_phyaddr(node, &phy_addr);
> +   if (err == 0) {
> +   /* Attach phy to mii bus. */
> +   err = mii_attach(dev, &sc->miibus, ifp,
> +cgem_ifmedia_upd, cgem_ifmedia_sts,
> +BMSR_DEFCAPMASK, phy_addr,
> MII_OFFSET_ANY, 0);
> +   }
> +
> +   if (err) {
> +   /* Attach phy to mii bus. */
> +   err = mii_attach(dev, &sc->miibus, ifp,
> +cgem_ifmedia_upd, cgem_ifmedia_sts,
> +BMSR_DEFCAPMASK, MII_PHY_ANY,
> MII_OFFSET_ANY, 0);
> +   }
> +
>
Same here. Also, a simpler implementation would be to have cgem_get_phyaddr
return the PHY address or MII_PHY_ANY on error and fold that all into the
declaration. That would leave the declaration as:
#ifdef __rtems__
   int phy_addr = cgem_get_phyaddr(node);
#endif

and the change here as:
   /* Attach phy to mii bus. */
   err = mii_attach(dev, &sc->miibus, ifp,
cgem_ifmedia_upd, cgem_ifmedia_sts,
#ifdef __rtems__
BMSR_DEFCAPMASK, phy_addr, MII_OFFSET_ANY, 0);
#else /* __rtems__ */
BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 0);
#endif /* __rtems__ */

if (err) {
> device_printf(dev, "attaching PHYs failed\n");
> cgem_detach(dev);
> --
> 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

Re: [PATCH rtems-libbsd 2/3] freebsd/cgem: Read clock frequency from device tree

[Will]

On Tue, Feb 28, 2023 at 11:57 PM Padmarao Begari <
padmarao.beg...@microchip.com> wrote:

> Read the clock frequency from the device tree and use it to
> calculate the mdc clock divider for the MII bus if not found
> then use default clock divider.
> ---
>  freebsd/sys/dev/cadence/if_cgem.c | 39 ---
>  1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> b/freebsd/sys/dev/cadence/if_cgem.c
> index 2888a085..363a9717 100644
> --- a/freebsd/sys/dev/cadence/if_cgem.c
> +++ b/freebsd/sys/dev/cadence/if_cgem.c
> @@ -135,6 +135,7 @@ struct cgem_softc {
> uint32_tnet_cfg_shadow;
> int neednullqs;
> int phy_contype;
> +   uint32_tpclk_rate;
>  #endif /* __rtems__ */
> int ref_clk_num;
>  #ifndef __rtems__
> @@ -1238,6 +1239,27 @@ cgem_get_phyaddr(phandle_t node, int *phy_addr)
> return (0);
>  }
>
> +static uint32_t cgem_mdc_clk_div(struct cgem_softc *sc)
> +{
> +   uint32_t config;
> +   uint32_t pclk_hz = sc->pclk_rate;
> +
> +   if (pclk_hz <= 2000)
> +   config = CGEM_NET_CFG_MDC_CLK_DIV_8;
> +   else if (pclk_hz <= 4000)
> +   config = CGEM_NET_CFG_MDC_CLK_DIV_16;
> +   else if (pclk_hz <= 8000)
> +   config = CGEM_NET_CFG_MDC_CLK_DIV_32;
> +   else if (pclk_hz <= 12000)
> +   config = CGEM_NET_CFG_MDC_CLK_DIV_48;
> +   else if (pclk_hz <= 16000)
> +   config = CGEM_NET_CFG_MDC_CLK_DIV_64;
> +   else
> +   config = CGEM_NET_CFG_MDC_CLK_DIV_96;
> +
> +   return config;
> +}
> +
>
Enclose this in a #ifdef __rtems__ guard. I think the suggested style is to
always use braces {} with if/else, even if it's a single line.


>  /* Reset hardware. */
>  static void
>  cgem_reset(struct cgem_softc *sc)
> @@ -1279,12 +1301,16 @@ cgem_reset(struct cgem_softc *sc)
> sc->net_cfg_shadow = CGEM_NET_CFG_DBUS_WIDTH_32;
> }
>
> +   if (sc->pclk_rate != 0) {
> +   sc->net_cfg_shadow |= cgem_mdc_clk_div(sc);
> +   } else {
>  #ifdef CGEM64
> -   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_48;
> +   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_48;
>  #else
> -   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_64;
> +   sc->net_cfg_shadow |= CGEM_NET_CFG_MDC_CLK_DIV_64;
>  #endif
> -   WR4(sc, CGEM_NET_CFG, sc->net_cfg_shadow);
> +   WR4(sc, CGEM_NET_CFG, sc->net_cfg_shadow);
> +   }
>  #endif /* __rtems__ */
>
> sc->net_ctl_shadow = CGEM_NET_CTRL_MGMT_PORT_EN;
> @@ -2038,6 +2064,13 @@ cgem_attach(device_t dev)
>  #endif /* __rtems__ */
> /* Get reference clock number and base divider from fdt. */
> node = ofw_bus_get_node(dev);
> +#ifdef __rtems__
> +   if (OF_getencprop(node, "clock-frequency", &cell, sizeof(cell)) >
> 0)
> +   sc->pclk_rate = cell;
> +   else
> +   sc->pclk_rate = 0;
> +#endif /* __rtems__ */
> +
> sc->ref_clk_num = 0;
> if (OF_getprop(node, "ref-clock-num", &cell, sizeof(cell)) > 0)
> sc->ref_clk_num = fdt32_to_cpu(cell);
> --
> 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

Re: [PATCH rtems-libbsd 3/3] freebsd/cgem: Add weak symbol for riscv

[Will]

This functionality is ideally implemented in a platform-specific system
level control register (SLCR) driver similar to ZynqMP and Versal. You
could also just leave it as-is since the default does exactly the same
thing. This patch should be dropped unless you're going to define an
implementation that will actually set the reference clock.

On Tue, Feb 28, 2023 at 11:57 PM Padmarao Begari <
padmarao.beg...@microchip.com> wrote:

> Add __weak_symbol instead of __weak_reference for the
> cgem_set_ref_clk() function for riscv build.
> ---
>  freebsd/sys/dev/cadence/if_cgem.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/freebsd/sys/dev/cadence/if_cgem.c
> b/freebsd/sys/dev/cadence/if_cgem.c
> index 363a9717..a12f7b43 100644
> --- a/freebsd/sys/dev/cadence/if_cgem.c
> +++ b/freebsd/sys/dev/cadence/if_cgem.c
> @@ -1764,6 +1764,12 @@ cgem_miibus_linkchg(device_t dev)
>   * Overridable weak symbol cgem_set_ref_clk().  This allows platforms to
>   * provide a function to set the cgem's reference clock.
>   */
> +#ifdef __riscv
> +__weak_symbol int cgem_set_ref_clk(int unit, int frequency)
> +{
> +   return 0;
> +}
> +#else
>  static int __used
>  cgem_default_set_ref_clk(int unit, int frequency)
>  {
> @@ -1771,6 +1777,7 @@ cgem_default_set_ref_clk(int unit, int frequency)
> return 0;
>  }
>  __weak_reference(cgem_default_set_ref_clk, cgem_set_ref_clk);
> +#endif /* __riscv */
>
>  /* Call to set reference clock and network config bits according to
> media. */
>  static void
> --
> 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

Re: Flash Device API

[Will]

On Fri, Mar 17, 2023 at 4:24 PM Gedare Bloom  wrote:

> Thank you Aaron for contributing this. I have a few comments below,
> and I'll also give some comments on your code shortly.
>
> On Fri, Mar 17, 2023 at 1:34 AM Sebastian Huber
>  wrote:
> >
> >
> >
> > On 16.03.23 23:07, Chris Johns wrote:
> > > On 16/3/2023 6:13 pm, Sebastian Huber wrote:
> > >> Hello Aaron,
> > >>
> > >> this API seems to be RTEMS-specific. Maybe we should simply pick up
> an existing
> > >> solution which is in more wide spread use, for example:
> > >>
> > >> https://docs.zephyrproject.org/latest/hardware/peripherals/flash.html
> > >
> > > That interface seems Zepher specific and looks to me like a series of
> calls that
> > > appear reasonable as a list to cover.
> >
> > The Zephyr API has drivers for a couple of chips:
> >
> > https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/flash
> >
> That code looks very zephyr-oriented. I think it would be a challenge
> to go first toward porting this API, if it requires substantial
> modifications of the upstream drivers to also use them, then it is
> more of a maintenance burden than the probable benefits of the code
> reuse. As a starting point, I do see a bespoke RTEMS implementation as
> a suitable place to begin. But, it would be good to understand the
> alternative flash driver frameworks that are out there, and what may
> be pros/cons of adopting them.
>
> > > The patch Aaron has posted is a driver. I
> > > prefer a driver like we have for I2C, SPI etc because the of support
> it brings.
> >
> > The I2C and SPI APIs are ported from Linux, so not RTEMS-specific.
> >
> > >
> > > The initial set of ioctl commands is small to start with. If you feel
> we should
> > > offer more I suggest they get added once this is merged.
> > >
> > > Is the change OK?
> >
> > I am not opposed to commit this API, however, I don't think it is a step
> > forward. It is yet another RTEMS-specific API. It has no related
> > documentation patches. The API has no high level user (for example
> > JAFFS2). The API has no implementation. It has no tests. It has no
> > driver framework (ONFI, JEDEC). It has no example driver. It has no
> > Doxygen documentation. The coding style of the new file has nothing to
> > do with the RTEMS coding style.
> >
>
> I think the provided code appears to be a good starting point.  I
> would request that you might add Doxygen something aligned with what
> we have for the i2c or spi would be good.
> https://docs.rtems.org/doxygen/branches/master/group__I2C.html
>
> In addition to the shell command addition, can you create/extend a
> testsuite for exercising the API?
>
> I will address the code directly also, but these high-level additions
> will greatly improve the submission of a new API. Unfortunately, my
> work on code formatting is not quite complete enough to rely on it for
> fixing any style issues. I'll do what I can to guide you through that.
>

Aaron,
Just in case you haven't already found it, the document you should be using
for style and header documentation is here:
https://docs.rtems.org/branches/master/eng/coding-conventions.html

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

Re: [PATCH] spec/bsp/makecustom: Make BSP include path a system include path

[Will]

This change is fine, but it also needs the packageconfig change to match.
The thread from October has the full patch (title was "[PATCH v2]
spec/pkgconfig: Allow builds to override headers"). This also needs a
change to libbsd to account for this alteration, IIRC.

Kinsey

On Wed, Apr 12, 2023 at 5:20 PM  wrote:

> From: Chris Johns 
>
> - Export the BSP include path as a system include path so the order
>   of options on an application compiler command line does not matter.
>
> Closes #4896
> ---
>  spec/build/bsps/makecustom.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/spec/build/bsps/makecustom.yml
> b/spec/build/bsps/makecustom.yml
> index 139629b597..c00240595e 100644
> --- a/spec/build/bsps/makecustom.yml
> +++ b/spec/build/bsps/makecustom.yml
> @@ -2,7 +2,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  build-type: config-file
>  content: |
>include $$(RTEMS_ROOT)/make/custom/default.cfg
> -  CPU_DEFINES = -I$$(exec_prefix)/$$(RTEMS_BSP)/lib/include
> +  CPU_DEFINES = -isystem $$(exec_prefix)/$$(RTEMS_BSP)/lib/include
>CPU_CFLAGS = ${ABI_FLAGS}
>CFLAGS_OPTIMIZE_V = ${OPTIMIZATION_FLAGS}
>LDFLAGS = -B$$(exec_prefix)/$$(RTEMS_BSP)/lib ${PKGCONFIG_LDFLAGS}
> --
> 2.37.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: [PATCH] rtemsbsd/versal_slcr: Fix Versal GEM clock set

[Will]

This looks good as far as the functional content is concerned. As a nit, it
looks like some unnecessary newlines were added in cgem_set_ref_clk() and
the added if() conditional braces are inconsistent in their formatting so
feel free to tweak those before commit.

On Thu, Jun 15, 2023 at 12:48 AM  wrote:

> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/9] cpukit/jffs2: Protect the inode cache

[Will]

On Wed, Dec 13, 2023 at 2:43 PM Chris Johns  wrote:

> On 14/12/2023 6:32 am, Sebastian Huber wrote:> We use this file system on
> lower
> end controllers.
>
> I do not believe this is relevant to the discussion. The issue standard on
> its
> own merit and not yours or my uses. Can we please avoid colouring
> discussion
> this way? Thanks.
>

I may have found a way to stuff the FS info pointer into the delayed work.
I'll work up and test a patch that doesn't introduce additional locking.

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

Re: [PATCH rtems6 1/1] xparameters.h: fix typo in comment

[Will]

Looks good to me. There is generally no need for a 0/X email when X is
small unless you think it is necessary. In this case, a message of "see
patch" isn't very useful.

Kinsey

On Sun, Jan 7, 2024 at 12:27 PM  wrote:

> From: Bernd Moessner 
>
> ---
>  bsps/include/xil/xparameters.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bsps/include/xil/xparameters.h
> b/bsps/include/xil/xparameters.h
> index b665810643..9d4d95eacb 100644
> --- a/bsps/include/xil/xparameters.h
> +++ b/bsps/include/xil/xparameters.h
> @@ -41,4 +41,4 @@ extern "C" {
>  }
>  #endif
>
> -#endif /* XIL_PRINTF_H */
> +#endif /* XPARAMETERS_H */
> --
> 2.34.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: [PATCH] improved error checking in ticks per timeslice

[Will]

Hey Zack,
Sebastian posted exactly what he thought those lines should be to match the
surrounding coding style:
#if defined(CONFIGURE_TICKS_PER_TIMESLICE) &&
   CONFIGURE_TICKS_PER_TIMESLICE <= 0

It should just be a single #if like that and with that order of
conditionals. You'll of course need to remove the second #endif since
you're going to 1 #if.

Kinsey

On Tue, Mar 5, 2024 at 8:44 PM  wrote:

> From: Zack leung 
>
> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
> index bd7cde628f..d480eb3971 100644
> --- a/cpukit/doxygen/appl-config.h
> +++ b/cpukit/doxygen/appl-config.h
> @@ -3312,7 +3312,7 @@
>   * @parblock
>   * The following constraints apply to this configuration option:
>   *
> - * * The value of the configuration option shall be greater than or equal
> to
> + * * The value of the configuration option shall be greater than
>   *   zero.
>   *
>   * * The value of the configuration option shall be less than or equal to
>  diff --git a/cpukit/include/rtems/confdefs/clock.h
> b/cpukit/include/rtems/confdefs/clock.h
> index 26519cc70b..bcca02bd43 100644
> --- a/cpukit/include/rtems/confdefs/clock.h
> +++ b/cpukit/include/rtems/confdefs/clock.h
> @@ -74,6 +74,12 @@
>#error "CONFIGURE_MICROSECONDS_PER_TICK must be positive"
>  #endif
>
> +#if CONFIGURE_TICKS_PER_TIMESLICE <= 0
> +  #if defined(CONFIGURE_TICKS_PER_TIMESLICE)
> +#error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> +  #endif
> +#endif
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
> --
> 2.43.0
>
> ___
> 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

ARM GICv3 Support

[Will]

Hi,
I'm currently doing some evaluations for an ARMv8 BSP which would
necessarily include a GIC that implements the GICv3 spec[1]. I see that
there is a shared GIC driver for ARM that seems to implement the ARM GICv1
spec based on the BSPs in which it is used.

Is anyone aware of whether the shared ARM GIC driver can also drive GICv2
implementations and thus possibly drive GICv3 implementations in legacy
mode (see section 1.3.6 of the spec) with minor alterations/restrictions?

I suspect that this is the case since GICv2 appears to be purely extensions
to GICv1, but it would be nice to have confirmation from someone better
versed in the implementation.

Thanks,
William

1:
https://static.docs.arm.com/ihi0069/c/IHI0069C_gic_architecture_specification.pdf

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

Re: ARM GICv3 Support

[Will]

Great, thanks! That will make initial bringup a little bit easier while
deciding whether I need to write a full GICv3 driver.

William

On Wed, Oct 24, 2018 at 6:16 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Will,
>
> On 23/10/2018 20:28, Will wrote:
> > Hi,
> > I'm currently doing some evaluations for an ARMv8 BSP which would
> > necessarily include a GIC that implements the GICv3 spec[1]. I see
> > that there is a shared GIC driver for ARM that seems to implement the
> > ARM GICv1 spec based on the BSPs in which it is used.
> >
> > Is anyone aware of whether the shared ARM GIC driver can also drive
> > GICv2 implementations and thus possibly drive GICv3 implementations in
> > legacy mode (see section 1.3.6 of the spec) with minor
> > alterations/restrictions?
> >
> > I suspect that this is the case since GICv2 appears to be purely
> > extensions to GICv1, but it would be nice to have confirmation from
> > someone better versed in the implementation.
>
> the Cortex-A7 MPCore equipped on the i.MX 7D uses a GIC v2.0. So, GICv2
> is supported.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Open Meetup on Discord

[Will]

Hey everyone,
We're doing this again in a few hours at 22:00 UTC for anyone that would
like to join in. We made plenty of progress closing out issues and
identifying what remains for the 6.1 release last week and we should be
there for another hour or so today.

Thanks,
Kinsey

On Thu, Oct 24, 2024 at 8:32 AM Joel Sherrill  wrote:

> Hi
>
> Meet up: Oct 24th 22:00 UTC to work on release issues and merge requests
> Location:  #General Discord Voice channe
>
> Myself, @kiwichris, @darkbeer42, @opticron, and @gedare plan to be there.
>
> Everyone is encouraged to attend and, hopefully, help wrap up some of the
> issues between here and a 6.1 release.
>
> Thanks.
>
> ---joel
> ___
> 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