Hangs during OMAP ROM reset/poweroff

I’m not quite sure when this bug appeared, but while testing my HAL USB stuff I noticed that my touchbook would hang during the pre-reset/power off sequence (i.e. inbetween Service_PreReset starting and HAL_Reset being called). For a while I was also able to reproduce the issue on one of my beagleboards, but then it later vanished, since it’s a timing specific issue. Anyway, what’s happening is the following:

• The OS starts issuing Service_PreReset
• DMAManager receives the service call and resets the DMA controller
• Something somewhere enables interrupts for a short while. I think this might be the USB drivers.
• The DMA reset would have caused the audio hardware to stop receiving data. If the period between DMA being reset and interrupts being enabled is long enough, the audio hardware will be starved of data and trigger an interrupt. SoundDMA then responds to this interrupt, gets told by the HAL that something’s gone wrong, and sets a callback to reinitialise the sound system (which is the only sure-fire way of recovering from audio DMA underruns on OMAP)
• Something (I’m guessing the USB drivers again!) allows that callback to be triggered.
• SoundDMA then runs through its shutdown/restart sequence, until it gets stuck in a section of HAL code that waits for the audio FIFO to be filled by the DMA controller. Except that the DMA reset seems to have screwed something up in either the HAL or DMAManager, so the DMA isn’t actually running, and the FIFO will never fill.

Looking at the above list, I can see several issues contributing to the bug:

• The code in the HAL which waits for the FIFO to fill doesn’t have a timeout. That’s something I can fix quite easily.
• The USB drivers enable interrupts during Service_PreReset, even though the OS has gone out of its way to disable both IRQs and FIQs. Plus they trigger callbacks. (Admittedly I’m not 100% sure it’s the USB drivers that are at fault here, but I’m fairly certain it was them who were causing issues the last time I had pre-reset problems)
• DMAManager resets the HAL devices without telling any of its clients that existing transfers have been paused/cancelled.
• Also my HALified version of SoundDMA doesn’t pay attention to Service_PreReset (although even if it did respond to that service call and use it to stop audio playback – or at least to stop paying attention to the DMA underrun errors – there’s no guarantee that SoundDMA would receive the service call before DMAManager & the USB modules have screwed everything up)

There’s also the issue that our pre-reset sequence isn’t as friendly as it probably could/should be. It would be nice if Ctrl-Break could follow a shutdown sequence similar to the shutdown sequence that the Wimp follows – closing files, dismounting discs, etc. But that might be something that’s at odds with the philosophy of Ctrl-Break – it seems like something you should only be using once the machine’s already crashed, so if it tried to be too friendly then there’s a chance that it would hit some corrupted code/memory and never succeed.

There’s still some bits of this that I’ll be investigating myself, but if anyone has any thoughts on how to improve the pre-reset sequence then please share them. With any luck the improvements made here will also help make Iyonix resets a bit more reliable (although I’ll admit that I’m still using OS 5.12!)

Tut, tut, naughty USB drivers…

[ctrl-break] so if it tried to be too friendly then there’s a chance that it would hit some corrupted code/memory and never succeed.

I take it the BB and similar (or the OMAP itself) doesn’t have a hardware watchdog feature we could use as a last resort?

Yes, there’s a watchdog timer which can be used to reset the OMAP. I haven’t tried it yet, but I guess it would be functionally identical to the reset that the HAL performs.

Anyway, adding a timeout to the audio code seems to do the trick, so for now that fix will do.

Yep, my watchdog suggestion clearly wasn’t a suggested solution but a nice-to-have for RISC OS (debatable?).