Re: [PATCH 2/4] bsps/shared/ofw: Use memcpy instead of strncpy

[Christian Mauderer]

On 06/02/2021 06:02, Niteesh G. S. wrote:

Hello Christian,

On Sat, Feb 6, 2021 at 2:33 AM Christian Mauderer > wrote:


On 05/02/2021 19:22, Gedare Bloom wrote:
 >
 >
 > On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu
mailto:niteesh...@gmail.com>
 > >> wrote:
 >
 >     Changed rtems_ofw_get_prop to use memcpy instead of strncpy
 >     ---
 >       bsps/shared/ofw/ofw.c | 10 +-
 >       1 file changed, 9 insertions(+), 1 deletion(-)
 >
 >     diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
 >     index fa94bfbf05..9dec310247 100644
 >     --- a/bsps/shared/ofw/ofw.c
 >     +++ b/bsps/shared/ofw/ofw.c
 >     @@ -198,7 +198,15 @@ ssize_t rtems_ofw_get_prop(
 >
 >         if (prop == NULL && strcmp(propname, "name") == 0) {
 >           prop = fdt_get_name(fdtp, offset, &len);
 >     -    strncpy(buf, prop, bufsize);
 >     +
 >     +    bufsize = MIN(len, bufsize - 1);
 >
 > ok, reserving 1 byte for the \0. It could be worth adding a
comment here
 > to that effect

Is the content of that property really _allways_ a string? Isn't it
possible to read some references or similar with it?

Yes in this case it is always a string since we check if the propname == 
"name"
In other cases we use bcopy. I wanted to get this to your attention but 
then I

confused myself with endianness and thought it will still be an issue.


Sorry, I think that confusion has been caused by me. If the spec tells 
that "name" is always a string and can never be something else, keeping 
str*cpy is OK from my point of view. What do you think Gedare?




And as per the device tree spec, the node name is 1-31 chars length, 
consists

only of ASCII chars(Device tree spec table 2.1) and is null-terminated.


In that case enforcing null-termination might still be a good idea in 
case the buffer passed to this function is smaller or in case someone 
passes an invalid device tree.




If it is always a string, I might have made a useless suggestion. In
that case it might is more efficient and readable to just keep the
strncpy. Depending on the use case, maybe using strlcpy instead of
strncpy could be a good idea to guarantee the \0 termination.

As per docs, strlcpy  is  not  present  in glibc and is not standardized 
by POSIX,

so is it okay to use that?


As far as I know, newlib (the C library we use) has a strlcpy. It is 
already used in some rtems code (for example 
cpukit/score/src/threadname.c) so I don't see a problem using it.



If not I can use strncpy with a check like this

strncpy(buf, str, buflen - 1);

            if (buflen > 0)
                buf[buflen - 1]= '\0';
This ensures the buffer is always null terminated.

 >
 >     +    memcpy(buf, prop, bufsize);
 >     +
 >     +    /* Null terminate the buffer */
 >     +    *((char *)buf + bufsize) = 0;
 >
 > that gets written here. looks fine to me.
 >
 >     +
 >     +    /* Return the length of the name including the null byte */
 >     +    /* This is the behaviour in libBSD ofw_fdt_getprop */
 >           return len + 1;
 >
 > shouldn't it be bufsize+1? if it got truncated by the MIN?
 >
 >         }
 >
 >     --
 >     2.17.1
 >
 >
 > ___
 > devel mailing list
 > devel@rtems.org 
 > http://lists.rtems.org/mailman/listinfo/devel

 >


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

Re: [PATCH 2/4] bsps/shared/ofw: Use memcpy instead of strncpy

[Gedare Bloom]

On Sat, Feb 6, 2021 at 1:59 AM Christian Mauderer  wrote:

> On 06/02/2021 06:02, Niteesh G. S. wrote:
> > Hello Christian,
> >
> > On Sat, Feb 6, 2021 at 2:33 AM Christian Mauderer  > > wrote:
> >
> > On 05/02/2021 19:22, Gedare Bloom wrote:
> >  >
> >  >
> >  > On Fri, Feb 5, 2021 at 10:41 AM G S Niteesh Babu
> > mailto:niteesh...@gmail.com>
> >  > >>
> wrote:
> >  >
> >  > Changed rtems_ofw_get_prop to use memcpy instead of strncpy
> >  > ---
> >  >   bsps/shared/ofw/ofw.c | 10 +-
> >  >   1 file changed, 9 insertions(+), 1 deletion(-)
> >  >
> >  > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> >  > index fa94bfbf05..9dec310247 100644
> >  > --- a/bsps/shared/ofw/ofw.c
> >  > +++ b/bsps/shared/ofw/ofw.c
> >  > @@ -198,7 +198,15 @@ ssize_t rtems_ofw_get_prop(
> >  >
> >  > if (prop == NULL && strcmp(propname, "name") == 0) {
> >  >   prop = fdt_get_name(fdtp, offset, &len);
> >  > -strncpy(buf, prop, bufsize);
> >  > +
> >  > +bufsize = MIN(len, bufsize - 1);
> >  >
> >  > ok, reserving 1 byte for the \0. It could be worth adding a
> > comment here
> >  > to that effect
> >
> > Is the content of that property really _allways_ a string? Isn't it
> > possible to read some references or similar with it?
> >
> > Yes in this case it is always a string since we check if the propname ==
> > "name"
> > In other cases we use bcopy. I wanted to get this to your attention but
> > then I
> > confused myself with endianness and thought it will still be an issue.
>
> Sorry, I think that confusion has been caused by me. If the spec tells
> that "name" is always a string and can never be something else, keeping
> str*cpy is OK from my point of view. What do you think Gedare?
>
> Yes


> >
> > And as per the device tree spec, the node name is 1-31 chars length,
> > consists
> > only of ASCII chars(Device tree spec table 2.1) and is null-terminated.
>
> In that case enforcing null-termination might still be a good idea in
> case the buffer passed to this function is smaller or in case someone
> passes an invalid device tree.
>
> +1

And add a comment like you said about the spec.


> >
> > If it is always a string, I might have made a useless suggestion. In
> > that case it might is more efficient and readable to just keep the
> > strncpy. Depending on the use case, maybe using strlcpy instead of
> > strncpy could be a good idea to guarantee the \0 termination.
> >
> > As per docs, strlcpy  is  not  present  in glibc and is not standardized
> > by POSIX,
> > so is it okay to use that?
>
> As far as I know, newlib (the C library we use) has a strlcpy. It is
> already used in some rtems code (for example
> cpukit/score/src/threadname.c) so I don't see a problem using it.
>
>
We assume it exists inside of rtems.


> > If not I can use strncpy with a check like this
> >
> > strncpy(buf, str, buflen - 1);
> >
> > if (buflen > 0)
> > buf[buflen - 1]= '\0';
> > This ensures the buffer is always null terminated.
> >
> >  >
> >  > +memcpy(buf, prop, bufsize);
> >  > +
> >  > +/* Null terminate the buffer */
> >  > +*((char *)buf + bufsize) = 0;
> >  >
> >  > that gets written here. looks fine to me.
> >  >
> >  > +
> >  > +/* Return the length of the name including the null byte
> */
> >  > +/* This is the behaviour in libBSD ofw_fdt_getprop */
> >  >   return len + 1;
> >  >
> >  > shouldn't it be bufsize+1? if it got truncated by the MIN?
> >  >
> >  > }
> >  >
> >  > --
> >  > 2.17.1
> >  >
> >  >
> >  > ___
> >  > devel mailing list
> >  > devel@rtems.org 
> >  > http://lists.rtems.org/mailman/listinfo/devel
> > 
> >  >
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Completed Hello World task

[Gedare Bloom]

Hi Sanskar,

Welcome! Please send me a git-patch of your change to RTEMS.

We generally underspecify our project descriptions on purpose. The scope
that can be accomplished in the timeframe varies depending on individual
student experience and skills. So, we like to let the students explore the
projects and discuss with potential mentors in order to shape the proposal
in a way that suits the student's and mentors' interests with a scope that
is appropriate.

You should look through the projects and see if any look promising to you,
and then ask questions preferably on devel@rtems.org about the ones that
interest you. The current open projects list may still need to update
slightly for work that has been done, or that is not desired any more. If
you're interested in a category of projects but no specific ones, you may
also inquire about other ideas from the community within that category.

Gedare

On Sat, Feb 6, 2021 at 6:21 AM Sanskar Khandelwal 
wrote:

>
> Hello everyone,
> My name is Sanskar Khandelwal. I want to contribute on rtems projects.
> I have completed the Hello world task. You guys can check the screenshot
> below.
> But I am a little confused about projects, I went through the project list
> and at least read descriptions of each one but could not figure out which
> projects I should work on.
> Please guide me in selecting a project.
>
> Thank you
> Sanskar
> ___
> 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

Remaining Waf Conversion Tickets for Community and GSoC Students

[Joel Sherrill]

Hi

While potential GSoC students are becoming more familiar with RTEMS and the
community,, I wanted to pass along a few tickets that we would appreciate
having resolved.

https://devel.rtems.org/ticket/4124 - bsp tester needs to be switched to waf
https://devel.rtems.org/ticket/4145 - RSB: Update RTEMS Kernel Recipe to
Use waf for RTEMS

The two tickets above are the worst things left to finish for the
conversion to waf. The full list of known issues remaining with the
conversion is:

https://devel.rtems.org/query?status=!closed&keywords=~wafblocker

Most of these are Python code or documentation.

Thanks.

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

[PATCH v2 2/4] bsps/shared/ofw: Use strlcpy instead of strncpy

[G S Niteesh Babu]

Changed rtems_ofw_get_prop to use strlcpy instead of strncpy
to ensure the buffer is null terminated incase of overflow.
---
 bsps/shared/ofw/ofw.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index fa94bfbf05..886ad0252b 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -198,7 +198,15 @@ ssize_t rtems_ofw_get_prop(
 
   if (prop == NULL && strcmp(propname, "name") == 0) {
 prop = fdt_get_name(fdtp, offset, &len);
-strncpy(buf, prop, bufsize);
+
+/* Node name's are 1-31 chars in length consisting of only
+ * ascii chars and are null terminated */
+strlcpy(buf, prop, bufsize);
+
+/* Return the length of the name including the null byte
+ * rather than the amount copied.
+ * This is the behaviour in libBSD ofw_fdt_getprop
+ */
 return len + 1;
   }
 
-- 
2.17.1

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

[PATCH v2 1/4] bsps/shared/ofw: Fix coverity reported defects

[G S Niteesh Babu]

Fixed use after free and null pointer dereference defects

FIXES:
1) CID 1472601 (NULL_RETURNS)
2) CID 1472600 (USE_AFTER_FREE)
3) CID 1472599 (USE_AFTER_FREE)
4) CID 1472598 (USE_AFTER_FREE)
5) CID 1472596 (USE_AFTER_FREE)

