Hi,
On Wed, 30 Jan 2019 at 12:03, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 1/30/19 11:46 AM, Alexander Graf wrote:
Our selftest will soon test the actual runtime reset function rather than the boot time one. For this, we need to ensure that the runtime version actually succeeds on x86 to keep our travis tests work.
So this patch implements an x86 runtime reset function. It is missing shutdown functionality today, but OSs usually implement that via ACPI and this function does more than the stub from before, so it's at least an improvement.
Eventually we will want to have full DM functionality in runtime services. But this fixes a travis failure and doesn't clutter the code too heavily, so we should pull it in without the amazing new RTS DM framework.
Signed-off-by: Alexander Graf agraf@suse.de
v2 -> v3:
- support EFI_RESET_PLATFORM_SPECIFIC
- reuse existing x86_sysreset_request() function
The v2->v3 update does not answer the question if the reset is correctly implemented. We would not want to call a function we do not trust.
@Simon, Bin: x86_sysreset_request() loosely resembles BOOT_CF9_SAFE in native_machine_emergency_restart() in Linux arch/x86/kernel/reboot.c which is tried before using the keyboard controller as last resort.
u8 reboot_code = reboot_mode == REBOOT_WARM ? 0x06 : 0x0E; u8 cf9 = inb(0xcf9) & ~reboot_code; outb(cf9|2, 0xcf9); /* Request hard reset */ udelay(50); /* Actually do the reset */ outb(cf9|reboot_code, 0xcf9); udelay(50);
So the Kernel first switches bit 2 off and bit 1 on, waits, and then switches bit 2 on, cf. http://smackerelofopinion.blogspot.com/2011/02/resetting-pc-using-reset-cont...
Shouldn't we do it the same way as the Kernel does it?
I suspect so, but Bin is the expert.
As to this patch, it perpetuates the current EFI run-time approach in U-Boot so I'm not sure this is the right path.
Regards, Simon