[U-Boot] [PATCH v3 1/2] x86: Add efi runtime reset
Bin Meng
bmeng.cn at gmail.com
Thu Jan 31 13:03:55 UTC 2019
On Thu, Jan 31, 2019 at 7:38 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 1/31/19 8:31 AM, Bin Meng wrote:
> > On Thu, Jan 31, 2019 at 3:30 PM Bin Meng <bmeng.cn at gmail.com> wrote:
> >>
> >> On Thu, Jan 31, 2019 at 9:24 AM Simon Glass <sjg at chromium.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Wed, 30 Jan 2019 at 12:03, Heinrich Schuchardt <xypron.glpk at 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 at 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-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?
>
This is not a sticky bit so it is reset to default 0 after power up.
Regards,
Bin
More information about the U-Boot
mailing list