On 7/9/10 6:01 PM, Myles Watson wrote:
On Fri, Jul 9, 2010 at 9:55 AM, Stefan Reinauer stefan.reinauer@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@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