On Thu, Jan 31, 2019 at 9:24 AM Simon Glass sjg@chromium.org wrote:
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.
What U-Boot does is essentially the same as Linux but a simplified version, because bit 2 is 0 any way. If it were 0, the system should have been reset already then there is no chance to execute the reset sequence at all.
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, Bin