[coreboot] [PATCH] fix normal vs. fallback

[Stefan Reinauer]

 On 7/9/10 6:01 PM, Myles Watson wrote:
> On Fri, Jul 9, 2010 at 9:55 AM, Stefan Reinauer
> <stefan.reinauer at coresystems.de> wrote:
>>  On 7/9/10 3:36 PM, Myles Watson wrote:
>>> On Fri, Jul 9, 2010 at 7:10 AM, Peter Stuge <peter at stuge.se> wrote:
>>>> Stefan Reinauer wrote:
>>>>> Even though the normal/fallback mechanism uses CMOS, it does not
>>>>> require an option table.
>>>>> Are there advantages in changing this?
>>>> One advantage would be that any use of NVRAM always implies having an
>>>> option table, which I think makes sense. Somewhere it needs to be
>>>> specified what bit(s) the mechanism uses, better in an option table
>>>> than hardcoded IMO.
>>> That was my thought.  It should be obvious when we're using/corrupting
>>> values, to minimize surprises.
>> the normal/fallback selection and the cmos settings are living in
>> completely distinct spaces. normal/fallback is not covered by the
>> checksum.
> Yes.  It could still corrupt values used by the factory BIOS if you're
> trying to have them coexist.  For testing, it can be nice to not have
> to do BIOS setup every time you boot the factory BIOS.

0. Maybe we should hard code the Normal / Fallback ("BOOT_BYTE") into
the cmos.layout parser tool so anyone who tries to use that byte gets a
decent error.

1. Should Fallback always ignore CMOS? I think it would make more sense
if Normal and Fallback were the same and both would write a decent set
of CMOS defaults in the case of a bad checksum.

2. Ok, so what should happen when bad settings are detected?
2.1 Go back to fallback (the same path like when the normal rom image is
corrupted)?
2.1.1 leave BOOT_BYTE alone ...?
2.1.2 dump a set of cmos default values
2.2 Stay in Normal
2.2.1 leave BOOT_BYTE alone ...?
2.2.2 dump a set of cmos default values

3. Do we want an extra "checksum" for BOOT_BYTE?

Stefan