Recent searches
Search options
Built a DUMPTRUCK for a friend, flashed it with a fresh build from source... Instant segfault.
After waaay too much time looking for hardware faults I flashed mine with the same build and... Boom segfault.
Still chasing the details and fixes but it appears that my board had been running a build of the bootloader from mid December, compiled against a stm32-cpp that didn't know how to initialize the L1 caches.
And while it initializes and invalidates the caches on startup, something is going haywire if the cache is already active when the main firmware starts. I saw my entire .data returning garbage values (which looked suspiciously like what the bootloader stored at those addresses), corrupted vtables, and more.
@azonenberg ah, the joys of building embedded devices for yourself and friends
@whitequark Looks like a dmb st, isb, and disabling both caches at the end of the bootloader before entry to the application fixes it.
The barriers were important, presumably there was some uncommitted store that would get lost if I just turned the cache off.
Will test more but I think it's good now.