RFE: Give Recovery Menu an exclusive mode when accessed while holding RTRIGGER during power-on

[GoogleCodeExporter]

I understand that PRO's Recovery Menu is unlike any other CFW that I have come 
across upon, where it is running on top of the XMB shell like any VSH plugin. 
This is also true when acessing the Menu while holding RTRIGGER during power-on.

The problem with this approach, however, is that when another VSH plugin 
misbehaves, then it can effectively crash the Recovery Menu as well and stop 
working. This is because the PSP, even though inside the Recovery Menu that has 
been accessed during system boot-up, is still loading VSH plugins in the 
background. (I know this because I have PSP-Hud set to load in VSH. Lo and 
behold it shows up on the screen). Thus, the purpose of having a recovery mode 
is defeated.

This problem is exemplified while testing plugins, enabling each one-by-one and 
see what works. This happened during my brief stay in 6.60 with PRO NIGHTLY. I 
was testing plugins when one plugin, Dayviewer v7 by neur0n, misbehaved and 
crashed the PSP during boot-up. I went into the Recovery Menu but unfortunately 
after a brief display of its menu items, it stopped working before I even got 
the chance to turn off the plugin.

Fortunately, I was able to reboot back into OFW mode, and load LME to disable 
the plugin from there. It wouldn't be too hard to imagine a situation involving 
a PSP Go ending in lock-up when one plugin in its internal storage misbehaves, 
and having PRO's Recovery Menu behave erratically because of said plugin.

Because of this, I would think that having a Recovery Menu running in exclusive 
mode (i.e. when accessed during system boot-up) WITHOUT any other plugins 
running in the background, should make for a nice lifeline while 
troubleshooting a misbehaving PSP.

Original issue reported on code.google.com by c0d3r5unltd@gmail.com on 4 Sep 2011 at 11:10

[GoogleCodeExporter]

I second this enhancement idea, as this exact sequence (with different plugins, 
mind you) affected me also.  I think this is a great idea.  With LCFW it may 
not be possible to make it like a true recovery, but you could add a section to 
bypass the loading of plugins when it is R held upon boot.  This right here is 
genius :)

Original comment by PhatMari...@gmail.com on 4 Sep 2011 at 10:32

[GoogleCodeExporter]

I should point out that this RFE is only meaningful for permanent CFWs (those 
with CIPLs, not sure about 6.20PRO-B with a permanent bootloader though).

In general, anything that prevents loading the XMB during boot-up, a problem 
that is not limited to misbehaving plugins alone, could in theory (and 
practice) affect a Recovery Menu that behaves like a VSH plugin among other 
plugins. I have put in practice this theory as aforementioned on a 6.60 PRO 
NIGHTLY, running on a PSP 2000 with CIPL, during plugins testing.

Of course it only takes taking out the MS in the case of a VSH plugin 
preventing normal boot-up, but for other problems that prevent the XMB from 
loading, a reliable recovery mode is nice to have.

Original comment by c0d3r5unltd@gmail.com on 5 Sep 2011 at 12:42

[GoogleCodeExporter]

I think it would be very simple to do blacklist for some plugins.

Original comment by realyoti on 5 Sep 2011 at 9:01

[GoogleCodeExporter]

I just think adding some code to the beginning of the Recovery menu, like after 
the check for whether a user is holding R on boot up, cancel all of the plugins 
from loading, I don't think that would be too difficult :)

Original comment by PhatMari...@gmail.com on 7 Sep 2011 at 3:39

[GoogleCodeExporter]

Taking a second look at a permanent CFW via a custom bootloader (a.k.a. perma 
patch), it seems that they too will benefit on this enhancement as well.

I gave rev. fa11d093db15 a try, and the implementation for this RFE is superb, 
just like back in the M33 days, only better. :)

Original comment by c0d3r5unltd@gmail.com on 8 Sep 2011 at 3:35

[GoogleCodeExporter]

Original comment by devnonam...@gmail.com on 15 Jun 2012 at 3:49

• Changed state: Done

[GoogleCodeExporter]

Issue 304 has been merged into this issue.

Original comment by devnonam...@gmail.com on 15 Jun 2012 at 4:31