Infinite loop on "Can't boot: No valid keys!"

[msuiche]

https://github.com/betrusted-io/xous-core/blob/5c155587b65c3e1a1b5b12c2dfe501e1f1836dd6/loader/src/secboot.rs#L351

When the above loop is hit, how does one restart the phone?

[bunnie]

This is the state where you've provisioned the root keys, but it's stuck trying to find a signed image?

Can you try one thing -- use a paperclip to hit the button inside the hole on the lower right hand side of your device.

It's possible that the FPGA didn't pick up the new root keys and so there's a mismatch between what's in the SoC and what's on the disk.

Failing that, then you'd need to do a factory reset to clear the SoC back to its default of looking for developer signed keys, or you need to upload a correctly dev-key signed image so it can recognize that (depending upon what the root cause is). For example, it's possible that in fact the xous.img file is actually damaged, in which case, that would need to be repaired before you can boot, and that can be done by just uploading a working xous.img.

[blakesmith]

I got stuck in this state as well. Steps that got me stuck here:

1. With a fully booted Precursor, I went to "Initialize Root Keys"
2. I accidentally pressed "enter" twice for each of the password prompts (I got confused by the 3-button dialogs that wanted me to pick my password hide mode), presumably setting 'blank' passwords for both keys.
3. Everything signed to completion.
4. Upon reboot, I got the "Can't boot: No valid keys!"

I tried to reproduce again, from a factory reset state, but was unsuccessful.

To get out of this state:

1. I used the "factory_reset.sh" script, and reflashed all the gateware / firmware (not sure if this helped anything). The screen stayed frozen with "Can't boot: No valid keys!" throughout the flash process.
2. Hit the paperclip reset button on the side, and Xous came back up with the initial developer keys again.

[mguthaus]

Mine did this after I had initialized the root keys and did an update. It was fine after the paperclip.

[bunnie]

Alright, it sounds like the gateware isn't automatically being reloaded properly. The device is supposed to reset itself, but it has to do a "cold" boot to pick up the latest gateware -- this could be hampered if the device is plugged into USB when that happens. If you're plugged into USB the best the device can do is a warm boot, unless you use the paperclip.

[bunnie]

I think this issue is basically resolved with the paperclip, but leaving it open until the first tranche of users receive their device and get stuck on this.

[uhtu]

just encountered this updating via update_ci.sh, happily this was the first hit for "precursor can't boot no valid keys" and post-paperclip, the device boots

[bunnie]

I think maybe 811bd8811138f015d65516c95e4ecd93a8fce809 may help to resolve this. The reboot timing was a bit too fast, so I think the reboot signal was catching before the power actually fully discharged. Either way, the fix is to use the paperclip, but hopefully this error is more rare after this fix (which will go live in 0.9.9)