RTEMS | RTEMS 6.1 GR740 Multiprocessing build fails (#5281)
Gedare Bloom (@gedare)
gitlab at rtems.org
Tue Jun 24 20:26:53 UTC 2025
Gedare Bloom created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5281
## Summary
When building the GR740 BSP with `RTEMS_MULTIPROCESSING` set to `true` , the build will fail.
## Steps to reproduce
The INI file contents are:
```
[DEFAULT]
RTEMS_POSIX_API = True
[sparc/gr740_mp]
INHERIT=gr740
RTEMS_MULTIPROCESSING=True
```
I configure the Waf system with:
`./waf configure --prefix=$RTEMS_PREFIX --rtems-config=gr740.ini`
And then `./waf` to build the BSP. I get the following output:
```
Waf: Entering directory `/scratch/matteo/rtems-build/src/rtems-6.1/build'
Waf: Leaving directory `/scratch/matteo/rtems-build/src/rtems-6.1/build'
'build' finished successfully (0.081s)
Waf: Entering directory `/scratch/matteo/rtems-build/src/rtems-6.1/build/sparc/gr740_mp'
[ 167/1641] Compiling bsps/sparc/leon3/clock/ckinit.c
In file included from ../../../bsps/sparc/leon3/clock/ckinit.c:46:
../../../bsps/sparc/leon3/clock/ckinit.c: In function 'leon3_clock_initialize':
../../../bsps/sparc/leon3/include/bsp/leon3.h:221:5: error: 'leon3_timer_core_index' undeclared (first use in this function); did you mean 'leon3_timecounter'?
221 | ( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index )
| ^~~~~~~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/ckinit.c:181:36: note: in expansion of macro 'LEON3_CLOCK_INDEX'
181 | timer = &LEON3_Timer_Regs->timer[LEON3_CLOCK_INDEX];
| ^~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/include/bsp/leon3.h:221:5: note: each undeclared identifier is reported only once for each function it appears in
221 | ( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index )
| ^~~~~~~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/ckinit.c:181:36: note: in expansion of macro 'LEON3_CLOCK_INDEX'
181 | timer = &LEON3_Timer_Regs->timer[LEON3_CLOCK_INDEX];
| ^~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/../../../shared/dev/clock/clockimpl.h: In function '_Clock_Initialize':
../../../bsps/sparc/leon3/include/bsp/leon3.h:221:5: error: 'leon3_timer_core_index' undeclared (first use in this function); did you mean 'leon3_timecounter'?
221 | ( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index )
| ^~~~~~~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/ckinit.c:137:49: note: in expansion of macro 'LEON3_CLOCK_INDEX'
137 | #define Adjust_clkirq_for_node() do { clkirq += LEON3_CLOCK_INDEX; } while(0)
| ^~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/ckinit.c:145:7: note: in expansion of macro 'Adjust_clkirq_for_node'
145 | Adjust_clkirq_for_node(); \
| ^~~~~~~~~~~~~~~~~~~~~~
../../../bsps/sparc/leon3/clock/../../../shared/dev/clock/clockimpl.h:249:3: note: in expansion of macro 'Clock_driver_support_find_timer'
249 | Clock_driver_support_find_timer();
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Waf: Leaving directory `/scratch/matteo/rtems-build/src/rtems-6.1/build/sparc/gr740_mp'
Build failed
-> task in '/bsps/sparc/leon3/obj' failed with exit status 1 (run with -v to display more information)
```
## Expected behaviour
Build should complete successfully.
## Possible fix
>From my own investigation this comes from `bsps/sparc/leon3/include/bsp/leon3.h` . `leon3_timer_core_index` is only declared if `LEON3_GPTIMER_BASE` is not defined but later in the file the `LEON3_CLOCK_INDEX` macro is defined in the following way:
```c
/**
* @brief This constant defines the index of the GPTIMER timer used by the
* clock driver.
*/
#if defined(RTEMS_MULTIPROCESSING)
#define LEON3_CLOCK_INDEX \
( leon3_timer_core_index != 0 ? 0 : 2 * LEON3_Cpu_Index )
#else
#define LEON3_CLOCK_INDEX 0
#endif
```
So when `RTEMS_MULTIPROCESSING` is used the `LEON3_CLOCK_INDEX` will expand to use the `leon3_timer_core_index` variable which won't be declared as the GPTIMER base is defined for the GR740 BSP.
I don't fully understand why the `LEON3_CLOCK_INDEX` macro is defined this way but changing it's define conditional to:
```c
#if defined(RTEMS_MULTIPROCESSING) && !defined(LEON3_GPTIMER_BASE)
```
Will make the BSP build successfully, I haven't had the time to test this fix, it might break something else at runtime.
--
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5281
You're receiving this email because of your account on gitlab.rtems.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250624/28cb7802/attachment-0001.htm>
More information about the bugs
mailing list