The below two defects have to marked false positive
1) CID 1472597 (ARRAY_VS_SINGLETON)
2) CID 1472595 (ARRAY_VS_SINGLETON)
---
 bsps/shared/ofw/ofw.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index 82924b2600..fa94bfbf05 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -313,7 +313,7 @@ ssize_t rtems_ofw_get_prop_alloc(
 }
 
 if (rtems_ofw_get_prop(node, propname, *buf, len) == -1) {
-  rtems_ofw_free(buf);
+  rtems_ofw_free(*buf);
   *buf = NULL;
   return -1;
 }
@@ -344,7 +344,7 @@ ssize_t rtems_ofw_get_prop_alloc_multi(
 }
 
 if (rtems_ofw_get_prop(node, propname, *buf, len) == -1) {
-  rtems_ofw_free(buf);
+  rtems_ofw_free(*buf);
   *buf = NULL;
   return -1;
 }
@@ -373,7 +373,7 @@ ssize_t rtems_ofw_get_enc_prop_alloc(
 }
 
 if (rtems_ofw_get_enc_prop(node, propname, *buf, len) == -1) {
-  rtems_ofw_free(buf);
+  rtems_ofw_free(*buf);
   *buf = NULL;
   return -1;
 }
@@ -404,7 +404,7 @@ ssize_t rtems_ofw_get_enc_prop_alloc_multi(
 }
 
 if (rtems_ofw_get_enc_prop(node, propname, *buf, len) == -1) {
-  rtems_ofw_free(buf);
+  rtems_ofw_free(*buf);
   *buf = NULL;
   return -1;
 }
