Re: [rtems commit] virtex5/startup/dummy_console.c: Fix no prototype warning

[Gedare Bloom]

On Tue, Apr 25, 2017 at 9:02 PM, Joel Sherrill  wrote:
>
>
> On Tue, Apr 25, 2017 at 7:21 PM, Gedare Bloom  wrote:
>>
>> On Mon, Apr 24, 2017 at 6:21 PM, Joel Sherrill  wrote:
>> > Module:rtems
>> > Branch:master
>> > Commit:fd48b43007b001a6f31949952504c9b55d895c4f
>> > Changeset:
>> > http://git.rtems.org/rtems/commit/?id=fd48b43007b001a6f31949952504c9b55d895c4f
>> >
>> > Author:Joel Sherrill 
>> > Date:  Mon Apr 24 11:15:53 2017 -0500
>> >
>> > virtex5/startup/dummy_console.c: Fix no prototype warning
>> >
>> > ---
>> >
>> >  c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
>> > b/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
>> > index 048133d..e62a9f0 100644
>> > --- a/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
>> > +++ b/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
>> > @@ -26,6 +26,7 @@ rtems_device_driver
>> > console_control(rtems_device_major_number major,
>> >  rtems_device_minor_number minor,
>> >  void* arg);
>> >
>> > +void BSP_output_char(char ch);
>> >
>> Can we avoid declaring non-static functions in .c files? I would
>> either see this in a header file, or see it declared as a static
>> function.
>
>
> It can't be static because it is in another file and used by both.
>
> I suppose a bspimpl.h could be added if folks desire.
>
If a function is used in more than one source file, it should be
exported via a header file to all of them. (I think this can, and
should, be a rule.)

>>
>>
>> >  ssize_t __bsp_memory_write(int minor, const char* buf, size_t len)
>> >  {
>> >
>> > ___
>> > vc mailing list
>> > v...@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/vc
>> ___
>> 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: Warning Report on Master

[Joel Sherrill]

On Tue, Apr 25, 2017 at 7:26 PM, Chris Johns  wrote:

> On 26/04/2017 09:18, Joel Sherrill wrote:
>
>>
>> This is the latest warnings report for the master.
>>
>
> I am seeing ...
>
>  Failures:
>arm/altcycv_devkit:  configure --target=arm-rtems4.12
> --enable-rtemsbsp=altcycv_devkit\
> --prefix=/opt/rtems/4.12 --enable-debug
> --enable-tests
>
> testsuites/libtests/block08/bdbuf_tests.c:144:24 error: expected ')'\
> before 'PRIdrtems_blkdev_bnum'
>arm/altcycv_devkit:  configure --target=arm-rtems4.12
> --enable-rtemsbsp=altcycv_devkit\
> --prefix=/opt/rtems/4.12 --enable-debug
> --enable-networking --enable-\
> tests
>
> testsuites/libtests/block08/bdbuf_tests.c:144:24 error: expected ')'\
> before 'PRIdrtems_blkdev_bnum'
>
> I will push a fix once I have tested it.
>
Hmm.. This should have worked or failed on all BSPs in all configurations.
And
apparently I got distracted and committed before looking at my logs. It did
fail on the BSP
which I was testing. Sorry.

The fix is simple. This test didn't include the general test macro files
tmacros.h
or pmacros.h. Thus it didn't have  already included.

I just pushed a fix.

>
> Time to start using the rtems-bsp-builder? :)
>

