From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heinrich Schuchardt Date: Thu, 31 Jan 2019 12:38:34 +0100 Subject: [U-Boot] [PATCH v3 1/2] x86: Add efi runtime reset In-Reply-To: References: <20190130104635.41372-1-agraf@suse.de> <20190130104635.41372-2-agraf@suse.de> <1c09e323-5980-47c3-0576-a05baaa5024b@gmx.de> Message-ID: <134d40f1-b2fe-a3fe-8420-e0e8410193e9@gmx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 1/31/19 8:31 AM, Bin Meng wrote: > On Thu, Jan 31, 2019 at 3:30 PM Bin Meng wrote: >> >> On Thu, Jan 31, 2019 at 9:24 AM Simon Glass wrote: >>> >>> Hi, >>> >>> On Wed, 30 Jan 2019 at 12:03, Heinrich Schuchardt 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 >>>>> >>>>> --- >>>>> >>>>> 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-control.html >>>> >>>> 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 > > Sorry, a typo: If it were "1" What happens if we reset a board multiple times? Best regards Heinrich > >> 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 >