search

oxidecomputer / hubris

A lightweight, memory-protected, message-passing kernel for deeply embedded systems.
Mozilla Public License 2.0
3.04k stars 180 forks source link

`hf` should at least respond to inquiries when it's upset #994

Open cbiffle opened 1 year ago

cbiffle commented 1 year ago

Currently, if the hf driver fails to recognize the JEDEC ident info it reads from the QSPI host flash, it does this:

    if log2_capacity.is_none() {
        loop {
            // We are dead now.
            hl::sleep_for(1000);
        }
    }

This means that anyone who attempts to IPC the hf server will just wait forever, which is not great. It would probably be better to have the server come up in a known-degraded state, unable to (say) do programming but willing to respond to status inquiries or re-load the JEDEC info.

mkeeter commented 1 year ago

Also, the hf task always muxes the flash to the SP when the task starts up. @jgallagher points out in #1145 that if the task has died for some reason – but the rest of the system is in A0 – this could steal the flash away from the host!

rmustacc commented 1 year ago

The only time that would be a problem is if we're still booting. In general, once we've booted and told the SP, we expect that the mux will be returned to the hf task.

nathanaelhuffman commented 1 year ago

just to link this: https://github.com/oxidecomputer/hubris/issues/1172 this is the issue about expected muxing away

cbiffle commented 1 year ago

Also, the hf task always muxes the flash to the SP when the task starts up. @jgallagher points out in #1145 that if the task has died for some reason – but the rest of the system is in A0 – this could steal the flash away from the host!

Since the mux state is maintained by a GPIO, it should be straightforward to make hf respect its current state on task restart.