Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Chris Johns]

On 16/8/20 8:29 am, Mritunjay Sharma wrote:
> On Sun, Aug 16, 2020 at 12:15 AM Gedare Bloom  > wrote:
> 
> Hi Mritunjay, Chris:
> 
> For the RSB, since it is user-facing, we need to be sure to minimize
> its dependencies on the user environment and platform. So this pycli
> can only be used if it is distributed standard with Python 2 and
> Python 3.
> 
> Would someone be able to apply this patch and use it to build epics?
> No, because (1) they won't have pycli available, and (2) they don't
> have a path /home/mritunjay
> 
> 
> I think what you are saying is absolutely right. It will be really a great 
> help
> if Chris can guide on what next can be done. 

See below.

> As far as 'pycli' is concerned, I have made a couple of minor tweaks. Gave it 
> a
> better name 'sedpy' and made it public on GitHub. 
> 
> Please find the link to the
> project here: https://github.com/mritunjaysharma394/sedpy

Thanks but I currently do not see a need for this tool.

> I will appreciate if mentors can have a look and try this and see if it in any
> way can be modified
> to be used with RSB or else we will go with what is suggested. 

Please put the RSB to one side. I will let you know when we can return to it.

I believe patching config files in EPCIS from the RSB is fragile. EPICS should
be free to change any of these files without needing to considering the effect
it has on the RSB. Just because we can peek inside does not means we are free to
exploit what we see.

What happens if you define the needed variables on the make command line? For
example:

 gmake RTEMS_BASE=$HOME/development/rtems/5 RTEMS_VERSION=5.1-rc2

These variables are just normal make ones and so they can be overridden from the
command line.

Please investigate this and see what happens?

Chris

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

Re: RTEMS 5 on the start page of RTEMS.org

[Christian Mauderer]

Hello Joel,

I noted that we already have RC2 for 5.1. So most likely it's better to
wait for 5.1. Otherwise it's double work.

On 08/08/2020 18:17, Joel Sherrill wrote:
> 
> 
> On Sat, Aug 8, 2020, 10:56 AM Christian Mauderer  > wrote:
> 
> Hello Joel,
> 
> On 08/08/2020 17:51, Joel Sherrill wrote:
> >
> >
> > On Sat, Aug 8, 2020, 10:38 AM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > >> wrote:
> >
> >     Hello,
> >
> >     I noted that on the start page of www.rtems.org
> 
> >     , there are still a lot
> >     of outdated references to the last release. One of the most
> obvious is
> >     the Documentation section on the right and the "Release and Active
> >     Development" section.
> >
> >     I don't think that our home page is in a git repo so that I
> could send a
> >     patch?
> >
> >
> > That would be nice but it isn't the way it is now. It is in Drupal
> now.
> > Personally I have decided an active CMS is too heavy for many
> websites.
> >
> > Hugo looks like a decent way for us to go as best I can tell. It is a
> > static site generator with lots of themes. But it takes work.
> >
> 
> I worked a bit with Hugo on some other pages. It's a nice system.
> 
> 
> As long as you have Go. :)

Right. That's a prerequisite.

If you start something with a static site generator: Tell me if I can
help with something.


Best regards

Christian

> 
> 
> >
> >
> >     Who would be able to update the links?
> >
> >
> > Me for one. Please file a ticket with specific changes and I will make
> > them. Please please please don't make me find everything and the right
> > destination. It is tedious enough executing the changes.
> 
> I'll try to find most locations in the next days. What format would be
> the best one for you? A screenshot with marked locations?
> 
> 
> You can do a text file if you want. Just name the box on the front page,
> text and link to change and new destination.
> 
> Usually they are easy to locate. 
> 
> Community > Mailing Lists should be new url
> 
> Probably will work for most.
> 
> If in text, just try. :)
> 
> --joel
> 
> 
> 
> 
> Best regards
> 
> Christian
> 
> >
> > --joel
> >
> >
> >     Best regards
> >
> >     Christian
> >     ___
> >     devel mailing list
> >     devel@rtems.org 
> >
> >     http://lists.rtems.org/mailman/listinfo/devel
> >
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/shared/ofw: Implement RTEMS OFW interface

[Chris Johns]

