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_150616

 > +    "\nDetermining DDR Interleave Bit (Testing bits 6 to %u)...\n",
 > +    max_safe_bit
 > +  );
 > +
 > +  for ( uint8_t bit = 6; bit <= max_safe_bit; bit++ ) {
 > +    uintptr_t interleave_mask = ( 1ULL << bit );
 > +    uintptr_t target_base = (uintptr_t) ctx->active_config.base_memory_region;
 > +
 > +    volatile uint8_t *addr_a = (volatile uint8_t *) ( target_base &
 > +                                                      ~interleave_mask );
 > +    volatile uint8_t *addr_b = (volatile uint8_t *) ( target_base |
 > +                                                      interleave_mask );
 > +
 > +    uint64_t start_time = rtems_clock_get_uptime_nanoseconds();
 > +
 > +    for ( int i = 0; i < 5000; i++ ) {

@gedare 5000 is a magic number I used to ensure enough samples to average out cache and bus noise on my local hardware, but you're right that it shouldn't be hardcoded. Slower architectures or strict boot-time constraints will definitely need to tune this.

I will expose a `calibration_iterations` field in `dhrl_config`. If the caller leaves it zero-initialized, the library will default to 5000.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150616
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/20260520/435804f4/attachment-0001.htm>