RTEMS: fix off-by-one array read in cpu_ticks()

[hjunkes]

Summary

cpu_ticks() in devIocStats/os/RTEMS/osdCpuUsage.c indexes obj->local_table[y] for y in 1..obj->maximum. But OBJECTS_INFORMATION_DEFINE allocates local_table[max] with valid indices 0..max-1, since RTEMS stores each object at id_index - OBJECTS_INDEX_MINIMUM (OBJECTS_INDEX_MINIMUM is 1). So this loop:

• reads one Thread_Control pointer past the end of local_table on every pass, and
• never reads the object actually stored at index 0.

I found this while chasing a hard crash under RTEMS 7 on a BeagleBone Black BSP. I initially assumed it was a Thread_Control struct layout change in RTEMS 7 (see discussion on #61), but verified with offsetof/sizeof against the real RTEMS 6 and RTEMS 7 headers/compilers for that BSP that the struct layout is byte-for-byte identical. The actual cause is this off-by-one, which apparently reads harmless memory under older RTEMS memory layouts but faults under RTEMS 7's.

Fix

Index with y - 1 instead of y.

Test plan

• Compiled osdCpuUsage.c cleanly with -Wall -Wextra against real RTEMS 6 and RTEMS 7 headers/cross-compilers for arm-rtems*-beagleboneblack.
• Confirmed via a small offsetof/sizeof probe that Thread_Control layout (and thus cpu_time_used's offset) is unchanged between RTEMS 6 and 7 for this target, ruling out a struct-layout explanation for the original crash.

[anjohnson]

Is the macro OBJECTS_INDEX_MINIMUM visible to the compiler here? If so this code should probably use that instead of the literal 1.

[hjunkes]

Yes, it's visible — OBJECTS_INDEX_MINIMUM is defined in rtems/score/objectimpl.h, and _Objects_Information_table (used a couple of lines above) is declared 8 lines below it in that same header. Switched to it.

While verifying this actually compiles against a current RTEMS 7 build (2026.03.04), I found this file wasn't building at all against it, for reasons unrelated to this specific line:

• devIocStatsOSD.h relied on <rtems.h> transitively pulling in <rtems/score/objectimpl.h> — current RTEMS no longer does that, so _Objects_Information_table/Objects_Information/OBJECTS_INDEX_MINIMUM weren't visible at all until I added the include explicitly.
• Objects_Information::maximum has been renamed to maximum_id and is now an encoded Objects_Id (API/class/node/index bits), not a plain count. Switched to _Objects_Get_maximum_index(), which is what RTEMS's own internals use for this.
• Thread_Control::cpu_time_used (Timestamp_Control) is int64_t on this build, not struct timespec — its representation is a per-architecture/config choice by design. Switched CPU_ELAPSED_TIME to the portable _Timestamp_Get_as_nanoseconds() accessor instead of assuming tv_sec/tv_nsec.

osdCpuUsage.c now compiles cleanly against this toolchain. Pushed as a follow-up commit.

Separately, I noticed the same kind of RTEMS-Score-API drift also breaks a few other files in this module against this RTEMS 7 build (osdSuspTasks.c: Objects_Locations no longer exists; osdWorkspaceUsage.c: _Workspace_Area undeclared), plus two unrelated failure classes (rtemsReboot implicit declaration, and -Wincompatible-pointer-types on the DSET init macros in devIocStatsAnalog/String/Waveform.c under a stricter modern GCC). Didn't touch any of those here since they're outside this PR's scope — flagging in case they're useful to know about.