On 16/8/20 4:49 am, G S Niteesh Babu wrote:
> ---
>  bsps/include/ofw/ofw.h  | 534 
>  bsps/shared/ofw/ofw.c   | 654 
>  spec/build/bsps/obj.yml |   4 +
>  3 files changed, 1192 insertions(+)
>  create mode 100644 bsps/include/ofw/ofw.h
>  create mode 100644 bsps/shared/ofw/ofw.c
> 
> diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
> new file mode 100644
> index 00..2ca5328abc
> --- /dev/null
> +++ b/bsps/include/ofw/ofw.h
> @@ -0,0 +1,534 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup ofw
> + *
> + * RTEMS FDT implementation of OpenFirmWare Interface.
> + *
> + * RTEMS OFW is a FDT only implementation of the OpenFirmWare interface.
> + * This API is created to be compatible with FreeBSD OpenFirmWare interface.
> + * The main intention is to make porting of FreeBSD drivers to RTEMS easier.
> + */
> +
> +/*
> + * Copyright (C) 2020 Niteesh Babu G S 
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef _OFW_H
> +#define _OFW_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 
> +#include 
> +
> +/**
> + * Represents a node in the device tree. The offset from fdtp to node is used
> + * instead of fdt offset to make sure this is compatible with OF interface in
> + * FreeBSD.
> + */
> +typedef uint32_t  phandle_t;
> +/**
> + * Represents the effective phandle of the node.
> + */
> +typedef uint32_t  ihandle_t;
> +/**
> + * Represents the data type of the buffer.
> + */
> +typedef uint32_t  pcell_t;
> +
> +/**
> + * @struct rtems_ofw_memory_area
> + *
> + * This is used to represent elements(FDT properties) that define
> + * region of memory address.
> + */
> +typedef struct {
> +  /** The start address of the memory region. */
> +  uint32_t start;
> +  /** The size of the memory region. */
> +  uint32_t size;
> +} rtems_ofw_memory_area;
> +
> +/**
> + * @struct rtems_ofw_ranges
> + *
> + * This is used to represent the ranges property in the device tree.
> + */
> +typedef struct {
> +  /** The physical address within the child bus address space */
> +  uint32_t child_bus;
> +  /** The physical address within the parent bus address space */
> +  uint32_t parent_bus;
> +  /** The size of the range in the child’s address space */
> +  uint32_t size;
> +} rtems_ofw_ranges;
> +
> +/**
> + * @brief Gets the node that is next to @a node.
> + *
> + * @param[in] node Node offset
> + *
> + * @retval Peer node offset Successful operation.
> + * @retval 0 No peer node or invalid node handle
> + */
> +phandle_t rtems_ofw_peer(
> +  phandle_t   node
> +);
> +
> +/**
> + * @brief Gets the node that is the child of @a node.
> + *
> + * @param[in] node Node offset
> + *
> + * @retval child node offset Successful operation.
> + * @retval 0 No child node or invalid node handle
> + */
> +phandle_t rtems_ofw_child(
> +  phandle_t   node
> +);
> +
> +/**
> + * @brief Gets the node that is the parent of @a node.
> + *
> + * @param[in] node Node offset
> + *
> + * @retval child node offset Successful operation.
> + * @retval 0 No child node or invalid node handle
> + */
> +phandle_t rtems_ofw_parent(
> +  phandle_t   node
> +);
> +
> +/**
> + * @brief Gets the length of the property mentioned in @a propname.
> + *
> + * @param[in] node Node offset
> + * @param[in] prop Property name
> + *
> + * @retval -1 Invalid node or property
> + * @retval  Length of property on successful operation
> + */
> +size_t rtems_ofw_get_prop_len(
> +  phandle_t   node,
> +  const char *propname
> +);
> +
> +/**
> + * @brief Gets the value of property mentioned in @a propname.
> + *
> +

Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Mritunjay Sharma]

On Sun, Aug 16, 2020 at 1:12 PM Chris Johns  wrote:

> On 16/8/20 8:29 am, Mritunjay Sharma wrote:
> > On Sun, Aug 16, 2020 at 12:15 AM Gedare Bloom  > > wrote:
> >
> > Hi Mritunjay, Chris:
> >
> > For the RSB, since it is user-facing, we need to be sure to minimize
> > its dependencies on the user environment and platform. So this pycli
> > can only be used if it is distributed standard with Python 2 and
> > Python 3.
> >
> > Would someone be able to apply this patch and use it to build epics?
> > No, because (1) they won't have pycli available, and (2) they don't
> > have a path /home/mritunjay
> >
> >
> > I think what you are saying is absolutely right. It will be really a
> great help
> > if Chris can guide on what next can be done.
>
> See below.
>
> > As far as 'pycli' is concerned, I have made a couple of minor tweaks.
> Gave it a
> > better name 'sedpy' and made it public on GitHub.
> >
> > Please find the link to the
> > project here: https://github.com/mritunjaysharma394/sedpy
>
> Thanks but I currently do not see a need for this tool.
>
> > I will appreciate if mentors can have a look and try this and see if it
> in any
> > way can be modified
> > to be used with RSB or else we will go with what is suggested.
>
> Please put the RSB to one side. I will let you know when we can return to
> it.
>
> I believe patching config files in EPCIS from the RSB is fragile. EPICS
> should
> be free to change any of these files without needing to considering the
> effect
> it has on the RSB. Just because we can peek inside does not means we are
> free to
> exploit what we see.
>
> What happens if you define the needed variables on the make command line?
> For
> example:
>
>  gmake RTEMS_BASE=$HOME/development/rtems/5 RTEMS_VERSION=5.1-rc2
>
> These variables are just normal make ones and so they can be overridden
> from the
> command line.
>
> Please investigate this and see what happens?
>

Hi Chris,
I investigated and used:

 `make RTEMS_BASE=$HOME/development/rtems/5-arm RTEMS_VERSION=5`

This worked perfectly fine and the build was successful. Thank you so much
for telling this. It makes it so
easy. What can we do next? This surely removes the requirement of `sed` or
the tool I built to make command line changes.

Thanks
Mritunjay


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

Re: Need help in figuring out why gdb gives different value of a variable in callee vs caller context

[Richi Dubey]

Oh, I printed the variable value too early. Thanks for your help.

On Sat, Aug 15, 2020 at 7:24 PM Gedare Bloom  wrote:

> On Sat, Aug 15, 2020 at 3:15 AM Richi Dubey  wrote:
> >
> > Hi,
> >
> > With reference to the code (github link), it aims to check if the
> Affinty of a node is set to 0 by calling the function
> _Processor_mask_Is_zero.
> >
> > While debugging with gdb, I can see using 'p' command that the variable
> is indeed 0 but after the variable gets passed to the function, the value
> of the variable isn't 0 anymore. Why is this happening?
> >
> > Gdb trace:
> > --
> > (gdb)
> > 0x00118af4 187 _Processor_mask_Is_set(&node->Affinity,
> _Per_CPU_Get_index(curr_CPU) ||
> > (gdb)
> > 0x00118af6 187 _Processor_mask_Is_set(&node->Affinity,
> _Per_CPU_Get_index(curr_CPU) ||
> > (gdb) p &node->Affinity
> > $8 = (Processor_mask *) 0x200efc <_Thread_Objects+2172>
> address 0x200efc
>
> > (gdb) p node->Affinity
> > $9 = {
> >   __bits = {0}
> > }
> > (gdb) si
> > 0x00118af8 187 _Processor_mask_Is_set(&node->Affinity,
> _Per_CPU_Get_index(curr_CPU) ||
> > (gdb)
> > 190 _Processor_mask_Is_zero( &node->Affinity ) )
> > (gdb)
> > 0x00118afc 190 _Processor_mask_Is_zero( &node->Affinity ) )
> > (gdb)
> > 0x00118afe 190 _Processor_mask_Is_zero( &node->Affinity ) )
> > (gdb)
> > 0x00118b00 190 _Processor_mask_Is_zero( &node->Affinity ) )
> > (gdb)
> > _Processor_mask_Is_zero (mask=0x203580 <_Per_CPU_Information>) at
> /home/richi/quick-start/src/rtems/cpukit/include/rtems/score/processormask.h:75
> > 75 {
> > (gdb)
> > 0x0011726a 75 {
> > (gdb)
> > 0x0011726c 75 {
> > (gdb) p mask
> > $10 = (const Processor_mask *) 0x203580 <_Per_CPU_Information>
> address 0x203580
>
> You're not looking at the same memory location
>
> > (gdb) p *mask
> > $11 = {
> >   __bits = {2126656}
> > }
> > 
> >
> > Please provide your views on this.
> > Thanks,
> > Richi,
> > ___
> > 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] bsps/shared/ofw: Implement RTEMS OFW interface

[Niteesh G. S.]

On Sun, Aug 16, 2020 at 2:25 PM Chris Johns  wrote:

> On 16/8/20 4:49 am, G S Niteesh Babu wrote:
> > ---
>
> > +
> > +#ifdef HAVE_CONFIG_H
> > +#include "config.h"
> > +#endif
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +const void *fdtp = NULL;
> > +
> > +static phandle_t rtems_fdt_offset_to_phandle( int offset )
> > +{
> > +  if (offset < 0) {
> > +return 0;
> > +  }
> > +
> > +  return (phandle_t)offset + fdt_off_dt_struct(fdtp);
> > +}
> > +
> > +static int rtems_fdt_phandle_to_offset( phandle_t handle )
> > +{
> > +  int off;
> > +  int fdt_off;
> > +
> > +  off = (int) handle;
> > +  fdt_off = fdt_off_dt_struct(fdtp);
> > +
> > +  if (off < fdt_off) {
> > +return -1;
> > +
> > +  }
> > +
> > +  return off - fdt_off;
> > +}
> > +
> > +static void rtems_ofw_init( void ) {
> > +  int rv;
> > +  const void *fdt;
> > +
> > +  fdt = bsp_fdt_get();
> > +
> > +  rv = fdt_check_header(fdt);
> > +
> > +  /*
> > +   * Is assert a good option to handle error?
> > +   * AFIAK there is no other way to recover from invalid FDT.
> > +   * On providing an invalid FDT most driver's will fail/crash anyway.
> > +   */
>
> If you want to fail with an error I suggest a documented internal error. I
> however would prefer we fail in degraded manner but I understand this may
> not be
> possible.
>

