paulk-collins patrickg, hi there, I've investigated a bit why my coreboot build on veyron_speedy fails at run time paulk-collins with gcc 5.2.0 paulk-collins the function that makes it crash is elog_add_watchdog_reset paulk-collins patrickg, here is the assembly with gcc 4.9: http://gagarine.paulk.fr/collins/~paulk/coreboot/watchdog-4.9.txt paulk-collins and with 5.2: http://gagarine.paulk.fr/collins/~paulk/coreboot/watchdog-5.2.txt paulk-collins it looks pretty obvious that it's doing some strange stuff at write32 with 5.2 nico_h looks really strange but still seems to do write32(*r4, 0) cbzx (~cbzx@CPE0015f275ebd6-CM00195edd810c.cpe.net.cable.rogers.com) a rejoint #coreboot nico_h ahem, I'm not sure how to read the dump, but: PC = 0x00200116 vs. 00200204 : 23cbzx ( 23~cbzx@CPE0015f275ebd6-CM00195edd810c.cpe.net.cable.rogers.com) a quitt #coreboot cbzx (~cbzx@CPE0015f275ebd6-CM00195edd810c.cpe.net.cable.rogers.com) a rejoint #coreboot nico_h or is the `PC = ` line the PC of the exception handler? nico_h paulk-collins: ^ paulk-collins nico_h, PC seems irrelevant here paulk-collins I wonder why paulk-collins it's not the exception handler either paulk-collins it's just a bit earlier in the code paulk-collins nico_h, well, my ASM is not that good, so perhaps it's doing the right thing in a rather offuscated way on 5.2 paulk-collins I'll comment out the write32 instruction and see paulk-collins (gcc 5.2.0 rebuilding now) patrickg paulk-collins: it's a byte-wise store. some registers don't like that paulk-collins oh paulk-collins why is it doing that anyway, isn't ARMv7 32-bit word? patrickg hm. maybe to mitigate unaligned accesses (which arm may or may not handle properly) paulk-collins ok, perhaps patrickg and I think that data_abort is a possible outcome of either, unaligned accesses on CPUs not configured to deal with them and the wrong kind of access to registers paulk-collins so if that turns out the be the problem, what can we do about it? patrickg that write ends up writing to _watchdog_tombstone, which is declared in src/soc/rockchip/rk3288/include/soc/memlayout.ld patrickg comment: "Careful: only supports 32-bit wide write accesses!" paulk-collins right nico_h fix write32, do it in assembly paulk-collins patrickg, haha, good spotting paulk-collins so yeah, looks like it mrnuke_i_ huh? compiler turns voulatile uint32_t* dereference into byte-stores? patrickg mrnuke_i_: welcome to the wonderful world of weird memory access modes mrnuke_i_ Well, C11 doesn't specify how the volatile types should be accesed, oinly that they can't be cached or saved in registers mrnuke_i_ but still, I have to say it: mrnuke_i_ WTF! patrickg too many words: C11 doesn't specify. patrickg that's more than enough to explain the state of C mrnuke_i_ C is still more portable than Java or objectiveC patrickg I know a low bar when I see it nico_h I wonder what GCC 5.2.0 would do to my SPARK code when compiling for ARMv7... mrnuke_i_ patrickg: I don't see the bar. I just trip on it patrickg hm. let's see