Add more recovery_reason codes

There are several places where the same recovery_reason was used to report
slightly different points of failure. Let's create some new codes instead.

Remember that recovery mode is handled by RO firmware, so if an updated RW
firmware uses one of the new error codes, pressing TAB at the recovery
screen will say "We have no idea what this means". That's not a bug. This CL
deprecates the original codes, so the fact that the RO firmware doesn't
recognize it just means it's a new code reported by a new RW BIOS.

BUG=chromium-os:36562
TEST=manual
BRANCH=parrot

Run

  make && make runtests

It should pass. You can test some of the error cases on actual hardware by
using

  crossystem recovery_reason=86
  reboot

and pressing TAB at the recovery screen. For that example you should see the
message

  recovery_reason: 0x56 TPM lock error in rewritable firmare

Change-Id: I123c781e6c6f6fe0284c4fd49f5f5a855eece7df
Reviewed-on: https://gerrit.chromium.org/gerrit/38652
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>

1 files changed, 1 insertions, 1 deletions

diff --git a/firmware/lib/cgptlib/cgptlib.c b/firmware/lib/cgptlib/cgptlib.c
index e708b7bc..c3f37442 100644
--- a/firmware/lib/cgptlib/cgptlib.c
+++ b/firmware/lib/cgptlib/cgptlib.c
@@ -89,7 +89,7 @@ int GptNextKernelEntry(GptData* gpt, uint64_t* start_sector, uint64_t* size) {
     return GPT_ERROR_NO_VALID_KERNEL;
   }
 
-  VBDEBUG(("GptNextKernelEntry likes that one\n"));
+  VBDEBUG(("GptNextKernelEntry likes partition %d\n", new_kernel+1));
   e = entries + new_kernel;
   *start_sector = e->starting_lba;
   *size = e->ending_lba - e->starting_lba + 1;