During the initial discussion, we discussed adding a new error code in case
of an
invalid FDT, something like BSP_INVALID_FDT. I had also sent a patch but
then we
decided not to add one(for some reason that I don't remember). Instead, use
RTEMS_NOT_CONFIGURED. This has also been used in my previous OFW patch.
So should we add a new error code like BSP_INVALID_FDT and fatal exit or
just
use RTEMS_NOT_CONIGURED like the previous patch?

>
> > +  assert(rv == 0);
>
> I would prefer we did not make this code dependent on -DNDEBUG.
>
> Chris
>
> > +
> > +  fdtp = fdt;
> > +}
> > +
> > +RTEMS_SYSINIT_ITEM(
> > +  rtems_ofw_init,
> > +  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
> > +  RTEMS_SYSINIT_ORDER_FIRST
> > +);
> > +
> > +phandle_t rtems_ofw_peer( phandle_t node )
> > +{
> > +  int offset;
> > +
> > +  if (node == 0) {
> > +int root = fdt_path_offset(fdtp, "/");
> > +return rtems_fdt_offset_to_phandle(root);
> > +  }
> > +
> > +  offset = rtems_fdt_phandle_to_offset(node);
> > +  if (offset < 0) {
> > +return 0;
> > +  }
> > +
> > +  offset = fdt_next_subnode(fdtp, offset);
> > +  return rtems_fdt_offset_to_phandle(offset);
> > +}
> > +
> > +phandle_t rtems_ofw_child( phandle_t node )
> > +{
> > +  int offset;
> > +
> > +  offset = rtems_fdt_phandle_to_offset(node);
> > +
> > +  if (offset < 0) {
> > +return 0;
> > +  }
> > +
> > +  offset = fdt_first_subnode(fdtp, offset);
> > +  return rtems_fdt_offset_to_phandle(offset);
> > +}
> > +
> > +phandle_t rtems_ofw_parent( phandle_t node )
> > +{
> > +  int offset;
> > +
> > +  offset = rtems_fdt_phandle_to_offset(node);
> > +
> > +  if (offset < 0) {
> > +return 0;
> > +  }
> > +
> > +  offset = fdt_parent_offset(fdtp, offset);
> > +  return rtems_fdt_offset_to_phandle(offset);
> > +}
> > +
> > +size_t rtems_ofw_get_prop_len(
> > +  phandle_t node,
> > +  const char *propname
> > +)
> > +{
> > +  int offset;
> > +  int len;
> > +  const void *prop;
> > +
> > +  offset = rtems_fdt_phandle_to_offset(node);
> > +
> > +  if (offset < 0) {
> > +return -1;
> > +  }
> > +
> > +  prop = fdt_getprop(fdtp, offset, propname, &len);
> > +
> > +  if (prop == NULL && strcmp(propname, "name") == 0) {
> > +fdt_get_name(fdtp, offset, &len);
> > +return len + 1;
> > +  }
> > +
> > +  if (prop == NULL && strcmp(propname, "/chosen") == 0) {
> > +if (strcmp(propname, "fdtbootcpu") == 0)
> > +  return sizeof(pcell_t);
> > +if (strcmp(propname, "fdtmemreserv") == 0)
> > +  return 2 * sizeof(uint64_t) * fdt_num_mem_rsv(fdtp);
> > +  }
> > +
> > +  if (prop == NULL) {
> > +return -1;
> > +  }
> > +
> > +  return len;
> > +}
> > +
> > +size_t rtems_ofw_get_prop(
> > +  phandle_tnode,
> > +  const char  *propname,
> > +  void*buf,
> > +  size_t   bufsize
> > +)
> > +{
> > +  int offset;
> > +  int len;
> > +  const void *prop;
> > +
> > +  offset = rtems_fdt_phandle_to_offset(node);
> > +
> > +  if (offset < 0) {
> > +return -1;
> > +  }
> > +
> > +  prop = fdt_getprop(fdtp, offset, propname, &len);
> > +
> > +  if (prop == NULL && strcmp(propname, "name") == 0) {
> > +fdt_get_name(fdtp, offset, &len);
> > +return len + 1;
> > +  }
> > +
> > +  if (prop == NULL && strcmp(propname, "/chosen") == 0) {
> > +if (strcmp(propname, "fdtbootcpu") == 0)
> > +  return sizeof(pcell_t);
> > +if (strcmp(propname, "fdtmemreserv") == 0)
> > +  return 2 * sizeof(uint64_t) * fdt_num_mem_rsv(fdtp);
> > +  }
> > +
> > +  if (prop == NULL) {
> > +return -1;
> > +  }
> > +
> > +  bcopy(prop, buf, MIN(len, bufsize));
> > +
> > +  return len;
> > +}
> > +
> > +size_t rtems_o

Re: Context switching through an ISR in RTEMS

[Gedare Bloom]