@@ -614,7 +614,7 @@ int rtems_ofw_get_reg(
 offset = rtems_fdt_phandle_to_offset(parent);
 ptr = fdt_getprop(fdtp, offset, "ranges", &len);
 
-if (len < 0) {
+if (ptr == NULL) {
   break;
 }
 
-- 
2.17.1

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

[PATCH v2 0/4] bsps/shared/ofw: Bug and Coverity defect fixes

[G S Niteesh Babu]

Update since v1: Using strlcpy instead of memcpy

The following series of patches fix bugs and coverity reported
defect in bsps/shared/ofw.c.

G S Niteesh Babu (4):
  bsps/shared/ofw: Fix coverity reported defects
  bsps/shared/ofw: Use strlcpy instead of strncpy
  bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative
  bsps/shared/ofw: Bug fixes

 bsps/shared/ofw/ofw.c | 35 ++-
 1 file changed, 22 insertions(+), 13 deletions(-)

-- 
2.17.1

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

[PATCH v2 4/4] bsps/shared/ofw: Bug fixes

[G S Niteesh Babu]

Fixed bugs in rtems_ofw_get_prop, rtems_ofw_get_prop_len
and removed hardcoded value.
---
 bsps/shared/ofw/ofw.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index 78576ecf45..1c3a81785d 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -162,7 +162,7 @@ ssize_t rtems_ofw_get_prop_len(
 return len + 1;
   }
 
-  if (prop == NULL && strcmp(propname, "/chosen") == 0) {
+  if (prop == NULL && offset == fdt_path_offset(fdtp, "/chosen")) {
 if (strcmp(propname, "fdtbootcpu") == 0)
   return sizeof(pcell_t);
 if (strcmp(propname, "fdtmemreserv") == 0)
@@ -210,7 +210,7 @@ ssize_t rtems_ofw_get_prop(
 return len + 1;
   }
 
-  if (prop == NULL && strcmp(propname, "/chosen") == 0) {
+  if (prop == NULL && offset == fdt_path_offset(fdtp, "/chosen")) {
 if (strcmp(propname, "fdtbootcpu") == 0) {
   cpuid = cpu_to_fdt32(fdt_boot_cpuid_phys(fdtp));
   len = sizeof(cpuid);
@@ -240,7 +240,7 @@ ssize_t rtems_ofw_get_enc_prop(
 {
   ssize_t rv;
 
-  assert(len % 4 == 0);
+  assert(len % sizeof(pcell_t) == 0);
   rv = rtems_ofw_get_prop(node, prop, buf, len);
 
   if (rv < 0) {
-- 
2.17.1

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

[PATCH v2 3/4] bsps/shared/ofw: Make rtems_ofw_get_effective_phandle iterative

[G S Niteesh Babu]

Refactored recursive rtems_ofw_get_effective_phandle into a
iterative function.
---
 bsps/shared/ofw/ofw.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
index 886ad0252b..78576ecf45 100644
--- a/bsps/shared/ofw/ofw.c
+++ b/bsps/shared/ofw/ofw.c
@@ -509,11 +509,12 @@ static phandle_t rtems_ofw_get_effective_phandle(
 {
   phandle_t child;
   phandle_t ref;
+  int node_offset;
 
-  for (child = rtems_ofw_child(node); child != 0; child = 
rtems_ofw_peer(child)) {
-ref = rtems_ofw_get_effective_phandle(child, xref);
-if (ref != -1)
-  return ref;
+  node_offset = fdt_path_offset(fdtp, "/");
+
+  while ((node_offset = fdt_next_node(fdtp, node_offset, NULL)) > 0) {
+child = rtems_fdt_offset_to_phandle(node_offset);
 
 if (rtems_ofw_get_enc_prop(child, "phandle", &ref, sizeof(ref)) == -1 &&
 rtems_ofw_get_enc_prop(child, "ibm,phandle", &ref, sizeof(ref)) == -1 
&&
-- 
2.17.1

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

[PATCH] powerpc/shared: ISA bus bridge fails to enable the openpic irq

[chrisj]

From: Chris Johns 

- The call to enable the openpic irq for the ISA bridge falls
  because the IRQ used is offset by the ISA bus signals and
  the openpic call expects an IRA relative to it's signals.

- Add the MVME 2600/2700 to the list is an ISA bridge.

Closes #4231
---
 bsps/powerpc/shared/irq/irq_init.c  | 2 +-
 bsps/powerpc/shared/irq/openpic_i8259_irq.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bsps/powerpc/shared/irq/irq_init.c 
b/bsps/powerpc/shared/irq/irq_init.c
index 1a44992a5b..1042c9d1a8 100644
--- a/bsps/powerpc/shared/irq/irq_init.c
+++ b/bsps/powerpc/shared/irq/irq_init.c
@@ -310,7 +310,7 @@ void BSP_rtems_irq_mng_init(unsigned cpuId)
 #endif
 known_cpi_isa_bridge = 1;
   }
-  if ( currentBoard == MVME_2300 ) {
+  if ( currentBoard == MVME_2300 || currentBoard == MVME_2600_2700_W_MVME761 ) 
{
 /* nothing to do for W83C553 bridge */
 known_cpi_isa_bridge = 1;
   }
diff --git a/bsps/powerpc/shared/irq/openpic_i8259_irq.c 
b/bsps/powerpc/shared/irq/openpic_i8259_irq.c
index 4a9c393f7f..513b9ac3e0 100644
--- a/bsps/powerpc/shared/irq/openpic_i8259_irq.c
+++ b/bsps/powerpc/shared/irq/openpic_i8259_irq.c
@@ -214,7 +214,7 @@ int BSP_setup_the_pic(rtems_irq_global_settings* config)
/*
  * Must enable PCI/ISA bridge IRQ
  */
-   openpic_enable_irq (BSP_PCI_ISA_BRIDGE_IRQ);
+openpic_enable_irq (BSP_PCI_ISA_BRIDGE_IRQ - BSP_PCI_IRQ_LOWEST_OFFSET);
 #endif
 #endif
 
-- 
2.27.0

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

Re: [PATCH] powerpc/shared: ISA bus bridge fails to enable the openpic irq

[Joel Sherrill]

On Sat, Feb 6, 2021, 2:09 PM  wrote:

> From: Chris Johns 
>
> - The call to enable the openpic irq for the ISA bridge falls
>   because the IRQ used is offset by the ISA bus signals and
>   the openpic call expects an IRA relative to it's signals.
>

Falls to fails
What's IRA
And its not it's



> - Add the MVME 2600/2700 to the list is an ISA bridge.
>
> Closes #4231
> ---
>  bsps/powerpc/shared/irq/irq_init.c  | 2 +-
>  bsps/powerpc/shared/irq/openpic_i8259_irq.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/bsps/powerpc/shared/irq/irq_init.c
> b/bsps/powerpc/shared/irq/irq_init.c
> index 1a44992a5b..1042c9d1a8 100644
> --- a/bsps/powerpc/shared/irq/irq_init.c
> +++ b/bsps/powerpc/shared/irq/irq_init.c
> @@ -310,7 +310,7 @@ void BSP_rtems_irq_mng_init(unsigned cpuId)
>  #endif
>  known_cpi_isa_bridge = 1;
>}
> -  if ( currentBoard == MVME_2300 ) {
> +  if ( currentBoard == MVME_2300 || currentBoard ==
> MVME_2600_2700_W_MVME761 ) {
>  /* nothing to do for W83C553 bridge */
>  known_cpi_isa_bridge = 1;
>}
> diff --git a/bsps/powerpc/shared/irq/openpic_i8259_irq.c
> b/bsps/powerpc/shared/irq/openpic_i8259_irq.c
> index 4a9c393f7f..513b9ac3e0 100644
> --- a/bsps/powerpc/shared/irq/openpic_i8259_irq.c
> +++ b/bsps/powerpc/shared/irq/openpic_i8259_irq.c
> @@ -214,7 +214,7 @@ int BSP_setup_the_pic(rtems_irq_global_settings*
> config)
> /*
>   * Must enable PCI/ISA bridge IRQ
>   */
> -   openpic_enable_irq (BSP_PCI_ISA_BRIDGE_IRQ);
> +openpic_enable_irq (BSP_PCI_ISA_BRIDGE_IRQ -
> BSP_PCI_IRQ_LOWEST_OFFSET);
>  #endif
>  #endif
>

I think the patch itself is ok to commit. It would be good to know that it
doesn't negatively impact other BSPs with openpic and i8259. Which other
BSPs use this code?

And does this mean that no bsp with openpic and i8259 had working ISA
interrupts?

--joel

>
> --
> 2.27.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

Re: [PATCH] powerpc/shared: ISA bus bridge fails to enable the openpic irq

[Chris Johns]

On 7/2/21 9:42 am, Joel Sherrill wrote:
> On Sat, Feb 6, 2021, 2:09 PM mailto:chr...@rtems.org>> 
> wrote:
> 
> From: Chris Johns mailto:chr...@rtems.org>>
> 
> - The call to enable the openpic irq for the ISA bridge falls
>   because the IRQ used is offset by the ISA bus signals and
>   the openpic call expects an IRA relative to it's signals.
> 
> Falls to fails

Thanks.

> What's IRA

IRQ

> And its not it's 

Thanks.

> - Add the MVME 2600/2700 to the list is an ISA bridge.
> 
> Closes #4231
> ---
>  bsps/powerpc/shared/irq/irq_init.c          | 2 +-
>  bsps/powerpc/shared/irq/openpic_i8259_irq.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/bsps/powerpc/shared/irq/irq_init.c
> b/bsps/powerpc/shared/irq/irq_init.c
> index 1a44992a5b..1042c9d1a8 100644
> --- a/bsps/powerpc/shared/irq/irq_init.c
> +++ b/bsps/powerpc/shared/irq/irq_init.c
> @@ -310,7 +310,7 @@ void BSP_rtems_irq_mng_init(unsigned cpuId)
>  #endif
>      known_cpi_isa_bridge = 1;
>    }
> -  if ( currentBoard == MVME_2300 ) {
> +  if ( currentBoard == MVME_2300 || currentBoard ==
> MVME_2600_2700_W_MVME761 ) {
>      /* nothing to do for W83C553 bridge */
>      known_cpi_isa_bridge = 1;
>    }
> diff --git a/bsps/powerpc/shared/irq/openpic_i8259_irq.c
> b/bsps/powerpc/shared/irq/openpic_i8259_irq.c
> index 4a9c393f7f..513b9ac3e0 100644
> --- a/bsps/powerpc/shared/irq/openpic_i8259_irq.c
> +++ b/bsps/powerpc/shared/irq/openpic_i8259_irq.c
> @@ -214,7 +214,7 @@ int BSP_setup_the_pic(rtems_irq_global_settings* 
> config)
>         /*
>       * Must enable PCI/ISA bridge IRQ
>       */
> -       openpic_enable_irq (BSP_PCI_ISA_BRIDGE_IRQ);
> +    openpic_enable_irq (BSP_PCI_ISA_BRIDGE_IRQ - 
> BSP_PCI_IRQ_LOWEST_OFFSET);
>  #endif
>  #endif
> 
> I think the patch itself is ok to commit. It would be good to know that it
> doesn't negatively impact other BSPs with openpic and i8259. Which other BSPs
> use this code?
> 
> And does this mean that no bsp with openpic and i8259 had working ISA 
> interrupts?
> 

Yes I believe so. In 4.10 the code was:

   openpic_enable_irq (0);

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

Re: [PATCH] powerpc/shared: ISA bus bridge fails to enable the openpic irq

[Chris Johns]

On 7/2/21 9:42 am, Joel Sherrill wrote:
> -  if ( currentBoard == MVME_2300 ) {
> +  if ( currentBoard == MVME_2300 || currentBoard ==
> MVME_2600_2700_W_MVME761 ) {
>      /* nothing to do for W83C553 bridge */
>      known_cpi_isa_bridge = 1;
>    }
> 
> I think the patch itself is ok to commit. It would be good to know that it
> doesn't negatively impact other BSPs with openpic and i8259. Which other BSPs
> use this code?

I am sorry I missed this question. The fragment about shows which BSPs have a
known CPI/ISA bridge so I assume any MVME2300 board.

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