Your timezone:
Friday, 16 May 10:10 - 10:35
(Europe/Lisbon)
Session Room 1 | Esmeralda I & II
Kernel debug mechanisms are traditionally reliant on a software handler, that can inspect or help inspecting a faulting kernel. It could be it a panic trigger or a specific event, the ability to start a failsafe kernel, or a working userspace. An embedded system has many more possible fault causes, including, but not limited to : software hang-up, watchdog trigger, firmware crashes, or simply a very nasty case of corruption. How would it be possible to still get reliable information from the kernel, once such an event occurs, considering the system cannot run any kind of instruction, be it a kernel panic handler or a working userspace, nor could not startup a recovery kernel ? In this session we can see a way to prepare the system ahead of time for such a cataclysmic event ! If the data we need is already marked as vital, mapped into a list, then the debugger, permanent storage, or remote processor already knows where to look, and what to expect. There wouldn't be any need for a software handler, rather just tap into the faulty system directly.