On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai  wrote:
>
>
>
> On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai  wrote:
>>
>>
>>
>> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom  wrote:
>>>
>>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai  wrote:
>>> >
>>> >
>>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai  
>>> > wrote:
>>> >>
>>> >> Thanks, I'll check them out.
>>> >>
>>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom  wrote:
>>> >>>
>>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai  
>>> >>> wrote:
>>> >>> >
>>> >>> > Hello,
>>> >>> > I have been testing my code for thread stack isolation against 
>>> >>> > various tests( Some written by me, and remaining already present). 
>>> >>> > One of the limitations that I have found is that I encounter fatal 
>>> >>> > errors whenever a context switch takes place through an ISR. Can you 
>>> >>> > please explain how the context switching procedure works when an 
>>> >>> > interrupt occurs. When I use gdb for stepping through the code it 
>>> >>> > asynchronously moves to context switching code from the executing 
>>> >>> > thread( for example psx16 test).
>>> >>> > For thread stack protection,  the part that deals with context 
>>> >>> > switching simply 'sets 'the memory entries of the heir stack and 
>>> >>> > 'unsets' that of the executing stack.
>>> >>>
>>> >>> There are two issues to start: interrupt stacks and dispatching from an 
>>> >>> ISR.
>>> >>>
>>> >>> I think you can start by reading some of the documentation:
>>> >>> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
>>> >>>
>>> >>> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
>>> >>>
>>> >>> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
>>> >>>
>>> >>> https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
>>> >>>
>>> >>> You can also find some material in rtems-docs.git/porting -- I don't
>>> >>> know where that gets generated.
>>> >>>
>>> >>> Continue to ask questions, and writing blog posts.
>>> >
>>> >
>>> > So after going through the materials, I was able to understand how an ISR 
>>> > is registered, ISR stack initialization. What is still not clear to me is 
>>> > what are the differences between dispatching a task in ISR different and  
>>> > a normal context-switch?
>>> >
>>> > For example the psxsignal06 test, we wait for a signal here,  on setting 
>>> > the breakpoint at the context switch code (cpu_asm.S), after this line,  
>>> > I find that the heir context stack is the ISR stack. The next thread is 
>>> > dispatched from this ISR but as soon as I unset the memory attributes of 
>>> > the ISR stack I get a fatal error. One possible reason is that the ISR 
>>> > stack is not page aligned and unsettling its attributes unsets nearby 
>>> > memory regions. Is there something else that I am missing?
>>> >
>>> what else is on the same page as the ISR stack?
>>>
>>
>> The idle thread stack is between 0x202e40 to 0x203e40 and the ISR stack is 
>> between 0x203e40 to 0x204e40. So when we unset the memory for the ISR it 
>> unsets between 0x203000 to 0x205000, I think this may be the problem.
>>
>>
>>>
>>> Not quite related, you'll need to also make sure to map the ISR stack
>>> back in during ISR Handling, before using it.
>>
>>
>> When the ISR gets called for the first time, it already has R/W permission 
>> and for subsequent context switches it's memory entry is accordingly 
>> set/unset.
>
>
> The idle thread stack and the ISR stack are placed at these addresses with 
> the BSP specific linker script as "rtemsstack.idle" and 
> "rtemsstack.interrupt". So to make them page-aligned we may have to make 
> changes in the lnker script.

Give it a try. It should be relatively easy to hack in a couple of alignments.

We can discuss later the correctness of that.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC 2020]: Need help in writing sed alternative in Python for RSB recipes

[Gedare Bloom]

On Sun, Aug 16, 2020 at 4:16 AM Mritunjay Sharma
 wrote:
>
>
>
> On Sun, Aug 16, 2020 at 1:12 PM Chris Johns  wrote:
>>
>> On 16/8/20 8:29 am, Mritunjay Sharma wrote:
>> > On Sun, Aug 16, 2020 at 12:15 AM Gedare Bloom > > > wrote:
>> >
>> > Hi Mritunjay, Chris:
>> >
>> > For the RSB, since it is user-facing, we need to be sure to minimize
>> > its dependencies on the user environment and platform. So this pycli
>> > can only be used if it is distributed standard with Python 2 and
>> > Python 3.
>> >
>> > Would someone be able to apply this patch and use it to build epics?
>> > No, because (1) they won't have pycli available, and (2) they don't
>> > have a path /home/mritunjay
>> >
>> >
>> > I think what you are saying is absolutely right. It will be really a great 
>> > help
>> > if Chris can guide on what next can be done.
>>
>> See below.
>>
>> > As far as 'pycli' is concerned, I have made a couple of minor tweaks. Gave 
>> > it a
>> > better name 'sedpy' and made it public on GitHub.
>> >
>> > Please find the link to the
>> > project here: https://github.com/mritunjaysharma394/sedpy
>>
>> Thanks but I currently do not see a need for this tool.
>>
>> > I will appreciate if mentors can have a look and try this and see if it in 
>> > any
>> > way can be modified
>> > to be used with RSB or else we will go with what is suggested.
>>
>> Please put the RSB to one side. I will let you know when we can return to it.
>>
>> I believe patching config files in EPCIS from the RSB is fragile. EPICS 
>> should
>> be free to change any of these files without needing to considering the 
>> effect
>> it has on the RSB. Just because we can peek inside does not means we are 
>> free to
>> exploit what we see.
>>
>> What happens if you define the needed variables on the make command line? For
>> example:
>>
>>  gmake RTEMS_BASE=$HOME/development/rtems/5 RTEMS_VERSION=5.1-rc2
>>
>> These variables are just normal make ones and so they can be overridden from 
>> the
>> command line.
>>
>> Please investigate this and see what happens?
>
>
> Hi Chris,
> I investigated and used:
>
>  `make RTEMS_BASE=$HOME/development/rtems/5-arm RTEMS_VERSION=5`
>
> This worked perfectly fine and the build was successful. Thank you so much 
> for telling this. It makes it so
> easy. What can we do next? This surely removes the requirement of `sed` or 
> the tool I built to make command line changes.
>

Of course! (I got stuck too far down the rabbit hole to see the
problem.) Now, you should attempt to rebuild EPICS for the two BSPs
you've done, but this time inject the configuration flags on the make
command lines etc. Once you've done this, then you will need to
revisit RSB to see how to write the code that can do the same thing.

That should only leave us with the last 'todo' of figuring out how to
use epics-base instead of Heinz' playground. If you can start to
figure out the differences between those two, I think that could be a
good start.

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

Re: Context switching through an ISR in RTEMS

[Utkarsh Rai]

On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom  wrote:

