On 7/18/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> On 18.07.2007 03:05, Peter Stuge 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
* Peter Stuge <[EMAIL PROTECTED]> [070718 17:32]:
> > Using ACPI here would be nicely transparent though, hiding firmware
> > specifics in the firmware code. I like that approach.
>
> We want to use less ACPI, not more, right?
Not sure. I think the use of ACPI as to and will greatly increase in t
ron minnich wrote:
> On 7/17/07, Corey Osgood <[EMAIL PROTECTED]> wrote:
>> Peter Stuge 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
On Wed, Jul 18, 2007 at 01:15:50PM +0200, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [070718 12:43]:
> > Hm. Can we abuse ACPI to do that? Like accessing SystemCMOS from a
> > _INI function?
>
> Possibly. But ACPI is running very early in the game. Where would we
> hook
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 destroy
On 18.07.2007 13:15, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [070718 12:43]:
>> Hm. Can we abuse ACPI to do that? Like accessing SystemCMOS from a
>> _INI function?
>
> Possibly. But ACPI is running very early in the game. Where would we
> hook it up?
>
> This would
* Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [070718 12:43]:
> Hm. Can we abuse ACPI to do that? Like accessing SystemCMOS from a
> _INI function?
Possibly. But ACPI is running very early in the game. Where would we
hook it up?
This would also establish ACPI as a pretty hard requirement. There
sh
On 18.07.2007 11:27, Stefan Reinauer wrote:
> * Peter Stuge <[EMAIL PROTECTED]> [070718 03:05]:
>>> But since many payloads don't do this correctly, should this be a
>>> config option?
>> Not payload, the OS. Maybe even the application. I say teach lxbios
>> how to set the completed flag if it does
* Corey Osgood <[EMAIL PROTECTED]> [070718 05:06]:
> Peter Stuge 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
This wont
* Peter Stuge <[EMAIL PROTECTED]> [070718 03:05]:
> > But since many payloads don't do this correctly, should this be a
> > config option?
>
> Not payload, the OS. Maybe even the application. I say teach lxbios
> how to set the completed flag if it doesn't already know and move the
> problem to wh
On 18.07.2007 03:05, Peter Stuge 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.
What about writing to flash instead? IIRC some factory BIOSes
On 7/17/07, Corey Osgood <[EMAIL PROTECTED]> wrote:
> Peter Stuge 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.
> >
> >
> > //Peter
>
Peter Stuge 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.
>
>
> //Peter
>
>
Agreed
-Corey
--
linuxbios mailing list
linuxbios@linuxbios
On Wed, Jul 18, 2007 at 01:35:49AM +0200, Stefan Reinauer wrote:
> > linuxbios can CLEAR the boot normal, but the only thing that
> > should set it is a payload. This is very conservative behaviour,
> > but I think it's correct.
>
> It definitely is, since linuxbios itself has no shell or other
>
* ron minnich <[EMAIL PROTECTED]> [070718 01:16]:
> So, at this point, I'd argue that linuxbios can CLEAR the boot normal,
> but the only thing that should set it is a payload. This is very
> conservative behaviour, but I think it's correct.
It definitely is, since linuxbios itself has no shell or
I think the key thing that v2 missed was in letting linuxbios set the
'boot success' flag. That flag should only be set by a payload or even
linux. It's not really useful to know that linuxbios came up. What
matters is that the payload came up. It was a big headache to me, esp.
on 1000 nodes, when
* Marc Jones <[EMAIL PROTECTED]> [070718 00:20]:
>
> Also, the boot count needs to be cleared at the end of LinuxBIOS. I
> think that this what the last boot flag was trying to do.
with v3 we can potentially have n:m mappings for all modules. is a
single byte like we have it in v2 still appropri
Marc Jones wrote:
> How should this work in V3? The current implementation doesn't really
> make sense to me. See do_normal_boot() in V2.
>
> I think that stage0+1 is the equivalent of V2 failover.
> In stage1 the normal boot flag cmos byte is checked to see if the normal
> or the fallback ima
How should this work in V3? The current implementation doesn't really
make sense to me. See do_normal_boot() in V2.
I think that stage0+1 is the equivalent of V2 failover.
In stage1 the normal boot flag cmos byte is checked to see if the normal
or the fallback image should be loaded.
The cmos b
19 matches
Mail list logo
