leon3 broken for hello

[Sebastian Huber]

Hello Joel,

since you don't provide much information (e.g. at least a stack trace would 
have been helpful) I can only guess.  You probably configured only one GPTIMER 
instance in the simulators.  Since the LEON processors lacks a free-running CPU 
counter I had to use a second GPTIMER instance for this.

You should end up in _Internal_error_Occurred() with the_source == 
RTEMS_FATAL_SOURCE_BSP_SPECIFIC.  Now you can look at the <bsp.h> of the LEON3 
BSP and find this:

typedef enum {
   LEON3_FATAL_CPU_COUNTER_INIT
} leon3_fatal_code;

If you search for LEON3_FATAL_CPU_COUNTER_INIT you will find this:

   adev = (void *) ambapp_for_each(
     &ambapp_plb,
     OPTIONS_ALL | OPTIONS_APB_SLVS,
     VENDOR_GAISLER,
     GAISLER_GPTIMER,
     ambapp_find_by_idx,
     &idx
   );
   if (adev == NULL) {
     rtems_fatal(RTEMS_FATAL_SOURCE_BSP_SPECIFIC, LEON3_FATAL_CPU_COUNTER_INIT);
   }

The question is now: is the absence of a second GPTIMER really a fatal error?

We can avoid a fatal error with the attached patch, but in this case the CPU 
counter returns invalid results (e.g. a rtems_counter_delay_ticks() will loop 
infinitely).  We can also redirect the register to the GPTIMER 0 which is used 
by the clock drivers and a possible watchdog.  The clock driver and watchdog 
need processor count + 1 timers.  What happens if we don't have that many 
timers in GPTIMER 0?

On 2014-02-19 01:10, Joel Sherrill wrote:
> git bisect ran the change down to this. It was running on tsim leon3
> and grsim before this but broke after this.
>
> -bash-4.2$ git bisect bad
> 24bf11eca11947d961cc9bb5f7d92dabff169e93 is the first bad commit
> commit 24bf11eca11947d961cc9bb5f7d92dabff169e93
> Author: Sebastian Huber <sebastian.huber at embedded-brains.de>
> Date:   Wed Feb 12 10:31:38 2014 +0100
>
>      score: Add CPU counter support
>
>      Add a CPU counter interface to allow access to a free-running counter.
>      It is useful to measure short time intervals.  This can be used for
>      example to enable profiling of critical low-level functions.
>
>      Add two busy wait functions rtems_counter_delay_ticks() and
>      rtems_counter_delay_nanoseconds() implemented via the CPU counter.
>
> :040000 040000 bb390b07675147a4b04bdfdba13d092726486075
> 948e8ec05ff56398dfee678c61c6e1a1ce2063bb M    c
> :040000 040000 3a8d256d93f7e8da95cb5b192a0d2babb3602fd8
> 85357381e4b15e2bbe83eb046290f913c6ed8db5 M    cpukit
> :040000 040000 4b7ccb865ac2633739868fafba5bda2e9bce363a
> 6d94e948495a5bca2dc9fb7022bfe1f1402201fc M    doc
> :040000 040000 950f06247d20e4b10bf20de2a251afef810a6bc2
> b7e3e1ca1fe5159a1550c5092f096c99f159bcec M    testsuites
>
>
> On 2/18/2014 1:12 PM, Joel Sherrill wrote:
>> Hi
>>
>> As best Jennifer and I can tell, the leon3 is broken at the moment.
>> hello does not run on either tsim or grsim.
>>
>> Starting a git bisect but feedback is appreciated.
>>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com         On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>


-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hack.patch
Type: text/x-patch
Size: 2267 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140219/cf307da6/attachment-0001.bin>