If it is related to Ethernet, maybe the ethtool (also available on BSP 2.8) is a better tool to perform such readings.
The devmem2 is a simplistic wrapper around /dev/mem. And the error that you are facing (I tested and also faced the same) is a processor fault (BUS ERROR).
For me, there is a little more information:
root@colibri-vf:~# devmem2 0x400d0024
/dev/[ 5058.214939] Unhandled fault: external abort on non-linefetch (0x1008) at 0x76f17024
mem opened.[ 5058.244622] pgd = 8d2a4000
[ 5058.257857] [76f17024] *pgd=8d2b8831, *pte=400d0303, *ppte=400d0a33
Memory mapped at address 0x76f17000.
Bus error (core dumped)
root@colibri-vf:~#
Those pte, ppte and pgd are messages directly from the kernel: Page Table Management
So, other tools similar to devmem2 would probably raise the same error.
Another possibility for the failure is that the ethernet driver grabbed the addresses and /dev/mem is not able to access it.
We want to perform deeper optimization of power consumption. The idea is to start by checking if all unused parts of SoC are off at registers level: like 0x400d0024 - there’s a clock disable bit for Ethernet submodule there
Since ethernet is not enabled in DT, perhaps it stays gated (see CCM CCG), which may explain why you get bus error. It must be ungated to allow register access