RTEMS | cpukit: Create DHRL Library for DRAM Latency Mitigation (!1193)

[Wayne Thornton (@wmthornton-dev)]

Wayne Thornton commented on a discussion on cpukit/dhrl/dhrl.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150865

 > +  best_bit = 6;
 > +  lowest_latency = UINT64_MAX;
 > +  max_safe_bit = 0;
 > +  safe_size = ctx->active_config.memory_region_size / 2;
 > +
 > +  if ( safe_size > 1 ) {
 > +    max_safe_bit = (uint8_t) ( ( sizeof( unsigned long long ) * 8 - 1 ) -
 > +                               __builtin_clzll(
 > +                                 (unsigned long long) safe_size
 > +                               ) );
 > +  }
 > +
 > +  rtems_dhrl_debug_printk(
 > +    "\nDetermining DDR Interleave Bit (Testing bits 6 to %u)...\n",
 > +    max_safe_bit
 > +  );

While it's true that the debug macro is only used in this one function, I'd strongly prefer to keep it. Because `rtems_dhrl_calibrate_interleave` is empirically determining the memory topology at runtime, these debug prints are the only way an application developer can peek into that black box and see which hardware routing bit was actually selected. This is particularly useful if they want to run the calibration once during testing, read the output, and then hardcode that specific `interleave_bit` into their `rtems_dhrl_config` to save boot time later. Since it evaluates to a `no-op` when the debug flag is disabled, it shouldn't add any complexity to the final executable

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150865
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/20260522/15f7a048/attachment-0001.htm>