Hello,
The problem is that the wrong timer is allocated. In the following code the second GPTIMER core is searched for (idx=1), which most LEON systems don't have. The standard configuration is that the LEON
chip has one GPTIMER core with multiple timer units within that GPTIMER core, what we should do is to use the second timer of the first GPTIMER core instead.
It is safe to assume that there is always two timer instances with the first GPTIMER. If we need a third timer, I think it would be better that it is not an critical error if the hardware is not
present, or that the driver is selectable from project configuration for hardware that supports multiple timers.
The only case I can think of that have multiple GPTIMER instances is NGMP, that
reason for that is to be able to support ASMP easier by letting each OS
instance have one GPTIMER core itself.
On the GR712RC this code will also fail, this is not because the GR712RC miss a
second timer core. But, because the second timer core is a GRTIMER which has a
different PnP ID.
+void leon3_cpu_counter_initialize(void)
+{
+ struct ambapp_dev *adev;
+ int idx = 1;
+ volatile struct gptimer_regs *gpt;
+ unsigned new_prescaler = 8;
+ unsigned prescaler;
+ uint32_t frequency;
+
+ 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);
+ }
Sebastian, what is the problem of using the System Clock timer GPTIMER[0].timer0. It is never stopped right? So basically it is running all the time and reading it would not cause the any conflict
with the Clock Driver. _CPU_Counter_read() does not take into account the underflow of the timer, is this accepted by the caller? Is 1MHz to slow? Will there be a rounding problem with the (prescaler
/ new_prescaler) calculation? The prescaler is always initialized to a value of number of MHz the system clock is running at, which means that LEON is limited to running at a frequency of a multiple
of 1MHz, but the prescaler does not have to be a multiple of 8.
Best Regards,
Daniel Hellstrom
Software Section Head
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758657
dan...@gaisler.com
www.Aeroflex.com/Gaisler
On 02/19/2014 06:17 PM, Joel Sherrill wrote:
OK.. On tsim-leon3, the BSP fails to find the GP_TIMER as best I
can tell:
(gdb) bt
#0 _Internal_error_Occurred (
the_source=the_source@entry=RTEMS_FATAL_SOURCE_BSP,
is_internal=is_internal@entry=false, the_error=the_error@entry=512)
at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
#1 0x400076f4 in rtems_fatal (source=source@entry=RTEMS_FATAL_SOURCE_BSP,
error=error@entry=512)
at ../../../../../../rtems/c/src/../../cpukit/sapi/src/fatal2.c:34
#2 0x400018a8 in bsp_fatal (code=LEON3_FATAL_CPU_COUNTER_INIT)
at ../../../../../.././leon3/lib/include/bsp/fatal.h:108
#3 leon3_cpu_counter_initialize ()
at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/startup/cpucounter.c:41
Tsim is documented to include a GPTIMER unit with two timers. I have no idea
why this is failing now since it should be there.
cc'ing Daniel so he can provide some feedback.
--joel
On 2/19/2014 3:24 AM, Sebastian Huber wrote:
On 2014-02-19 08:48, Sebastian Huber wrote:
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); }
With this change
http://git.rtems.org/rtems/commit/?id=33cb8bf64d7b7551ea3a2e7ced5d4b56cd32d6db
it is now easier to figure out what cased a BSP specific fatal error:
Breakpoint 2, _Internal_error_Occurred (the_source=RTEMS_FATAL_SOURCE_BSP,
is_internal=false, the_error=512) at
../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
36 {
(gdb) where
#0 _Internal_error_Occurred (the_source=RTEMS_FATAL_SOURCE_BSP,
is_internal=false, the_error=512) at
../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:36
#1 0x4000239c in leon3_cpu_counter_initialize () at
../../../../../.././leon3/lib/include/bsp/fatal.h:108
#2 0x40001c80 in bsp_start () at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/startup/bspstart.c:72
#3 0x40001b34 in boot_card (cmdline=0x0) at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../shared/bootcard.c:82
#4 0x400010c8 in zerobss () at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start/start.S:362
#5 0x400010c8 in zerobss () at
../../../../../../../../rtems/c/src/lib/libbsp/sparc/leon3/../../sparc/shared/start/start.S:362
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) p (bsp_fatal_code) the_error
$4 = LEON3_FATAL_CPU_COUNTER_INIT
(gdb)
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