> On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai 
> wrote:
> >
> >
> >
> > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai 
> wrote:
> >>
> >>
> >>
> >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom  wrote:
> >>>
> >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai 
> wrote:
> >>> >
> >>> >
> >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai 
> wrote:
> >>> >>
> >>> >> Thanks, I'll check them out.
> >>> >>
> >>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom 
> wrote:
> >>> >>>
> >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai <
> utkarsh.ra...@gmail.com> wrote:
> >>> >>> >
> >>> >>> > Hello,
> >>> >>> > I have been testing my code for thread stack isolation against
> various tests( Some written by me, and remaining already present). One of
> the limitations that I have found is that I encounter fatal errors whenever
> a context switch takes place through an ISR. Can you please explain how the
> context switching procedure works when an interrupt occurs. When I use gdb
> for stepping through the code it asynchronously moves to context switching
> code from the executing thread( for example psx16 test).
> >>> >>> > For thread stack protection,  the part that deals with context
> switching simply 'sets 'the memory entries of the heir stack and 'unsets'
> that of the executing stack.
> >>> >>>
> >>> >>> There are two issues to start: interrupt stacks and dispatching
> from an ISR.
> >>> >>>
> >>> >>> I think you can start by reading some of the documentation:
> >>> >>>
> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
> >>> >>>
> >>> >>>
> https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
> >>> >>>
> >>> >>>
> https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
> >>> >>>
> >>> >>>
> https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
> >>> >>>
> >>> >>> You can also find some material in rtems-docs.git/porting -- I
> don't
> >>> >>> know where that gets generated.
> >>> >>>
> >>> >>> Continue to ask questions, and writing blog posts.
> >>> >
> >>> >
> >>> > So after going through the materials, I was able to understand how
> an ISR is registered, ISR stack initialization. What is still not clear to
> me is what are the differences between dispatching a task in ISR different
> and  a normal context-switch?
> >>> >
> >>> > For example the psxsignal06 test, we wait for a signal here,  on
> setting the breakpoint at the context switch code (cpu_asm.S), after this
> line,  I find that the heir context stack is the ISR stack. The next thread
> is dispatched from this ISR but as soon as I unset the memory attributes of
> the ISR stack I get a fatal error. One possible reason is that the ISR
> stack is not page aligned and unsettling its attributes unsets nearby
> memory regions. Is there something else that I am missing?
> >>> >
> >>> what else is on the same page as the ISR stack?
> >>>
> >>
> >> The idle thread stack is between 0x202e40 to 0x203e40 and the ISR stack
> is between 0x203e40 to 0x204e40. So when we unset the memory for the ISR it
> unsets between 0x203000 to 0x205000, I think this may be the problem.
> >>
> >>
> >>>
> >>> Not quite related, you'll need to also make sure to map the ISR stack
> >>> back in during ISR Handling, before using it.
> >>
> >>
> >> When the ISR gets called for the first time, it already has R/W
> permission and for subsequent context switches it's memory entry is
> accordingly set/unset.
> >
> >
> > The idle thread stack and the ISR stack are placed at these addresses
> with the BSP specific linker script as "rtemsstack.idle" and
> "rtemsstack.interrupt". So to make them page-aligned we may have to make
> changes in the lnker script.
>
> Give it a try. It should be relatively easy to hack in a couple of
> alignments.
>
> We can discuss later the correctness of that.
>

Ok, I will report how it goes.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help in figuring out why gdb gives different value of a variable in callee vs caller context

[Richi Dubey]

Hi,

The gdb trace above refers to this

code
where the items in all_Nodes chain are checked. The items in the chain are
getting inserted here
,
before which on line 763, the Affinity of the items is set to all the
online processors. Why does the gdb show the Affinity of the node as 0
then? How is this possible? Please advise.

On Sun, Aug 16, 2020 at 5:48 PM Richi Dubey  wrote:

