Re: Valid interrupt vectors and the interrupt server

2017-06-17 Thread Chris Johns 
On 18/6/17 2:17 am, Christian Mauderer wrote:
> Hello,
> 
> I had a problem recently, that the interrupt server (for example used in 
> libbsd) caused some odd behaviour on an ARM Cortex BSP. That was solved by 
> the following patch:
> 
> https://git.rtems.org/rtems/commit/?id=ce3ac00c
> 
> Just today Sichen Zhao had a similar problem on the BBB:
> 
> https://lists.rtems.org/pipermail/devel/2017-June/018158.html
> 
> I took a look and it seems that there are a lot of BSPs which don't check for 
> the valid interrupt vector range in their bsp_interrupt_vector_disable/enable 
> functions. Every one of them will most likely have a problems if someone 
> tries to use libbsd or the interrupt server.

I seem to be missing something. Is the interrupt server and libbsd attempting to
use interrupts that are no valid for these board and this is causing a problem?

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

IRC #rtems logs unavailable

2017-06-17 Thread Denis Obrezkov 
Hello, I can't find RTEMS IRC logs: http://www.rtems.org/irclogs/
page is unavailable.

-- 
Regards, Denis Obrezkov
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Are you happy with how the project is going?

2017-06-17 Thread Denis Obrezkov 
2017-06-17 22:11 GMT+03:00 Denis Obrezkov :

>
>>> Can you run RTEMS hello world? Or does printf make that too large? If
>> that is
>> too large, you need to force the tests to switch to printk(). There is
>> some magic
>> in testsuites/configure.ac for that.
>>
>> The low ticker examples (especially the last one) will show configure
>> options
>> to cut memory use.
>>
>> But these are hacks on individual tests. If there is a simulator which
>> has interrupts,
>> I would be testing on it since you will be battling the architecture not
>> a RAM limit.
>> Your project is the port not to put RTEMS into a tiny memory space. :)
>>
>> --joel
>>
>>
>>> --
>>> Regards, Denis Obrezkov
>>>
>>
>> I was able to run the low ticker example further than in my earlier
> attempts.
>
> But now I have a problem with it:
> #0  memset (m=0xb98a0641, c=0, n=102) at ../../../../../gcc-7.1.0/
> newlib/libc/string/memset.c:62
> #1  0x20403168 in _Heap_Initialize (heap=0xb98a0641, 
> heap_area_begin_ptr=0x80002456,
> heap_area_size=7082, page_size=8)
> at /home/reprofy/Projects/riscv/rtems/development/rtems/
> kernel/rtems-riscv/c/src/../../cpukit/score/src/heap.c:230
> #2  0x20400954 in RTEMS_Malloc_Initialize (areas=0x80003f78, area_count=1,
> extend=0x0)
> at /home/reprofy/Projects/riscv/rtems/development/rtems/
> kernel/rtems-riscv/c/src/../../cpukit/libcsupport/src/
> malloc_initialize.c:40
> #3  0x20400378 in bsp_work_area_initialize_default
> (area_begin=0x8e10, area_size=12784) at ../../../../../.././hifive1/
> lib/include/bsp/bootcard.h:158
> #4  0x204003c0 in bsp_work_area_initialize () at
> /home/reprofy/Projects/riscv/rtems/development/rtems/
> kernel/rtems-riscv/c/src/lib/libbsp/riscv32/hifive1/../../
> shared/bspgetworkarea.c:61
> #5  0x204021bc in rtems_initialize_executive () at
> /home/reprofy/Projects/riscv/rtems/development/rtems/
> kernel/rtems-riscv/c/src/../../cpukit/sapi/src/exinit.c:95
> #6  0x2040031c in boot_card (cmdline=0x0) at /home/reprofy/Projects/riscv/
> rtems/development/rtems/kernel/rtems-riscv/c/src/lib/
> libbsp/riscv32/hifive1/../../shared/bootcard.c:76
> #7  0x20400064 in _end_clear_bss () at /home/reprofy/Projects/riscv/
> rtems/development/rtems/kernel/rtems-riscv/c/src/lib/
> libbsp/riscv32/hifive1/start/start.S:116
>
> I want to figure out, why it wants to use memset on these addresses,
> because 0x80004000 is the maximum available address.
>
>
> --
> Regards, Denis Obrezkov
>