:) Didn't matter what I used. This was a stupid human error for not
checking that
the last build before I left the office actually worked. :(

Shame we don't have something automated that would prevented this. :(

Again my apologies

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

Re: [rtems commit] virtex5/startup/dummy_console.c: Fix no prototype warning

[Joel Sherrill]

On Tue, Apr 25, 2017 at 7:21 PM, Gedare Bloom  wrote:

> On Mon, Apr 24, 2017 at 6:21 PM, Joel Sherrill  wrote:
> > Module:rtems
> > Branch:master
> > Commit:fd48b43007b001a6f31949952504c9b55d895c4f
> > Changeset: http://git.rtems.org/rtems/commit/?id=
> fd48b43007b001a6f31949952504c9b55d895c4f
> >
> > Author:Joel Sherrill 
> > Date:  Mon Apr 24 11:15:53 2017 -0500
> >
> > virtex5/startup/dummy_console.c: Fix no prototype warning
> >
> > ---
> >
> >  c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
> b/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
> > index 048133d..e62a9f0 100644
> > --- a/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
> > +++ b/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
> > @@ -26,6 +26,7 @@ rtems_device_driver 
> > console_control(rtems_device_major_number
> major,
> >  rtems_device_minor_number minor,
> >  void* arg);
> >
> > +void BSP_output_char(char ch);
> >
> Can we avoid declaring non-static functions in .c files? I would
> either see this in a header file, or see it declared as a static
> function.
>

It can't be static because it is in another file and used by both.

I suppose a bspimpl.h could be added if folks desire.


>
> >  ssize_t __bsp_memory_write(int minor, const char* buf, size_t len)
> >  {
> >
> > ___
> > vc mailing list
> > v...@rtems.org
> > http://lists.rtems.org/mailman/listinfo/vc
> ___
> 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: [rtems commit] genmcf548x/irq/irq.c: Fix incompatible pointer warning

[Joel Sherrill]

On Tue, Apr 25, 2017 at 7:22 PM, Chris Johns  wrote:

> On 26/04/2017 10:19, Gedare Bloom wrote:
>
>>  static void_func get_exception_handler(rtems_vector_number vector)
>>>  {
>>> +  void **vbr;
>>>void_func *exception_table;
>>>
>>> -  m68k_get_vbr(exception_table);
>>> +  m68k_get_vbr(vbr);
>>> +
>>> +  exception_table = (void_func *)vbr;
>>>
>>> This looks strange. Can you achieve a similar effect with
>> m68k_get_vbr( (void*)exception_table );
>>
>>
> I think so. I prefer this.


On this architectural variant, m68k_get_vbr() is a macro with an assignment.
This results in the LHS having a cast to get the destination which we had
to work through the code base removing during the gcc 3.4 days.

I tried it and it didn't work. YMMV

--joel


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

Re: [rtems commit] posix/src/mutexinit.c: Fix used before initialized warning

[Joel Sherrill]

On Tue, Apr 25, 2017 at 7:25 PM, Gedare Bloom  wrote:

> On Tue, Apr 25, 2017 at 7:14 PM, Joel Sherrill  wrote:
> > Module:rtems
> > Branch:master
> > Commit:6601684f74f0ea1ec44fb52ec75d52215af11f5f
> > Changeset: http://git.rtems.org/rtems/commit/?id=
> 6601684f74f0ea1ec44fb52ec75d52215af11f5f
> >
> > Author:Joel Sherrill 
> > Date:  Tue Apr 25 13:57:03 2017 -0500
> >
> > posix/src/mutexinit.c: Fix used before initialized warning
> >
> > ---
> >
> >  cpukit/posix/src/mutexinit.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/cpukit/posix/src/mutexinit.c b/cpukit/posix/src/mutexinit.c
> > index 39139a4..47e0bcb 100644
> > --- a/cpukit/posix/src/mutexinit.c
> > +++ b/cpukit/posix/src/mutexinit.c
> > @@ -40,6 +40,9 @@ int pthread_mutex_init(
> >const Scheduler_Control   *scheduler;
> >Priority_Control   priority;
> >
> > +  /* initialize to avoid warning for used uninitialized */
> > +  priority = 0;
> > +
> The warning is spurious. You could refactor the code so the compiler
> doesn't get confused.
>

If you see how to do it, please go ahead. I have looked into this multiple
times over the years and not found the magic.



>
> >if ( attr ) the_attr = attr;
> >elsethe_attr = &_POSIX_Mutex_Default_attributes;
> >
> >
> > ___
> > vc mailing list
> > v...@rtems.org
> > http://lists.rtems.org/mailman/listinfo/vc
> ___
> 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: Warning Report on Master

[Chris Johns]

On 26/04/2017 09:18, Joel Sherrill wrote:


This is the latest warnings report for the master.


I am seeing ...

 Failures:
   arm/altcycv_devkit:  configure --target=arm-rtems4.12 
--enable-rtemsbsp=altcycv_devkit\
--prefix=/opt/rtems/4.12 --enable-debug 
--enable-tests


testsuites/libtests/block08/bdbuf_tests.c:144:24 error: expected ')'\
before 'PRIdrtems_blkdev_bnum'
   arm/altcycv_devkit:  configure --target=arm-rtems4.12 
--enable-rtemsbsp=altcycv_devkit\
--prefix=/opt/rtems/4.12 --enable-debug 
--enable-networking --enable-\

tests

testsuites/libtests/block08/bdbuf_tests.c:144:24 error: expected ')'\
before 'PRIdrtems_blkdev_bnum'

I will push a fix once I have tested it.

Time to start using the rtems-bsp-builder? :)

Chris

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

Re: [rtems commit] posix/src/mutexinit.c: Fix used before initialized warning

[Gedare Bloom]

On Tue, Apr 25, 2017 at 7:14 PM, Joel Sherrill  wrote:
> Module:rtems
> Branch:master
> Commit:6601684f74f0ea1ec44fb52ec75d52215af11f5f
> Changeset: 
> http://git.rtems.org/rtems/commit/?id=6601684f74f0ea1ec44fb52ec75d52215af11f5f
>
> Author:Joel Sherrill 
> Date:  Tue Apr 25 13:57:03 2017 -0500
>
> posix/src/mutexinit.c: Fix used before initialized warning
>
> ---
>
>  cpukit/posix/src/mutexinit.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/cpukit/posix/src/mutexinit.c b/cpukit/posix/src/mutexinit.c
> index 39139a4..47e0bcb 100644
> --- a/cpukit/posix/src/mutexinit.c
> +++ b/cpukit/posix/src/mutexinit.c
> @@ -40,6 +40,9 @@ int pthread_mutex_init(
>const Scheduler_Control   *scheduler;
>Priority_Control   priority;
>
> +  /* initialize to avoid warning for used uninitialized */
> +  priority = 0;
> +
The warning is spurious. You could refactor the code so the compiler
doesn't get confused.

>if ( attr ) the_attr = attr;
>elsethe_attr = &_POSIX_Mutex_Default_attributes;
>
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] genmcf548x/irq/irq.c: Fix incompatible pointer warning

[Chris Johns]

On 26/04/2017 10:19, Gedare Bloom wrote:

 static void_func get_exception_handler(rtems_vector_number vector)
 {
+  void **vbr;
   void_func *exception_table;

-  m68k_get_vbr(exception_table);
+  m68k_get_vbr(vbr);
+
+  exception_table = (void_func *)vbr;


This looks strange. Can you achieve a similar effect with
m68k_get_vbr( (void*)exception_table );



I think so. I prefer this.

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

Re: [rtems commit] virtex5/startup/dummy_console.c: Fix no prototype warning

[Gedare Bloom]

On Mon, Apr 24, 2017 at 6:21 PM, Joel Sherrill  wrote:
> Module:rtems
> Branch:master
> Commit:fd48b43007b001a6f31949952504c9b55d895c4f
> Changeset: 
> http://git.rtems.org/rtems/commit/?id=fd48b43007b001a6f31949952504c9b55d895c4f
>
> Author:Joel Sherrill 
> Date:  Mon Apr 24 11:15:53 2017 -0500
>
> virtex5/startup/dummy_console.c: Fix no prototype warning
>
> ---
>
>  c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c 
> b/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
> index 048133d..e62a9f0 100644
> --- a/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
> +++ b/c/src/lib/libbsp/powerpc/virtex5/startup/dummy_console.c
> @@ -26,6 +26,7 @@ rtems_device_driver 
> console_control(rtems_device_major_number major,
>  rtems_device_minor_number minor,
>  void* arg);
>
> +void BSP_output_char(char ch);
>
Can we avoid declaring non-static functions in .c files? I would
either see this in a header file, or see it declared as a static
function.

>  ssize_t __bsp_memory_write(int minor, const char* buf, size_t len)
>  {
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] genmcf548x/irq/irq.c: Fix incompatible pointer warning

[Gedare Bloom]

On Mon, Apr 24, 2017 at 6:21 PM, Joel Sherrill  wrote:
> Module:rtems
> Branch:master
> Commit:485222e633da85047daa1dafd1732b2b4750e933
> Changeset: 
> http://git.rtems.org/rtems/commit/?id=485222e633da85047daa1dafd1732b2b4750e933
>
> Author:Joel Sherrill 
> Date:  Mon Apr 24 12:00:15 2017 -0500
>
> genmcf548x/irq/irq.c: Fix incompatible pointer warning
>
> ---
>
>  c/src/lib/libbsp/m68k/genmcf548x/irq/irq.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/c/src/lib/libbsp/m68k/genmcf548x/irq/irq.c 
> b/c/src/lib/libbsp/m68k/genmcf548x/irq/irq.c
> index 47a155a..58e9044 100644
> --- a/c/src/lib/libbsp/m68k/genmcf548x/irq/irq.c
> +++ b/c/src/lib/libbsp/m68k/genmcf548x/irq/irq.c
> @@ -99,18 +99,24 @@ rtems_status_code 
> bsp_interrupt_vector_disable(rtems_vector_number vector)
>
>  static void_func get_exception_handler(rtems_vector_number vector)
>  {
> +  void **vbr;
>void_func *exception_table;
>
> -  m68k_get_vbr(exception_table);
> +  m68k_get_vbr(vbr);
> +
> +  exception_table = (void_func *)vbr;
>
This looks strange. Can you achieve a similar effect with
m68k_get_vbr( (void*)exception_table );

>return exception_table[vector_to_exception_vector(vector)];
>  }
>
>  static void set_exception_handler(rtems_vector_number vector, void_func 
> handler)
>  {
> +  void **vbr;
>void_func *exception_table;
>
> -  m68k_get_vbr(exception_table);
> +  m68k_get_vbr(vbr);
> +
> +  exception_table = (void_func *)vbr;
>
>exception_table[vector_to_exception_vector(vector)] = handler;
>  }
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems commit] dhrystone/dhry_1.c: Fix may be used uninitialized warning

[Gedare Bloom]

On Mon, Apr 24, 2017 at 6:21 PM, Joel Sherrill  wrote:
> Module:rtems
> Branch:master
> Commit:906e67fe88658122d515a5dcc0570ee56a02877d
> Changeset: 
> http://git.rtems.org/rtems/commit/?id=906e67fe88658122d515a5dcc0570ee56a02877d
>
> Author:Joel Sherrill 
> Date:  Sun Apr 23 11:50:46 2017 -0500
>
> dhrystone/dhry_1.c: Fix may be used uninitialized warning
>
> ---
>
>  testsuites/benchmarks/dhrystone/dhry_1.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/testsuites/benchmarks/dhrystone/dhry_1.c 
> b/testsuites/benchmarks/dhrystone/dhry_1.c
> index 36ac303..9b64d3a 100644
> --- a/testsuites/benchmarks/dhrystone/dhry_1.c
> +++ b/testsuites/benchmarks/dhrystone/dhry_1.c
> @@ -143,6 +143,11 @@ execution_start:
>Begin_Time = time ( (long *) 0);
>  #endif
>
> +#ifdef __rtems__
> +  /* avoid used uninitialized warning */
> +  Int_2_Loc = 0;
> +#endif
> +
This looks like unnecessarily catering to the compiler. At any rate,
this kind of change should be located before the call to the timer,
since it maybe perturbs the benchmark timing.

>for (Run_Index = 1; Run_Index <= Number_Of_Runs; ++Run_Index)
>{
>
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help Request - Fix Out of Bounds Subscript Warning in Raspberry Pi

[Pavel Pisa]

Hello Joel,

On Wednesday 26 of April 2017 01:03:30 Joel Sherrill wrote:
> Pavel,
>
> Feel free to commit the patch.

the patch should be tested and (unfortunately) I do not get
to that in next weeks. I have not even check that it compiles.
If you apply it and it compiles for you and you are happy with
it, push it please.

As for the GCC analysis, it does not warn for preceding
sequence

  *bank_number = bank;

  ACQUIRE_LOCK(gpio_bank_state[bank].lock);

but the first iteration has to go through this branch of the if.
So the range check has to be valid for values stored 
into *bank_number for all following iterations.

I think that GCC is puzzled because it does not
find that there is no other way into else branch then
after if branch.

At least it is my expectation.

Best wishes,

Pavel


> Why do you think the warning is a false positive?
>
> --joel
>
> On Tue, Apr 25, 2017 at 4:53 AM, Pavel Pisa  wrote:
> > From 3a2957faeb744af08196f1fd3baac71f15d76c85 Mon Sep 17 00:00:00 2001
> > Message-Id: <3a2957faeb744af08196f1fd3baac71f15d76c85.1493113587.git.
> > pp...@pikron.com>
> > From: Pavel Pisa 
> > Date: Tue, 25 Apr 2017 11:45:57 +0200
> > Subject: [PATCH] bsp/raspberrypi: GPIO silence warning and ensure that
> > lock is
> >  always released.
> > To: rtems-de...@rtems.org
> >
> > Signed-off-by: Pavel Pisa 
> > ---
> >  c/src/lib/libbsp/shared/gpio.c | 18 --
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > Not tested or even compiled quick fix of warning and more serious real
> > problem.
> > The waning seems to be GCC false positive. The first iteration
> > (i == 0) sets *bank_number for sure. But return with RTEMS_INVALID_ID can
> > happen without lock release.
> >
> > diff --git a/c/src/lib/libbsp/shared/gpio.c b/c/src/lib/libbsp/shared/
> > gpio.c
> > index 9ceeb407..bf0e415 100644
> > --- a/c/src/lib/libbsp/shared/gpio.c
> > +++ b/c/src/lib/libbsp/shared/gpio.c
> > @@ -303,6 +303,7 @@ static rtems_status_code get_pin_bitmask(
> >uint32_t pin_number;
> >uint32_t bank;
> >uint8_t i;
> > +  int locked_bank = -1;
> >
> >if ( pin_count < 1 ) {
> >  return RTEMS_UNSATISFIED;
> > @@ -314,18 +315,23 @@ static rtems_status_code get_pin_bitmask(
> >  pin_number = pins[i];
> >
> >  if ( pin_number < 0 || pin_number >= BSP_GPIO_PIN_COUNT ) {
> > +  if (locked_bank >= 0)
> > +RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
> > +
> >return RTEMS_INVALID_ID;
> >  }
> >
> >  bank = BANK_NUMBER(pin_number);
> >
> > -if ( i == 0 ) {
> > +if ( locked_bank < 0 ) {
> >*bank_number = bank;
> > +  locked_bank = bank;
> >
> > -  ACQUIRE_LOCK(gpio_bank_state[bank].lock);
> > +  ACQUIRE_LOCK(gpio_bank_state[locked_bank].lock);
> >  }
> > -else if ( bank != *bank_number ) {
> > -  RELEASE_LOCK(gpio_bank_state[*bank_number].lock);
> > +else if ( bank != locked_bank ) {
> > +  if (locked_bank >= 0)
> > +RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
> >
> >return RTEMS_UNSATISFIED;
> >  }
> > @@ -334,7 +340,7 @@ static rtems_status_code get_pin_bitmask(
> >  gpio_pin_state[pin_number].pin_function != function ||
> >  gpio_pin_state[pin_number].on_group
> >  ) {
> > -  RELEASE_LOCK(gpio_bank_state[bank].lock);
> > +  RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
> >
> >return RTEMS_NOT_CONFIGURED;
> >  }
> > @@ -342,7 +348,7 @@ static rtems_status_code get_pin_bitmask(
> >  *bitmask |= (1 << PIN_NUMBER(pin_number));
> >}
> >
> > -  RELEASE_LOCK(gpio_bank_state[bank].lock);
> > +  RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
> >
> >return RTEMS_SUCCESSFUL;
> >  }
> > --
> > 1.9.1

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

Re: [PATCH 0/2] Zynq7000 series device configuration driver

[Chris Johns]

On 22/04/2017 01:44, Patrick Gauvin wrote:

I'll plan on storing a few bitfiles for common platforms, like the
MicroZed (7Z010) and the ZedBoard (7Z020), with the test. I do have a
simple bitfile, but it currently targets the ZedBoard. If you'd like, I
can send a version for the MicroZed when I send the updated patches next
week (should I attach it to the mailing list? I'm not sure what the
etiquette is for large attachments).


Send me the files directly and I can upload them to the ftp server. We 
can figure out how to integrate them into the build after that.



I worry about the processing system initialization (such as FCLK
frequency) being mismatched with the bitstream.


I have code to control some of the clocks and set them. Further to this 
for a project I have been adding pre and post load metadata to a bitfile 
wrapper to manage this issue. The pre-load metadata can hold 
configurations that update the Zynq before a load, for example FCLK. 
This moves the role of the FSBL initialise to being a default and for 
example specific bitfiles can be built at different AXI clock speeds. In 
the case of the Zedboard you could have a bitfile that has a completely 
difference set up to the Zedboard's default.



I think the SDK
generates a GPLed FSBL source now, so maybe including that will do.


I do not think the SDK FSBL is GPL. It use to be restrictive but I think 
recent versions have a better license. I have not checked lately.



If
there is an alternative I'd love to hear it, I dislike being tied to the
SDK for initialization.


I prefer to have no dependency on the SDK because of the complexity it 
creates, for example the FPGA team want a later release because it is a 
faster or better build, while the matching SDK break software, or the 
compiler is broken, or some other reason.


The only solutions I know of are the SDK, uboot or some code I have. My 
solution needs some work to make public.


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

Warning Report on Master

[Joel Sherrill]

Hi

This is the latest warnings report for the master. This is
the first report in a LONG time where nearly all BSPs
were warning free.

Note that it ignores issues in code associated with the
old network stack. Now that the status is pretty good,
nibbling at those is a reasonable step.

ftp://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-4.12-master-20170425c

Unique Warnings :  20
BSPs:  167
BSPs with Zero  :  161
BSPs with only in shared:  4


 Warnings by Class

  1 array-bounds
  4 maybe-uninitialized
  4 unused-local-typedefs


 Top Ten BSPs with Warnings

0 sparc-leon3  (none)
0 sparc-ngmp  (none)
0 v850-v850e1sim  (none)
0 v850-v850e2sim  (none)
0 v850-v850e2v3sim  (none)
0 v850-v850esim  (none)
0 v850-v850essim  (none)
0 v850-v850sim  (none)
1 arm-raspberrypi2  (inBSP=1 inLibCPU=0)
1 arm-raspberrypi  (inBSP=1 inLibCPU=0)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help Request - Fix Out of Bounds Subscript Warning in Raspberry Pi

[Joel Sherrill]

Pavel,

Feel free to commit the patch.

Why do you think the warning is a false positive?

--joel

On Tue, Apr 25, 2017 at 4:53 AM, Pavel Pisa  wrote:

> From 3a2957faeb744af08196f1fd3baac71f15d76c85 Mon Sep 17 00:00:00 2001
> Message-Id: <3a2957faeb744af08196f1fd3baac71f15d76c85.1493113587.git.
> pp...@pikron.com>
> From: Pavel Pisa 
> Date: Tue, 25 Apr 2017 11:45:57 +0200
> Subject: [PATCH] bsp/raspberrypi: GPIO silence warning and ensure that
> lock is
>  always released.
> To: rtems-de...@rtems.org
>
> Signed-off-by: Pavel Pisa 
> ---
>  c/src/lib/libbsp/shared/gpio.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> Not tested or even compiled quick fix of warning and more serious real
> problem.
> The waning seems to be GCC false positive. The first iteration
> (i == 0) sets *bank_number for sure. But return with RTEMS_INVALID_ID can
> happen without lock release.
>
> diff --git a/c/src/lib/libbsp/shared/gpio.c b/c/src/lib/libbsp/shared/
> gpio.c
> index 9ceeb407..bf0e415 100644
> --- a/c/src/lib/libbsp/shared/gpio.c
> +++ b/c/src/lib/libbsp/shared/gpio.c
> @@ -303,6 +303,7 @@ static rtems_status_code get_pin_bitmask(
>uint32_t pin_number;
>uint32_t bank;
>uint8_t i;
> +  int locked_bank = -1;
>
>if ( pin_count < 1 ) {
>  return RTEMS_UNSATISFIED;
> @@ -314,18 +315,23 @@ static rtems_status_code get_pin_bitmask(
>  pin_number = pins[i];
>
>  if ( pin_number < 0 || pin_number >= BSP_GPIO_PIN_COUNT ) {
> +  if (locked_bank >= 0)
> +RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
> +
>return RTEMS_INVALID_ID;
>  }
>
>  bank = BANK_NUMBER(pin_number);
>
> -if ( i == 0 ) {
> +if ( locked_bank < 0 ) {
>*bank_number = bank;
> +  locked_bank = bank;
>
> -  ACQUIRE_LOCK(gpio_bank_state[bank].lock);
> +  ACQUIRE_LOCK(gpio_bank_state[locked_bank].lock);
>  }
> -else if ( bank != *bank_number ) {
> -  RELEASE_LOCK(gpio_bank_state[*bank_number].lock);
> +else if ( bank != locked_bank ) {
> +  if (locked_bank >= 0)
> +RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
>
>return RTEMS_UNSATISFIED;
>  }
> @@ -334,7 +340,7 @@ static rtems_status_code get_pin_bitmask(
>  gpio_pin_state[pin_number].pin_function != function ||
>  gpio_pin_state[pin_number].on_group
>  ) {
> -  RELEASE_LOCK(gpio_bank_state[bank].lock);
> +  RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
>
>return RTEMS_NOT_CONFIGURED;
>  }
> @@ -342,7 +348,7 @@ static rtems_status_code get_pin_bitmask(
>  *bitmask |= (1 << PIN_NUMBER(pin_number));
>}
>
> -  RELEASE_LOCK(gpio_bank_state[bank].lock);
> +  RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
>
>return RTEMS_SUCCESSFUL;
>  }
> --
> 1.9.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] cpukit/../ratemonreportstatistics.c:Use rtems/inttypes removes 12 warnings.

[Joel Sherrill]

I pushed a slightly different patch to this file yesterday. I used
PRItime_t as I recall.

Update your tree. I got rid of a LOT of warnings this weekend.

--joel

On Apr 25, 2017 5:02 AM, "Cillian O'Donnell"  wrote:

> ---
>  cpukit/rtems/src/ratemonreportstatistics.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/cpukit/rtems/src/ratemonreportstatistics.c
> b/cpukit/rtems/src/ratemonreportstatistics.c
> index a1bab4a..78477b0 100644
> --- a/cpukit/rtems/src/ratemonreportstatistics.c
> +++ b/cpukit/rtems/src/ratemonreportstatistics.c
> @@ -21,13 +21,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
>  /* We print to 1/10's of milliseconds */
>  #define NANOSECONDS_DIVIDER 1000
>  #define PERCENT_FMT "%04" PRId32
> -#define NANOSECONDS_FMT "%06" PRId32
> +#define NANOSECONDS_FMT "%06" PRIdtime_t
>
>  void rtems_rate_monotonic_report_statistics_with_plugin(
>const rtems_printer *printer
> @@ -112,9 +113,9 @@ ididididid  c mm X
>
>_Timespec_Divide_by_integer( total_cpu, the_stats.count,
> _average );
>rtems_printf( printer,
> -"%" PRId32 "."  NANOSECONDS_FMT "/"/* min cpu time */
> -"%" PRId32 "."  NANOSECONDS_FMT "/"/* max cpu time */
> -"%" PRId32 "."  NANOSECONDS_FMT " ",   /* avg cpu time */
> +"%" PRIdtime_t "."  NANOSECONDS_FMT "/"/* min cpu time */
> +"%" PRIdtime_t "."  NANOSECONDS_FMT "/"/* max cpu time */
> +"%" PRIdtime_t "."  NANOSECONDS_FMT " ",   /* avg cpu time */
>  _Timespec_Get_seconds( min_cpu ),
>   _Timespec_Get_nanoseconds( min_cpu ) / NANOSECONDS_DIVIDER,
>  _Timespec_Get_seconds( max_cpu ),
> @@ -135,9 +136,9 @@ ididididid  c mm X
>
>_Timespec_Divide_by_integer(total_wall, the_stats.count,
> _average);
>rtems_printf( printer,
> -"%" PRId32 "." NANOSECONDS_FMT "/"/* min wall time */
> -"%" PRId32 "." NANOSECONDS_FMT "/"/* max wall time */
> -"%" PRId32 "." NANOSECONDS_FMT "\n",  /* avg wall time */
> +"%" PRIdtime_t "." NANOSECONDS_FMT "/"/* min wall time */
> +"%" PRIdtime_t "." NANOSECONDS_FMT "/"/* max wall time */
> +"%" PRIdtime_t "." NANOSECONDS_FMT "\n",  /* avg wall time */
>  _Timespec_Get_seconds( min_wall ),
>_Timespec_Get_nanoseconds( min_wall ) / NANOSECONDS_DIVIDER,
>  _Timespec_Get_seconds( max_wall ),
> --
> 2.7.4
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] cpukit/../ratemonreportstatistics.c:Use rtems/inttypes removes 12 warnings.

[Cillian O'Donnell]

---
 cpukit/rtems/src/ratemonreportstatistics.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/cpukit/rtems/src/ratemonreportstatistics.c 
b/cpukit/rtems/src/ratemonreportstatistics.c
index a1bab4a..78477b0 100644
--- a/cpukit/rtems/src/ratemonreportstatistics.c
+++ b/cpukit/rtems/src/ratemonreportstatistics.c
@@ -21,13 +21,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
 /* We print to 1/10's of milliseconds */
 #define NANOSECONDS_DIVIDER 1000
 #define PERCENT_FMT "%04" PRId32
-#define NANOSECONDS_FMT "%06" PRId32
+#define NANOSECONDS_FMT "%06" PRIdtime_t
 
 void rtems_rate_monotonic_report_statistics_with_plugin(
   const rtems_printer *printer
@@ -112,9 +113,9 @@ ididididid  c mm X
 
   _Timespec_Divide_by_integer( total_cpu, the_stats.count, _average );
   rtems_printf( printer,
-"%" PRId32 "."  NANOSECONDS_FMT "/"/* min cpu time */
-"%" PRId32 "."  NANOSECONDS_FMT "/"/* max cpu time */
-"%" PRId32 "."  NANOSECONDS_FMT " ",   /* avg cpu time */
+"%" PRIdtime_t "."  NANOSECONDS_FMT "/"/* min cpu time */
+"%" PRIdtime_t "."  NANOSECONDS_FMT "/"/* max cpu time */
+"%" PRIdtime_t "."  NANOSECONDS_FMT " ",   /* avg cpu time */
 _Timespec_Get_seconds( min_cpu ),
  _Timespec_Get_nanoseconds( min_cpu ) / NANOSECONDS_DIVIDER,
 _Timespec_Get_seconds( max_cpu ),
@@ -135,9 +136,9 @@ ididididid  c mm X
 
   _Timespec_Divide_by_integer(total_wall, the_stats.count, _average);
   rtems_printf( printer,
-"%" PRId32 "." NANOSECONDS_FMT "/"/* min wall time */
-"%" PRId32 "." NANOSECONDS_FMT "/"/* max wall time */
-"%" PRId32 "." NANOSECONDS_FMT "\n",  /* avg wall time */
+"%" PRIdtime_t "." NANOSECONDS_FMT "/"/* min wall time */
+"%" PRIdtime_t "." NANOSECONDS_FMT "/"/* max wall time */
+"%" PRIdtime_t "." NANOSECONDS_FMT "\n",  /* avg wall time */
 _Timespec_Get_seconds( min_wall ),
   _Timespec_Get_nanoseconds( min_wall ) / NANOSECONDS_DIVIDER,
 _Timespec_Get_seconds( max_wall ),
-- 
2.7.4

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

Re: Help Request - Fix Out of Bounds Subscript Warning in Raspberry Pi

[Pavel Pisa]

>From 3a2957faeb744af08196f1fd3baac71f15d76c85 Mon Sep 17 00:00:00 2001
Message-Id: 
<3a2957faeb744af08196f1fd3baac71f15d76c85.1493113587.git.pp...@pikron.com>
From: Pavel Pisa 
Date: Tue, 25 Apr 2017 11:45:57 +0200
Subject: [PATCH] bsp/raspberrypi: GPIO silence warning and ensure that lock is
 always released.
To: rtems-de...@rtems.org

Signed-off-by: Pavel Pisa 
---
 c/src/lib/libbsp/shared/gpio.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

Not tested or even compiled quick fix of warning and more serious real problem.
The waning seems to be GCC false positive. The first iteration
(i == 0) sets *bank_number for sure. But return with RTEMS_INVALID_ID can
happen without lock release.

diff --git a/c/src/lib/libbsp/shared/gpio.c b/c/src/lib/libbsp/shared/gpio.c
index 9ceeb407..bf0e415 100644
--- a/c/src/lib/libbsp/shared/gpio.c
+++ b/c/src/lib/libbsp/shared/gpio.c
@@ -303,6 +303,7 @@ static rtems_status_code get_pin_bitmask(
   uint32_t pin_number;
   uint32_t bank;
   uint8_t i;
+  int locked_bank = -1;
 
   if ( pin_count < 1 ) {
 return RTEMS_UNSATISFIED;
@@ -314,18 +315,23 @@ static rtems_status_code get_pin_bitmask(
 pin_number = pins[i];
 
 if ( pin_number < 0 || pin_number >= BSP_GPIO_PIN_COUNT ) {
+  if (locked_bank >= 0)
+RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
+
   return RTEMS_INVALID_ID;
 }
 
 bank = BANK_NUMBER(pin_number);
 
-if ( i == 0 ) {
+if ( locked_bank < 0 ) {
   *bank_number = bank;
+  locked_bank = bank;
 
-  ACQUIRE_LOCK(gpio_bank_state[bank].lock);
+  ACQUIRE_LOCK(gpio_bank_state[locked_bank].lock);
 }
-else if ( bank != *bank_number ) {
-  RELEASE_LOCK(gpio_bank_state[*bank_number].lock);
+else if ( bank != locked_bank ) {
+  if (locked_bank >= 0)
+RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
 
   return RTEMS_UNSATISFIED;
 }
@@ -334,7 +340,7 @@ static rtems_status_code get_pin_bitmask(
 gpio_pin_state[pin_number].pin_function != function ||
 gpio_pin_state[pin_number].on_group
 ) {
-  RELEASE_LOCK(gpio_bank_state[bank].lock);
+  RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
 
   return RTEMS_NOT_CONFIGURED;
 }
@@ -342,7 +348,7 @@ static rtems_status_code get_pin_bitmask(
 *bitmask |= (1 << PIN_NUMBER(pin_number));
   }
 
-  RELEASE_LOCK(gpio_bank_state[bank].lock);
+  RELEASE_LOCK(gpio_bank_state[locked_bank].lock);
 
   return RTEMS_SUCCESSFUL;
 }
-- 
1.9.1

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