On Friday, 12 May 2023 01:23:14 CEST Paul Boddie wrote:
All of this gets the kernel started in various ways, as I previously achieved, but it still doesn't manage to complete its initialisation and still appears to hang in vprintf, so there is something else amiss.
Well, I can't figure this out at all. Debugging when the UART isn't even set up in the kernel is very difficult, but I managed to get the on-board LEDs to suggest that the failure has an exception code of 5, related to a store operation that is either in unmapped memory or is misaligned.
Tedious exercises trying to extract the failure address or instruction haven't been informative. I tried with limited success to call the bootstrap code's write function for UART output, which required manually setting up the t9 register, but I don't think this can be relied upon.
I would potentially try and revert the sources in Git to something approximating to the r83 version from Subversion, but everything is now a collection of repositories, and I don't see any obvious way of using the Ham tool to perform such an operation. It is also difficult to know what the repositories would be reverted to, especially given the way the history appears to integrate commits from all sorts of dates, not necessarily in chronological order.
Since I've been using QEMU to emulate the MIPS Malta board, it is odd that I don't see problems running the software under emulation, but I am admittedly not using precisely the same repository versions. Maybe the arguably incorrect bootstrap initialisation is somehow forgiven by the Malta emulation but not the CI20 hardware.
What should have been a simple rebasing of a few patches, with some even eliminated due to the integration of various changes (including some I suggested several years ago), seems to have turned into a futile exercise with really no obvious indication as to why the code no longer works. To be honest, it is all rather frustrating and disappointing, but such is the way of the world, I guess.
Paul