I was able to proceed further after adding
#define CONFIGURE_UNIFIED_WORK_AREAS
to init.c of low_ticker example.
Now I get an error:
#0  0x2040d940 in _Chain_Initialize_node (the_node=0x80003ec0) at
../../cpukit/../../../hifive1/lib/include/rtems/score/chainimpl.h:127
#1  0x2040da82 in _Chain_Iterator_initialize (the_chain=0x8320
<_User_extensions_List>, the_registry=0x832c
<_User_extensions_List+12>, the_iterator=0x80003ec0,
direction=CHAIN_ITERATOR_FORWARD) at
../../cpukit/../../../hifive1/lib/include/rtems/score/chainimpl.h:1049
#2  0x2040de90 in _User_extensions_Iterate (arg=0x80003f18,
visitor=0x2040dd48 <_User_extensions_Fatal_visitor>,
direction=CHAIN_ITERATOR_FORWARD)
at
/home/reprofy/Projects/riscv/rtems/development/rtems/kernel/rtems-riscv/c/src/../../cpukit/score/src/userextiterate.c:174
#3  0x204036c4 in _User_extensions_Fatal (source=INTERNAL_ERROR_CORE,
error=4) at
../../cpukit/../../../hifive1/lib/include/rtems/score/userextimpl.h:307
#4  0x204036e8 in _Terminate (the_source=INTERNAL_ERROR_CORE, the_error=4)
at
/home/reprofy/Projects/riscv/rtems/development/rtems/kernel/rtems-riscv/c/src/../../cpukit/score/src/interr.c:35
#5  0x20403730 in _Internal_error
(core_error=INTERNAL_ERROR_INTERRUPT_STACK_TOO_SMALL)
at
/home/reprofy/Projects/riscv/rtems/development/rtems/kernel/rtems-riscv/c/src/../../cpukit/score/src/interr.c:44
#6  0x20403824 in _ISR_Handler_initialization () at
/home/reprofy/Projects/riscv/rtems/development/rtems/kernel/rtems-riscv/c/src/../../cpukit/score/src/isr.c:51
#7  0x20402170 in rtems_initialize_data_structures () at
/home/reprofy/Projects/riscv/rtems/development/rtems/kernel/rtems-riscv/c/src/../../cpukit/sapi/src/exinit.c:82
#8  0x204021bc in rtems_initialize_executive () at
/home/reprofy/Projects/riscv/rtems/development/rtems/kernel/rtems-riscv/c/src/../../cpukit/sapi/src/exinit.c:95
#9  0x2040031c in boot_card (cmdline=0x0) at
/home/reprofy/Projects/riscv/rtems/development/rtems/kernel/rtems-riscv/c/src/lib/libbsp/riscv32/hifive1/../../shared/bootcard.c:76
#10 0xcd98 in ?? ()

And I found out that rtems_minimum_stack_size variable is 0xab817bb3.
And I don't know why - in the low ticker example it is set to 512.

-- 
Regards, Denis Obrezkov
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Valid interrupt vectors and the interrupt server

2017-06-17 Thread Christian Mauderer 