> Oh, I printed the variable value too early. Thanks for your help.
>
> On Sat, Aug 15, 2020 at 7:24 PM Gedare Bloom  wrote:
>
>> On Sat, Aug 15, 2020 at 3:15 AM Richi Dubey  wrote:
>> >
>> > Hi,
>> >
>> > With reference to the code (github link), it aims to check if the
>> Affinty of a node is set to 0 by calling the function
>> _Processor_mask_Is_zero.
>> >
>> > While debugging with gdb, I can see using 'p' command that the variable
>> is indeed 0 but after the variable gets passed to the function, the value
>> of the variable isn't 0 anymore. Why is this happening?
>> >
>> > Gdb trace:
>> > --
>> > (gdb)
>> > 0x00118af4 187 _Processor_mask_Is_set(&node->Affinity,
>> _Per_CPU_Get_index(curr_CPU) ||
>> > (gdb)
>> > 0x00118af6 187 _Processor_mask_Is_set(&node->Affinity,
>> _Per_CPU_Get_index(curr_CPU) ||
>> > (gdb) p &node->Affinity
>> > $8 = (Processor_mask *) 0x200efc <_Thread_Objects+2172>
>> address 0x200efc
>>
>> > (gdb) p node->Affinity
>> > $9 = {
>> >   __bits = {0}
>> > }
>> > (gdb) si
>> > 0x00118af8 187 _Processor_mask_Is_set(&node->Affinity,
>> _Per_CPU_Get_index(curr_CPU) ||
>> > (gdb)
>> > 190 _Processor_mask_Is_zero( &node->Affinity ) )
>> > (gdb)
>> > 0x00118afc 190 _Processor_mask_Is_zero( &node->Affinity ) )
>> > (gdb)
>> > 0x00118afe 190 _Processor_mask_Is_zero( &node->Affinity ) )
>> > (gdb)
>> > 0x00118b00 190 _Processor_mask_Is_zero( &node->Affinity ) )
>> > (gdb)
>> > _Processor_mask_Is_zero (mask=0x203580 <_Per_CPU_Information>) at
>> /home/richi/quick-start/src/rtems/cpukit/include/rtems/score/processormask.h:75
>> > 75 {
>> > (gdb)
>> > 0x0011726a 75 {
>> > (gdb)
>> > 0x0011726c 75 {
>> > (gdb) p mask
>> > $10 = (const Processor_mask *) 0x203580 <_Per_CPU_Information>
>> address 0x203580
>>
>> You're not looking at the same memory location
>>
>> > (gdb) p *mask
>> > $11 = {
>> >   __bits = {2126656}
>> > }
>> > 
>> >
>> > Please provide your views on this.
>> > Thanks,
>> > Richi,
>> > ___
>> > 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] bsps/shared/ofw: Implement RTEMS OFW interface

[Chris Johns]

On 16/8/20 11:19 pm, Niteesh G. S. wrote:
> 
> On Sun, Aug 16, 2020 at 2:25 PM Chris Johns  > wrote:
> 
> On 16/8/20 4:49 am, G S Niteesh Babu wrote:
> > ---
> 
> > +
> > +#ifdef HAVE_CONFIG_H
> > +#include "config.h"
> > +#endif
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +const void *fdtp = NULL;
> > +
> > +static phandle_t rtems_fdt_offset_to_phandle( int offset )
> > +{
> > +  if (offset < 0) {
> > +    return 0;
> > +  }
> > +
> > +  return (phandle_t)offset + fdt_off_dt_struct(fdtp);
> > +}
> > +
> > +static int rtems_fdt_phandle_to_offset( phandle_t handle )
> > +{
> > +  int off;
> > +  int fdt_off;
> > +
> > +  off = (int) handle;
> > +  fdt_off = fdt_off_dt_struct(fdtp);
> > +
> > +  if (off < fdt_off) {
> > +    return -1;
> > +
> > +  }
> > +
> > +  return off - fdt_off;
> > +}
> > +
> > +static void rtems_ofw_init( void ) {
> > +  int rv;
> > +  const void *fdt;
> > + 
> > +  fdt = bsp_fdt_get();
> > +
> > +  rv = fdt_check_header(fdt);
> > +
> > +  /*
> > +   * Is assert a good option to handle error?
> > +   * AFIAK there is no other way to recover from invalid FDT.
> > +   * On providing an invalid FDT most driver's will fail/crash anyway.
> > +   */
> 
> If you want to fail with an error I suggest a documented internal error. I
> however would prefer we fail in degraded manner but I understand this may 
> not be
> possible.
> 
> 
> During the initial discussion, we discussed adding a new error code in case 
> of an
> invalid FDT, something like BSP_INVALID_FDT. I had also sent a patch but then 
> we
> decided not to add one(for some reason that I don't remember). Instead, use
> RTEMS_NOT_CONFIGURED. This has also been used in my previous OFW patch.

I am sorry I missed the discussion or I would have commented. Currently the FDT
support in RTEMS is hostile. If you build a u-boot image and forget to add FDT
support added you get a low level crash dump and that is unfriendly. I woud like
to this changed.

> So should we add a new error code like BSP_INVALID_FDT and fatal exit or just
> use RTEMS_NOT_CONIGURED like the previous patch?

Not configured is fine with me.

Chris
> 
> 
> > +  assert(rv == 0);
> 
> I would prefer we did not make this code dependent on -DNDEBUG.
> 
> Chris
> 
> > +
> > +  fdtp = fdt;
> > +}
> > +
> > +RTEMS_SYSINIT_ITEM(
> > +  rtems_ofw_init,
> > +  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
> > +  RTEMS_SYSINIT_ORDER_FIRST
> > +);
> > +
> > +phandle_t rtems_ofw_peer( phandle_t node )
> > +{
> > +  int offset;
> > +
> > +  if (node == 0) {
> > +    int root = fdt_path_offset(fdtp, "/");
> > +    return rtems_fdt_offset_to_phandle(root);
> > +  }
> > +
> > +  offset = rtems_fdt_phandle_to_offset(node);
> > +  if (offset < 0) {
> > +    return 0;
> > +  }
> > +
> > +  offset = fdt_next_subnode(fdtp, offset);
> > +  return rtems_fdt_offset_to_phandle(offset);
> > +}
> > +
> > +phandle_t rtems_ofw_child( phandle_t node )
> > +{
> > +  int offset;
> > +
> > +  offset = rtems_fdt_phandle_to_offset(node);
> > +
> > +  if (offset < 0) {
> > +    return 0;
> > +  }
> > +
> > +  offset = fdt_first_subnode(fdtp, offset);
> > +  return rtems_fdt_offset_to_phandle(offset);
> > +}
> > +
> > +phandle_t rtems_ofw_parent( phandle_t node )
> > +{
> > +  int offset;
> > +
> > +  offset = rtems_fdt_phandle_to_offset(node);
> > +
> > +  if (offset < 0) {
> > +    return 0;
> > +  }
> > +
> > +  offset = fdt_parent_offset(fdtp, offset);
> > +  return rtems_fdt_offset_to_phandle(offset);
> > +}
> > +
> > +size_t rtems_ofw_get_prop_len(
> > +  phandle_t node,
> > +  const char *propname
> > +)
> > +{
> > +  int offset;
> > +  int len;
> > +  const void *prop;
> > +
> > +  offset = rtems_fdt_phandle_to_offset(node);
> > +
> > +  if (offset < 0) {
> > +    return -1;
> > +  }
> > +
> > +  prop = fdt_getprop(fdtp, offset, propname, &len);
> > +
> > +  if (prop == NULL && strcmp(propname, "name") == 0) {
> > +    fdt_get_name(fdtp, offset, &len);
> > +    return len + 1;
> > +  }
> > +
> > +  if (prop == NULL && strcmp(propname, "/chosen") == 0) {
> > +    if (strcmp(propname, "fdtbootcpu") == 0)
> > +      return sizeof(pcell_t);
> > +    if (strcmp(propname, "fdtmemreserv") == 0)
> > +      return 2 * sizeof(uint64_t) * fdt_num_mem_rsv(fdtp);
> > +  }
> > +
> > +  if (prop == NULL) {
> > +    return -1;
> > +  }
> > +
> > +  retur

Re: Need help in figuring out why gdb gives different value of a variable in callee vs caller context

[Gedare Bloom]

This is wrong: 
https://github.com/richidubey/rtems/blob/c3162134d3fd7d4d46ec01609d81bdb62bc818af/cpukit/score/src/schedulerstrongapa.c#L182

It assumes the Chain_Node is at the start of the struct
Scheduler_strong_APA_Node.

On Sun, Aug 16, 2020 at 11:34 AM Richi Dubey  wrote:
>
> Hi,
>
> The gdb trace above refers to this code where the items in all_Nodes chain 
> are checked. The items in the chain are getting inserted here, before which 
> on line 763, the Affinity of the items is set to all the online processors. 
> Why does the gdb show the Affinity of the node as 0 then? How is this 
> possible? Please advise.
>
> On Sun, Aug 16, 2020 at 5:48 PM Richi Dubey  wrote:
>>
>> Oh, I printed the variable value too early. Thanks for your help.
>>
>> On Sat, Aug 15, 2020 at 7:24 PM Gedare Bloom  wrote:
>>>
>>> On Sat, Aug 15, 2020 at 3:15 AM Richi Dubey  wrote:
>>> >
>>> > Hi,
>>> >
>>> > With reference to the code (github link), it aims to check if the Affinty 
>>> > of a node is set to 0 by calling the function _Processor_mask_Is_zero.
>>> >
>>> > While debugging with gdb, I can see using 'p' command that the variable 
>>> > is indeed 0 but after the variable gets passed to the function, the value 
>>> > of the variable isn't 0 anymore. Why is this happening?
>>> >
>>> > Gdb trace:
>>> > --
>>> > (gdb)
>>> > 0x00118af4 187 _Processor_mask_Is_set(&node->Affinity, 
>>> > _Per_CPU_Get_index(curr_CPU) ||
>>> > (gdb)
>>> > 0x00118af6 187 _Processor_mask_Is_set(&node->Affinity, 
>>> > _Per_CPU_Get_index(curr_CPU) ||
>>> > (gdb) p &node->Affinity
>>> > $8 = (Processor_mask *) 0x200efc <_Thread_Objects+2172>
>>> address 0x200efc
>>>
>>> > (gdb) p node->Affinity
>>> > $9 = {
>>> >   __bits = {0}
>>> > }
>>> > (gdb) si
>>> > 0x00118af8 187 _Processor_mask_Is_set(&node->Affinity, 
>>> > _Per_CPU_Get_index(curr_CPU) ||
>>> > (gdb)
>>> > 190 _Processor_mask_Is_zero( &node->Affinity ) )
>>> > (gdb)
>>> > 0x00118afc 190 _Processor_mask_Is_zero( &node->Affinity ) )
>>> > (gdb)
>>> > 0x00118afe 190 _Processor_mask_Is_zero( &node->Affinity ) )
>>> > (gdb)
>>> > 0x00118b00 190 _Processor_mask_Is_zero( &node->Affinity ) )
>>> > (gdb)
>>> > _Processor_mask_Is_zero (mask=0x203580 <_Per_CPU_Information>) at 
>>> > /home/richi/quick-start/src/rtems/cpukit/include/rtems/score/processormask.h:75
>>> > 75 {
>>> > (gdb)
>>> > 0x0011726a 75 {
>>> > (gdb)
>>> > 0x0011726c 75 {
>>> > (gdb) p mask
>>> > $10 = (const Processor_mask *) 0x203580 <_Per_CPU_Information>
>>> address 0x203580
>>>
>>> You're not looking at the same memory location
>>>
>>> > (gdb) p *mask
>>> > $11 = {
>>> >   __bits = {2126656}
>>> > }
>>> > 
>>> >
>>> > Please provide your views on this.
>>> > Thanks,
>>> > Richi,
>>> > ___
>>> > 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: Need help in figuring out why gdb gives different value of a variable in callee vs caller context

[Richi Dubey]

Thanks a lot! This is why get_highest_ready was causing problems. I
couldn't have figured it out by myself.

On Mon, Aug 17, 2020 at 4:14 AM Gedare Bloom  wrote:

> This is wrong:
> https://github.com/richidubey/rtems/blob/c3162134d3fd7d4d46ec01609d81bdb62bc818af/cpukit/score/src/schedulerstrongapa.c#L182
>
> It assumes the Chain_Node is at the start of the struct
> Scheduler_strong_APA_Node.
>
> On Sun, Aug 16, 2020 at 11:34 AM Richi Dubey  wrote:
> >
> > Hi,
> >
> > The gdb trace above refers to this code where the items in all_Nodes
> chain are checked. The items in the chain are getting inserted here, before
> which on line 763, the Affinity of the items is set to all the online
> processors. Why does the gdb show the Affinity of the node as 0 then? How
> is this possible? Please advise.
> >
> > On Sun, Aug 16, 2020 at 5:48 PM Richi Dubey 
> wrote:
> >>
> >> Oh, I printed the variable value too early. Thanks for your help.
> >>
> >> On Sat, Aug 15, 2020 at 7:24 PM Gedare Bloom  wrote:
> >>>
> >>> On Sat, Aug 15, 2020 at 3:15 AM Richi Dubey 
> wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > With reference to the code (github link), it aims to check if the
> Affinty of a node is set to 0 by calling the function
> _Processor_mask_Is_zero.
> >>> >
> >>> > While debugging with gdb, I can see using 'p' command that the
> variable is indeed 0 but after the variable gets passed to the function,
> the value of the variable isn't 0 anymore. Why is this happening?
> >>> >
> >>> > Gdb trace:
> >>> >
> --
> >>> > (gdb)
> >>> > 0x00118af4 187 _Processor_mask_Is_set(&node->Affinity,
> _Per_CPU_Get_index(curr_CPU) ||
> >>> > (gdb)
> >>> > 0x00118af6 187 _Processor_mask_Is_set(&node->Affinity,
> _Per_CPU_Get_index(curr_CPU) ||
> >>> > (gdb) p &node->Affinity
> >>> > $8 = (Processor_mask *) 0x200efc <_Thread_Objects+2172>
> >>> address 0x200efc
> >>>
> >>> > (gdb) p node->Affinity
> >>> > $9 = {
> >>> >   __bits = {0}
> >>> > }
> >>> > (gdb) si
> >>> > 0x00118af8 187 _Processor_mask_Is_set(&node->Affinity,
> _Per_CPU_Get_index(curr_CPU) ||
> >>> > (gdb)
> >>> > 190 _Processor_mask_Is_zero( &node->Affinity ) )
> >>> > (gdb)
> >>> > 0x00118afc 190 _Processor_mask_Is_zero( &node->Affinity ) )
> >>> > (gdb)
> >>> > 0x00118afe 190 _Processor_mask_Is_zero( &node->Affinity ) )
> >>> > (gdb)
> >>> > 0x00118b00 190 _Processor_mask_Is_zero( &node->Affinity ) )
> >>> > (gdb)
> >>> > _Processor_mask_Is_zero (mask=0x203580 <_Per_CPU_Information>) at
> /home/richi/quick-start/src/rtems/cpukit/include/rtems/score/processormask.h:75
> >>> > 75 {
> >>> > (gdb)
> >>> > 0x0011726a 75 {
> >>> > (gdb)
> >>> > 0x0011726c 75 {
> >>> > (gdb) p mask
> >>> > $10 = (const Processor_mask *) 0x203580 <_Per_CPU_Information>
> >>> address 0x203580
> >>>
> >>> You're not looking at the same memory location
> >>>
> >>> > (gdb) p *mask
> >>> > $11 = {
> >>> >   __bits = {2126656}
> >>> > }
> >>> > 
> >>> >
> >>> > Please provide your views on this.
> >>> > Thanks,
> >>> > Richi,
> >>> > ___
> >>> > 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] bsps/shared/ofw: Implement RTEMS OFW interface

[Niteesh G. S.]

On Mon, Aug 17, 2020 at 3:49 AM Chris Johns  wrote:

> On 16/8/20 11:19 pm, Niteesh G. S. wrote:
> >
> > On Sun, Aug 16, 2020 at 2:25 PM Chris Johns  > > wrote:
> >
> > On 16/8/20 4:49 am, G S Niteesh Babu wrote:
> > > ---
> >
> > > +
> > > +#ifdef HAVE_CONFIG_H
> > > +#include "config.h"
> > > +#endif
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +const void *fdtp = NULL;
> > > +
> > > +static phandle_t rtems_fdt_offset_to_phandle( int offset )
> > > +{
> > > +  if (offset < 0) {
> > > +return 0;
> > > +  }
> > > +
> > > +  return (phandle_t)offset + fdt_off_dt_struct(fdtp);
> > > +}
> > > +
> > > +static int rtems_fdt_phandle_to_offset( phandle_t handle )
> > > +{
> > > +  int off;
> > > +  int fdt_off;
> > > +
> > > +  off = (int) handle;
> > > +  fdt_off = fdt_off_dt_struct(fdtp);
> > > +
> > > +  if (off < fdt_off) {
> > > +return -1;
> > > +
> > > +  }
> > > +
> > > +  return off - fdt_off;
> > > +}
> > > +
> > > +static void rtems_ofw_init( void ) {
> > > +  int rv;
> > > +  const void *fdt;
> > > +
> > > +  fdt = bsp_fdt_get();
> > > +
> > > +  rv = fdt_check_header(fdt);
> > > +
> > > +  /*
> > > +   * Is assert a good option to handle error?
> > > +   * AFIAK there is no other way to recover from invalid FDT.
> > > +   * On providing an invalid FDT most driver's will fail/crash
> anyway.
> > > +   */
> >
> > If you want to fail with an error I suggest a documented internal
> error. I
> > however would prefer we fail in degraded manner but I understand
> this may not be
> > possible.
> >
> >
> > During the initial discussion, we discussed adding a new error code in
> case of an
> > invalid FDT, something like BSP_INVALID_FDT. I had also sent a patch but
> then we
> > decided not to add one(for some reason that I don't remember). Instead,
> use
> > RTEMS_NOT_CONFIGURED. This has also been used in my previous OFW patch.
>
> I am sorry I missed the discussion or I would have commented. Currently
> the FDT
> support in RTEMS is hostile. If you build a u-boot image and forget to add
> FDT
> support added you get a low level crash dump and that is unfriendly. I
> woud like
> to this changed.
>

So should we add a proper fatal code in case of invalid FDT or FDT is not
provided?
ARM, POWERPC and RISCV are the only architectures in RTEMS that use FDT.
Can we add an FDT check inside start.S before bsp_fdt_copy? and fail
properly in
case of an invalid FDT.
Or is it a better idea to add the check inside bsp_fdt_copy but
bsp_fdt_copy is optional
in architectures like ARM, RISCV it is compile time guarded with
BSP_START_COPY_FDT_FROM_UBOOT

> So should we add a new error code like BSP_INVALID_FDT and fatal exit or
> just
> > use RTEMS_NOT_CONIGURED like the previous patch?
>
> Not configured is fine with me.
>
> Chris
> >
> >
> > > +  assert(rv == 0);
> >
> > I would prefer we did not make this code dependent on -DNDEBUG.
> >
> > Chris
> >
> > > +
> > > +  fdtp = fdt;
> > > +}
> > > +
> > > +RTEMS_SYSINIT_ITEM(
> > > +  rtems_ofw_init,
> > > +  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
> > > +  RTEMS_SYSINIT_ORDER_FIRST
> > > +);
> > > +
> > > +phandle_t rtems_ofw_peer( phandle_t node )
> > > +{
> > > +  int offset;
> > > +
> > > +  if (node == 0) {
> > > +int root = fdt_path_offset(fdtp, "/");
> > > +return rtems_fdt_offset_to_phandle(root);
> > > +  }
> > > +
> > > +  offset = rtems_fdt_phandle_to_offset(node);
> > > +  if (offset < 0) {
> > > +return 0;
> > > +  }
> > > +
> > > +  offset = fdt_next_subnode(fdtp, offset);
> > > +  return rtems_fdt_offset_to_phandle(offset);
> > > +}
> > > +
> > > +phandle_t rtems_ofw_child( phandle_t node )
> > > +{
> > > +  int offset;
> > > +
> > > +  offset = rtems_fdt_phandle_to_offset(node);
> > > +
> > > +  if (offset < 0) {
> > > +return 0;
> > > +  }
> > > +
> > > +  offset = fdt_first_subnode(fdtp, offset);
> > > +  return rtems_fdt_offset_to_phandle(offset);
> > > +}
> > > +
> > > +phandle_t rtems_ofw_parent( phandle_t node )
> > > +{
> > > +  int offset;
> > > +
> > > +  offset = rtems_fdt_phandle_to_offset(node);
> > > +
> > > +  if (offset < 0) {
> > > +return 0;
> > > +  }
> > > +
> > > +  offset = fdt_parent_offset(fdtp, offset);
> > > +  return rtems_fdt_offset_to_phandle(offset);
> > > +}
> > > +
> > > +size_t rtems_ofw_get_prop_len(
> > > +  phandle_t node,
> > > +  const char *propname
> > > +)
> > > +{
> > > +  int offset;
> > > +  int len;
> > > +  co

Re: Context switching through an ISR in RTEMS

[Sebastian Huber]

On 16/08/2020 18:09, Utkarsh Rai wrote:




On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom > wrote:


On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai
mailto:utkarsh.ra...@gmail.com>> wrote:
>
>
>
> On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai
mailto:utkarsh.ra...@gmail.com>> wrote:
>>
>>
>>
>> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom mailto:ged...@rtems.org>> wrote:
>>>
>>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai
mailto:utkarsh.ra...@gmail.com>> wrote:
>>> >
>>> >
>>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai
mailto:utkarsh.ra...@gmail.com>> wrote:
>>> >>
>>> >> Thanks, I'll check them out.
>>> >>
>>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom
mailto:ged...@rtems.org>> wrote:
>>> >>>
>>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai
mailto:utkarsh.ra...@gmail.com>> wrote:
>>> >>> >
>>> >>> > Hello,
>>> >>> > I have been testing my code for thread stack isolation
against various tests( Some written by me, and remaining already
present). One of the limitations that I have found is that I
encounter fatal errors whenever a context switch takes place
through an ISR. Can you please explain how the context switching
procedure works when an interrupt occurs. When I use gdb for
stepping through the code it asynchronously moves to context
switching code from the executing thread( for example psx16 test).
>>> >>> > For thread stack protection, the part that deals with
context switching simply 'sets 'the memory entries of the heir
stack and 'unsets' that of the executing stack.
>>> >>>
>>> >>> There are two issues to start: interrupt stacks and
dispatching from an ISR.
>>> >>>
>>> >>> I think you can start by reading some of the documentation:
>>> >>>

https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
>>> >>>
>>> >>>

https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
>>> >>>
>>> >>>

https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
>>> >>>
>>> >>>

https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
>>> >>>
>>> >>> You can also find some material in rtems-docs.git/porting
-- I don't
>>> >>> know where that gets generated.
>>> >>>
>>> >>> Continue to ask questions, and writing blog posts.
>>> >
>>> >
>>> > So after going through the materials, I was able to
understand how an ISR is registered, ISR stack initialization.
What is still not clear to me is what are the differences between
dispatching a task in ISR different and  a normal context-switch?
>>> >
>>> > For example the psxsignal06 test, we wait for a signal
here,  on setting the breakpoint at the context switch code
(cpu_asm.S), after this line,  I find that the heir context stack
is the ISR stack. The next thread is dispatched from this ISR but
as soon as I unset the memory attributes of the ISR stack I get a
fatal error. One possible reason is that the ISR stack is not page
aligned and unsettling its attributes unsets nearby memory
regions. Is there something else that I am missing?
>>> >
>>> what else is on the same page as the ISR stack?
>>>
>>
>> The idle thread stack is between 0x202e40 to 0x203e40 and the
ISR stack is between 0x203e40 to 0x204e40. So when we unset the
memory for the ISR it unsets between 0x203000 to 0x205000, I think
this may be the problem.
>>
>>
>>>
>>> Not quite related, you'll need to also make sure to map the
ISR stack
>>> back in during ISR Handling, before using it.
>>
>>
>> When the ISR gets called for the first time, it already has R/W
permission and for subsequent context switches it's memory entry
is accordingly set/unset.
>
>
> The idle thread stack and the ISR stack are placed at these
addresses with the BSP specific linker script as "rtemsstack.idle"
and "rtemsstack.interrupt". So to make them page-aligned we may
have to make changes in the lnker script.

Give it a try. It should be relatively easy to hack in a couple of
alignments.

We can discuss later the correctness of that.

Ok, I will report how it goes.


Please use the CPU port option

#define CPU_INTERRUPT_STACK_ALIGNMENT CPU_CACHE_LINE_BYTES

to define the interrupt and idle stack alignment. There is no need to 
change the linker command file.


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