On Wed, Jul 18, 2007 at 09:17:14AM +0200, Carl-Daniel Hailfinger wrote:
What about writing to flash instead?
Yes, that is definately where I want to go evetually.
But, for the last_boot_normal this one bit toggles on every boot, assuming one reboot per second a 100k writes flash chip is destroyed in about one day. :( Perhaps a clever algorithm can fix that by using a full 4k page rather than a single bit.
On Tue, Jul 17, 2007 at 08:16:34PM -0700, ron minnich wrote:
Also re CMOS checksum, I would like if LB could avoid clobbering the CMOS, for when switching back and forth with another BIOS.
Writing LB CMOS bytes would be done after the final switch.
Agreed
So I guess the original logic is right.
- CMOS csum bad? fallback boot
- last boot normal not set? fallback boot
Yep:
if checksumok and last_boot_normal: clear last_boot_normal boot normal else: boot fallback
but we still need the ability to clear one bit, so we can drop to fallback. That bit is the 'last boot normal' bit. We can't get away from clearing one bit. But we can avoid messing with cmos otherwise.
As long as LB checksum does not collide with the factory checksum this will just work<tm> because the checksum is always "bad" until lxbios has been run. This is exactly what I would like.
LB can complain quite loudly that the CMOS is bad and that it should be upgraded with lxbios in order to actually do a normal boot, but I think having this backwards compatibility is really important.
On Wed, Jul 18, 2007 at 11:30:09AM +0200, Stefan Reinauer wrote:
Writing LB CMOS bytes would be done after the final switch.
Agreed
This wont work, or it will render lots of features unusable. LinuxBIOS relies on having the cmos available for its settings. Fallback does not use any CMOS settings though.
That's fine. Until the CMOS has been LB:ified the best you'll get is fallback. I think this is a great deal if we can make sure that LB never clobbers the CMOS until after lxbios has been run.
(Does it erase the CMOS anyways? If so, this should probably be fixed)
All I can say for sure is that LB does change CMOS bytes even if lxbios has not been run. :)
Instead, if you switch between flash contents, switch between cmos contents, too by using lxbios (now in the tree)
Yes, good point. But I will forget to do it, and others may not want to do it. I think it would be very nice to not have this requirement.
On Wed, Jul 18, 2007 at 11:27:43AM +0200, Stefan Reinauer wrote:
Yes, the OS should set it. So we should add an option to lxbios lxbios --set-boot-complete or something.
Yes! Perfect.
lxbios can back up the cmos for you. So when you call flashrom, you should also call lxbios to put the cmos values for your bios in place.
It would be nice if flashrom could call lxbios externally to automatically do that, or to have a wrapper script.
I thought about that too. Perhaps store original CMOS in the lar?
One of my customers uses 2 small scripts
switch_to_linuxbios.sh switch_to_legacybios.sh
that flash a fiven bios image and write the according cmos contents to it.
But that doesn't make much sense when we already have these nice tools. Something is wrong if the tools aren't enough to do a good job IMHO.
Writing LB CMOS bytes would be done after the final switch.
Final switch?
Ah, sorry, should have been more clear.
I think it will be common for people to switch back and forth between LB and the factory BIOS when first getting started with LB. Present situation is that LB writes to CMOS and on next factory BIOS boot there's a checksum error, and some or all of the factory BIOS settings may have been lost.
I wanted to avoid this by making LB completely unobtrusive if the CMOS has not been prepared by the user in advance. Running in fallback-only is a fair price to pay for that I think.
Once the user has switched to LB the last time (final switch) she then runs lxbios in order to LB:ify the CMOS contents.
//Peter