Am 17.06.2017 um 20:16 schrieb Joel Sherrill:
> 
> 
> On Jun 17, 2017 11:17 AM, "Christian Mauderer"
>  > wrote:
> 
> Hello,
> 
> I had a problem recently, that the interrupt server (for example
> used in libbsd) caused some odd behaviour on an ARM Cortex BSP. That
> was solved by the following patch:
> 
> https://git.rtems.org/rtems/commit/?id=ce3ac00c
> 
> 
> Just today Sichen Zhao had a similar problem on the BBB:
> 
> https://lists.rtems.org/pipermail/devel/2017-June/018158.html
> 
> 
> I took a look and it seems that there are a lot of BSPs which don't
> check for the valid interrupt vector range in their
> bsp_interrupt_vector_disable/enable functions. Every one of them
> will most likely have a problems if someone tries to use libbsd or
> the interrupt server.
> 
> It also seems that there is no test for the interrupt server. As far
> as I know, not all targets are able to support the interrupt server
> depending on the interrupt controller (I'm not exactly sure which
> ones have support and which doesn't). So if a test for the server
> would be added, that test will most likely fail on a lot of targets.
> 
> Has someone an idea how a test for the interrupt server could look
> like? We would need an interrupt that can be used on every target.
> 
> Should we mass-change all BSPs to add the check for a valid
> interrupt? A mass-change could be problematic because it is nearly
> impossible to test on all targets and it's in a quite critical location.
> 
> 
> Is there anyway a timer method could be used to fake out the interrupt
> occurrence? 
> 
> There is no single interrupt source or interface to get to one.

Hm. OK. I just took another look and noted that there is also not really a test 
for the normal non-server interrupt install. The only occurrence I found is in 
a smp test:

https://git.rtems.org/rtems/tree/testsuites/smptests/smpcapture02/init.c?id=ae359a9df#n333

There is about that implemented what you suggested. The test searches for a 
clock interrupt and replaces it by another (wrapper) handler. Not really an 
easy solution and I'm not sure whether it would be a good idea to replace the 
clock tick interrupt with a interrupt server.

By the way: Any such test would most likely only catch a part of the BSPs. For 
example on the atsam BSP, the odd behaviour normally occurred only a few 
minutes after the start. Sichens BBB BSP on the other hand would have reached a 
_Terminate in that case.

But maybe it's the wrong approach. Maybe we should test the 
bsp_interrupt_vector_enable/disable instead. Any ideas for that test? I think 
there is no bsp_interrupt_vector_is_enabled() check function? And also if there 
were one, it would be most likely affected too.

> 
> 
> Kind regards
> 
> Christian Mauderer

-- 

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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: Generation of ccoshl.o file

2017-06-17 Thread Joel Sherrill 
On Jun 17, 2017 2:28 PM, "aditya upadhyay"  wrote:

Hello All,

I have ported ccoshl.c from freebsd and trying to check whether the
lib-a-w_ccoshl.o file has generated or not.
When i executed this command :
 aditya@aditya-Lenovo-ideapad-110-15ACL:~/development/b-
sparc-rtems4.12-newlib$
sparc-rtems4.12-nm
/home/aditya/development/b-sparc-rtems4.12-newlib/sparc-
rtems4.12/newlib/libm.a

I am not seeing the file like lib_a-w_ccoshl.o. However i have used
j-newlib script to build newlib for sparc and arm bsp.

These are the commands i have to build the newlib :
aditya@aditya-Lenovo-ideapad-110-15ACL:~$ cd development/newlib/
aditya@aditya-Lenovo-ideapad-110-15ACL:~/development/newlib$ ../j-newlib

Then these two files has been generated : b-sparc-rtems4.12-newlib and
b-arm-rtems4.12-newlib.

aditya@aditya-Lenovo-ideapad-110-15ACL:~/development/b-
sparc-rtems4.12-newlib$
make
aditya@aditya-Lenovo-ideapad-110-15ACL:~/development/b-
sparc-rtems4.12-newlib$
make install.
I am attaching the script by which i am trying to build newlib.
I do not know where i am making mistake.


Is this a new file or just checking the previous commit was ok? I checked
that the last method was in the library after the commit.

--joel


Thanks & Regards,
Aditya Upadhyay

___
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

Generation of ccoshl.o file

2017-06-17 Thread aditya upadhyay 
Hello All,

I have ported ccoshl.c from freebsd and trying to check whether the
lib-a-w_ccoshl.o file has generated or not.
When i executed this command :
 aditya@aditya-Lenovo-ideapad-110-15ACL:~/development/b-sparc-rtems4.12-newlib$
sparc-rtems4.12-nm
/home/aditya/development/b-sparc-rtems4.12-newlib/sparc-rtems4.12/newlib/libm.a

I am not seeing the file like lib_a-w_ccoshl.o. However i have used
j-newlib script to build newlib for sparc and arm bsp.

These are the commands i have to build the newlib :
aditya@aditya-Lenovo-ideapad-110-15ACL:~$ cd development/newlib/
aditya@aditya-Lenovo-ideapad-110-15ACL:~/development/newlib$ ../j-newlib

Then these two files has been generated : b-sparc-rtems4.12-newlib and
b-arm-rtems4.12-newlib.

aditya@aditya-Lenovo-ideapad-110-15ACL:~/development/b-sparc-rtems4.12-newlib$
make
aditya@aditya-Lenovo-ideapad-110-15ACL:~/development/b-sparc-rtems4.12-newlib$
make install.
I am attaching the script by which i am trying to build newlib.
I do not know where i am making mistake.

Thanks & Regards,
Aditya Upadhyay


j-newlib
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Valid interrupt vectors and the interrupt server

2017-06-17 Thread Joel Sherrill 
On Jun 17, 2017 11:17 AM, "Christian Mauderer" <
christian.maude...@embedded-brains.de> wrote:

Hello,

I had a problem recently, that the interrupt server (for example used in
libbsd) caused some odd behaviour on an ARM Cortex BSP. That was solved by
the following patch:

https://git.rtems.org/rtems/commit/?id=ce3ac00c

Just today Sichen Zhao had a similar problem on the BBB:

https://lists.rtems.org/pipermail/devel/2017-June/018158.html

I took a look and it seems that there are a lot of BSPs which don't check
for the valid interrupt vector range in their
bsp_interrupt_vector_disable/enable
functions. Every one of them will most likely have a problems if someone
tries to use libbsd or the interrupt server.

It also seems that there is no test for the interrupt server. As far as I
know, not all targets are able to support the interrupt server depending on
the interrupt controller (I'm not exactly sure which ones have support and
which doesn't). So if a test for the server would be added, that test will
most likely fail on a lot of targets.

Has someone an idea how a test for the interrupt server could look like? We
would need an interrupt that can be used on every target.

Should we mass-change all BSPs to add the check for a valid interrupt? A
mass-change could be problematic because it is nearly impossible to test on
all targets and it's in a quite critical location.


Is there anyway a timer method could be used to fake out the interrupt
occurrence?

There is no single interrupt source or interface to get to one.


Kind regards

Christian Mauderer
--

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Adding new arch/bsp to rtems tools

2017-06-17 Thread Joel Sherrill 
On Jun 17, 2017 12:55 PM, "Denis Obrezkov"  wrote:

I don't think that the tester subdirectory has anything to do with this
>
> Confirm that you can successfully 'waf configure' for the sparc/erc32.
> If not, the problem is somewhere in your command line or install
> point. Note that rtems-tools should point to the installed toolchain,
> and --rtems should point to the installed build of your BSP/rtems.
> Check that your 'make install' succeeded.
>
> > --
> > Regards, Denis Obrezkov
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
Thank you, I really forgot to "make install" after rtems building.


I wonder if this is such a common user issue that the waf error message
should offer guidance.

Similarly for the tools.

--joel



-- 
Regards, Denis Obrezkov

___
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: Adding new arch/bsp to rtems tools

2017-06-17 Thread Denis Obrezkov 
>
> I don't think that the tester subdirectory has anything to do with this
>
> Confirm that you can successfully 'waf configure' for the sparc/erc32.
> If not, the problem is somewhere in your command line or install
> point. Note that rtems-tools should point to the installed toolchain,
> and --rtems should point to the installed build of your BSP/rtems.
> Check that your 'make install' succeeded.
>
> > --
> > Regards, Denis Obrezkov
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
Thank you, I really forgot to "make install" after rtems building.

-- 
Regards, Denis Obrezkov
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Valid interrupt vectors and the interrupt server

2017-06-17 Thread Christian Mauderer 
Hello,

I had a problem recently, that the interrupt server (for example used in 
libbsd) caused some odd behaviour on an ARM Cortex BSP. That was solved by the 
following patch:

https://git.rtems.org/rtems/commit/?id=ce3ac00c

Just today Sichen Zhao had a similar problem on the BBB:

https://lists.rtems.org/pipermail/devel/2017-June/018158.html

I took a look and it seems that there are a lot of BSPs which don't check for 
the valid interrupt vector range in their bsp_interrupt_vector_disable/enable 
functions. Every one of them will most likely have a problems if someone tries 
to use libbsd or the interrupt server.

It also seems that there is no test for the interrupt server. As far as I know, 
not all targets are able to support the interrupt server depending on the 
interrupt controller (I'm not exactly sure which ones have support and which 
doesn't). So if a test for the server would be added, that test will most 
likely fail on a lot of targets.

Has someone an idea how a test for the interrupt server could look like? We 
would need an interrupt that can be used on every target.

Should we mass-change all BSPs to add the check for a valid interrupt? A 
mass-change could be problematic because it is nearly impossible to test on all 
targets and it's in a quite critical location.

Kind regards

Christian Mauderer
-- 

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
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] Fix beagle bsp irq issue

2017-06-17 Thread Sichen Zhao 
Yes, i will!
-- Original --
From:  "punit vara";;
Date:  Sat, Jun 17, 2017 11:44 PM
To:  "Sichen Zhao"<1473996...@qq.com>; 
Cc:  "rtems-de...@rtems.org"; "Christian 
Mauderer"; 
Subject:  Re: [PATCH] Fix beagle bsp irq issue



Good job Sichen. Keep it up

On Sat, Jun 17, 2017 at 8:01 PM, Sichen Zhao <1473996...@qq.com> wrote:
> Enable/disable vector routines now check for a valid vector.
> Without these guards, the enable/disable vector routines
> will not work with the interrupt server.
> ---
>  c/src/lib/libbsp/arm/beagle/irq.c | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/beagle/irq.c 
> b/c/src/lib/libbsp/arm/beagle/irq.c
> index d080a5e..35750ba 100644
> --- a/c/src/lib/libbsp/arm/beagle/irq.c
> +++ b/c/src/lib/libbsp/arm/beagle/irq.c
> @@ -98,11 +98,14 @@ static uint32_t omap_get_mir_reg(rtems_vector_number 
> vector, uint32_t *const mas
>  rtems_status_code bsp_interrupt_vector_enable(rtems_vector_number vector)
>  {
>uint32_t mask, cur;
> -  uint32_t mir_reg = omap_get_mir_reg(vector, );
>
> -  cur = mmio_read(omap_intr.base + mir_reg);
> -  mmio_write(omap_intr.base + mir_reg, cur & ~mask);
> -  flush_data_cache();
> +  if (bsp_interrupt_is_valid_vector(vector)) {
> +uint32_t mir_reg = omap_get_mir_reg(vector, );
> +
> +cur = mmio_read(omap_intr.base + mir_reg);
> +mmio_write(omap_intr.base + mir_reg, cur & ~mask);
> +flush_data_cache();
> +  }
>
>return RTEMS_SUCCESSFUL;
>  }
> @@ -110,11 +113,14 @@ rtems_status_code 
> bsp_interrupt_vector_enable(rtems_vector_number vector)
>  rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number vector)
>  {
>uint32_t mask, cur;
> -  uint32_t mir_reg = omap_get_mir_reg(vector, );
>
> -  cur = mmio_read(omap_intr.base + mir_reg);
> -  mmio_write(omap_intr.base + mir_reg, cur | mask);
> -  flush_data_cache();
> +  if (bsp_interrupt_is_valid_vector(vector)) {
> +uint32_t mir_reg = omap_get_mir_reg(vector, );
> +
> +cur = mmio_read(omap_intr.base + mir_reg);
> +mmio_write(omap_intr.base + mir_reg, cur | mask);
> +flush_data_cache();
> +  }
>
>return RTEMS_SUCCESSFUL;
>  }
> --
> 2.7.4
>___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Fix beagle bsp irq issue

2017-06-17 Thread punit vara 
Good job Sichen. Keep it up

On Sat, Jun 17, 2017 at 8:01 PM, Sichen Zhao <1473996...@qq.com> wrote:
> Enable/disable vector routines now check for a valid vector.
> Without these guards, the enable/disable vector routines
> will not work with the interrupt server.
> ---
>  c/src/lib/libbsp/arm/beagle/irq.c | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/beagle/irq.c 
> b/c/src/lib/libbsp/arm/beagle/irq.c
> index d080a5e..35750ba 100644
> --- a/c/src/lib/libbsp/arm/beagle/irq.c
> +++ b/c/src/lib/libbsp/arm/beagle/irq.c
> @@ -98,11 +98,14 @@ static uint32_t omap_get_mir_reg(rtems_vector_number 
> vector, uint32_t *const mas
>  rtems_status_code bsp_interrupt_vector_enable(rtems_vector_number vector)
>  {
>uint32_t mask, cur;
> -  uint32_t mir_reg = omap_get_mir_reg(vector, );
>
> -  cur = mmio_read(omap_intr.base + mir_reg);
> -  mmio_write(omap_intr.base + mir_reg, cur & ~mask);
> -  flush_data_cache();
> +  if (bsp_interrupt_is_valid_vector(vector)) {
> +uint32_t mir_reg = omap_get_mir_reg(vector, );
> +
> +cur = mmio_read(omap_intr.base + mir_reg);
> +mmio_write(omap_intr.base + mir_reg, cur & ~mask);
> +flush_data_cache();
> +  }
>
>return RTEMS_SUCCESSFUL;
>  }
> @@ -110,11 +113,14 @@ rtems_status_code 
> bsp_interrupt_vector_enable(rtems_vector_number vector)
>  rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number vector)
>  {
>uint32_t mask, cur;
> -  uint32_t mir_reg = omap_get_mir_reg(vector, );
>
> -  cur = mmio_read(omap_intr.base + mir_reg);
> -  mmio_write(omap_intr.base + mir_reg, cur | mask);
> -  flush_data_cache();
> +  if (bsp_interrupt_is_valid_vector(vector)) {
> +uint32_t mir_reg = omap_get_mir_reg(vector, );
> +
> +cur = mmio_read(omap_intr.base + mir_reg);
> +mmio_write(omap_intr.base + mir_reg, cur | mask);
> +flush_data_cache();
> +  }
>
>return RTEMS_SUCCESSFUL;
>  }
> --
> 2.7.4
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Fix beagle bsp irq issue

2017-06-17 Thread Sichen Zhao 
Enable/disable vector routines now check for a valid vector.
Without these guards, the enable/disable vector routines
will not work with the interrupt server.
---
 c/src/lib/libbsp/arm/beagle/irq.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/c/src/lib/libbsp/arm/beagle/irq.c 
b/c/src/lib/libbsp/arm/beagle/irq.c
index d080a5e..35750ba 100644
--- a/c/src/lib/libbsp/arm/beagle/irq.c
+++ b/c/src/lib/libbsp/arm/beagle/irq.c
@@ -98,11 +98,14 @@ static uint32_t omap_get_mir_reg(rtems_vector_number 
vector, uint32_t *const mas
 rtems_status_code bsp_interrupt_vector_enable(rtems_vector_number vector)
 {
   uint32_t mask, cur;
-  uint32_t mir_reg = omap_get_mir_reg(vector, );
 
-  cur = mmio_read(omap_intr.base + mir_reg);
-  mmio_write(omap_intr.base + mir_reg, cur & ~mask);
-  flush_data_cache();
+  if (bsp_interrupt_is_valid_vector(vector)) {
+uint32_t mir_reg = omap_get_mir_reg(vector, );
+
+cur = mmio_read(omap_intr.base + mir_reg);
+mmio_write(omap_intr.base + mir_reg, cur & ~mask);
+flush_data_cache();
+  }
 
   return RTEMS_SUCCESSFUL;
 }
@@ -110,11 +113,14 @@ rtems_status_code 
bsp_interrupt_vector_enable(rtems_vector_number vector)
 rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number vector)
 {
   uint32_t mask, cur;
-  uint32_t mir_reg = omap_get_mir_reg(vector, );
 
-  cur = mmio_read(omap_intr.base + mir_reg);
-  mmio_write(omap_intr.base + mir_reg, cur | mask);
-  flush_data_cache();
+  if (bsp_interrupt_is_valid_vector(vector)) {
+uint32_t mir_reg = omap_get_mir_reg(vector, );
+
+cur = mmio_read(omap_intr.base + mir_reg);
+mmio_write(omap_intr.base + mir_reg, cur | mask);
+flush_data_cache();
+  }
 
   return RTEMS_SUCCESSFUL;
 }
-- 
2.7.4



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

[PATCH] Fix beagle bsp irq issue

2017-06-17 Thread hahchenchen 
Enable/disable vector routines now check for a valid vector.
Without these guards, the enable/disable vector routines
will not work with the interrupt server.
---
 c/src/lib/libbsp/arm/beagle/irq.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/c/src/lib/libbsp/arm/beagle/irq.c 
b/c/src/lib/libbsp/arm/beagle/irq.c
index d080a5e..35750ba 100644
--- a/c/src/lib/libbsp/arm/beagle/irq.c
+++ b/c/src/lib/libbsp/arm/beagle/irq.c
@@ -98,11 +98,14 @@ static uint32_t omap_get_mir_reg(rtems_vector_number 
vector, uint32_t *const mas
 rtems_status_code bsp_interrupt_vector_enable(rtems_vector_number vector)
 {
   uint32_t mask, cur;
-  uint32_t mir_reg = omap_get_mir_reg(vector, );
 
-  cur = mmio_read(omap_intr.base + mir_reg);
-  mmio_write(omap_intr.base + mir_reg, cur & ~mask);
-  flush_data_cache();
+  if (bsp_interrupt_is_valid_vector(vector)) {
+uint32_t mir_reg = omap_get_mir_reg(vector, );
+
+cur = mmio_read(omap_intr.base + mir_reg);
+mmio_write(omap_intr.base + mir_reg, cur & ~mask);
+flush_data_cache();
+  }
 
   return RTEMS_SUCCESSFUL;
 }
@@ -110,11 +113,14 @@ rtems_status_code 
bsp_interrupt_vector_enable(rtems_vector_number vector)
 rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number vector)
 {
   uint32_t mask, cur;
-  uint32_t mir_reg = omap_get_mir_reg(vector, );
 
-  cur = mmio_read(omap_intr.base + mir_reg);
-  mmio_write(omap_intr.base + mir_reg, cur | mask);
-  flush_data_cache();
+  if (bsp_interrupt_is_valid_vector(vector)) {
+uint32_t mir_reg = omap_get_mir_reg(vector, );
+
+cur = mmio_read(omap_intr.base + mir_reg);
+mmio_write(omap_intr.base + mir_reg, cur | mask);
+flush_data_cache();
+  }
 
   return RTEMS_SUCCESSFUL;
 }
-- 
2.7.4



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

Re: RSB Couverture-Qemu build queries

2017-06-17 Thread Cillian O'Donnell 
On 16 June 2017 at 22:00, Jiri Gaisler  wrote:
> Hi Cillian,
>
> the gaisler.org server is currently down due to a power problem last
> week. I am in the Caribbean at the moment so I can't fix it until
> Tuesday next week. I suggest you skip the LEON3 patches until I fix the
> server next week. Let me know if you get problems merging the patches,
> and I will try to sort it out.
>
> Jiri.
>

Ok, thanks for letting me know Jiri. I'll leave the patches till
Tuesday and see If I can put them back together and get them merged
then. Thanks Joel, I've been talking with Fabien Chouteau from the
Couverture project, I'll reach out to him with the patches and cc you
and Chris and thanks Gedare for the info.

>
> On 06/16/2017 03:13 PM, Cillian O'Donnell wrote:
>> Hi,
>>
>> I am getting the RSB to build Couverture-Qemu and I just want to check
>> a few things I have done so far.
>>
>> 1. There are about 5 patches applied to the current qemu build. Only
>> one of which applies cleanly to the Couverture build. Do you want me
>> to try and fix these up, comment them out and leave a note for
>> whoever wants to fix them or remove them completely? The patches that
>> don't work are:
>>
>> %patch add qemu
>> pw://patchwork.ozlabs.org/patch/406903/raw/Provide-the-missing-LIBUSB_LOG_LEVEL_-for-older-libusb-or-FreeBSD.-Providing-just-the-needed-value-as-a-defined..patch
>>
>> %patch add qemu
>> https://gaisler.org/qemu/0001-LEON3-Add-emulation-of-AMBA-plug-
>> play.patch
>>
>> %patch add qemu
>> https://gaisler.org/qemu/0002-LEON3-Build-AMBA-plug-and-play-records-from-high-lev.patch
>>
>> %patch add qemu
>> https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
>>
>>
>> 2. For this source setting section, is the first part just dealing
>> with the case were this a packaged release so a tar of the download is
>> already included with it?
>>
>> %if %{rsb_released} && %{!defined without_release_url}
>> %source set qemu
>> %{rtems_release_url}/%{rtems_version}/sources/qemu-git-42d58e7.tar.xz
>> %else
>> %source set qemu
>> https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
>> %endif
>>
>> 3. What does the -q option do in the %prep section of the build, this
>> option shows up in examples in the docs but there is no description of
>> what it does?
>>
>> %source setup qemu -q -n qemu-%{qemu_version}
>>
>> 4. The current qemu build is configured with the default setting to
>> build for all architectures but most of the arch's aren't used by
>> RTEMS and/or don't have machine support for same bsps, so I've added a
>> --target-list to only build the targets that have a corresponding bsp
>> (sparc64-softmmu is missing as it runs into build issues, I forgot to
>> mention in the initial results). However the list spills over 80 lines
>> so should I make a %{qemu_targets} macro and if so where should I put
>> it?
>>
>>  --make=%{__make} \
>>  72 
>> --target-list=arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu,ppc-softmmu,sparc-softmmu
>> \
>>  73 ${VDE_CONFIG} \
>>  74 --disable-smartcard-nss \
>>
>> Thanks,
>>
>> Cillian.
>> ___
>> 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