[SeaBIOS] [edk2] [PATCH 0/8] OvmfPkg: reset-related changes

[David Woodhouse]

On Fri, 2013-02-22 at 04:23 +0100, Laszlo Ersek wrote:
> Patches 1 to 6 upgrade the FADT to ACPI 2.0 and present the PIIX3
> Reset Control Register in it.

Hm. I can still trigger the soft reset loop in SeaBIOS, but perhaps not
in a circumstance that we care about...

I've fixed Qemu to do the proper hard reset on 0xcf9 but not any other
reset method. I'm running with KVM on an old machine without
"unrestricted guest" support.

I've fixed SeaBIOS to look for the ACPI RESET_REG and use it, and that
part *works*... but SeaBIOS only *sees* the ACPI table when we boot a
legacy OS. If I boot an EFI OS and then do a soft reset via the keyboard
controller ('echo -en \\xfe | dd of=/dev/port bs=1 seek=$((0x64))'),
SeaBIOS hasn't seen the ACPI tables, still uses the keyboard controller
as its first choice of reset method, and still does its reset loop as
before.

Do we actually *care* about that? Do we expect any EFI OS to be doing a
keyboard reset instead of using ACPI or the runtime services Reset call?

If we've booted a legacy OS, it works fine. SeaBIOS gets invoked at
0xffff0 after a soft reset, uses the ACPI RESET_REG that it was given by
OVMF, and does a proper reset...

# echo -en \\xfe | dd of=/dev/port bs=1 seek=$((0x64))
Changing serial settings was 0/0 now 3/0
In resume (status=0)
In 32bit resume
Attempting a hard reboot
Using ACPI reset reg
rcr_write 6 (debug from qemu)
SecCoreStartupWithStack(0xFFFE6000, 0x80000)
File->Type: 0xB
...

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://www.seabios.org/pipermail/seabios/attachments/20130222/8216ff17/attachment.bin>