Possible issue with interrupts enabled when shouldn’t be during early boot

Looking in HAL.Top, (on IOMD 5.29), interrupts are switched off almost immediately, and the code commenting looks like there is a story behind that! :)

Anyway, during the very early boot of the HAL / Kernel, once we get into Kernel.HAL, there is a ‘DebugTX “IICInit” followed by ‘BL IICInit’;

Immediately after that is BLEQ ClearWkspRAM;

ClearWkspRAM commences with MSR CPSR_c, #F32_bit+FIQ32_mode, prepares the FIQ registers for later use, then does an ‘MSR CPSR_c, #F32_bit+SVC32_mode’ to go back to SVC mode.

It definitely stays in ‘IRQs on, FIQs off mode’ for many instructions afterwards, maybe as many as 2 million instructions (which is around the point on a 32MB IOMD system that the IRQs are ‘officially’ turned on (the ‘IRQs On’ DebugTx message);

It is a minor thing, there is probably an MSR my single-stepper is missing, but the IRQs are left on for a while before they are ‘officially’ enabled.

Should we add an IRQ disable bit to those instructions? Given this is in the Kernel.HAL code, it is probably in all distributions, and might cause very occasional issues during boot if an IRQ manages to get through somehow, before it is meant to?

Hope this makes sense!

If this is an issue, then the same things happens a few more times in the early bootstrap sequence;

- firstly, a few lines down in ClearWkspaceRAM,

Then in Kernel.HAL, just before BL ConstructCAMfromPageTables;

The FIQs do go on briefly once or twice too, before IRQs are officially enabled.

However, changing those MSRs I mentioned above means IRQs stay off all the way until they are officially enabled, so it does seem like they are meant to be off. I will look at FIQs shortly :)