| Message ID | 20190130104635.41372-2-agraf@suse.de |
|---|---|
| State | Accepted, archived |
| Commit | 3eeb09b4c06fd6eb5c724b21cd2ac538fc015a31 |
| Delegated to: | Heinrich Schuchardt |
| Headers | show |
| Series | efi_loader: Patch RTS at ExitBootServices | expand |
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-control.html Shouldn't we do it the same way as the Kernel does it? Best regards Heinrich > --- > drivers/sysreset/sysreset_x86.c | 23 ++++++++++++++++++++++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c > index 20b958cfd4..009f376602 100644 > --- a/drivers/sysreset/sysreset_x86.c > +++ b/drivers/sysreset/sysreset_x86.c > @@ -10,8 +10,10 @@ > #include <sysreset.h> > #include <asm/io.h> > #include <asm/processor.h> > +#include <efi_loader.h> > > -static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type) > +static __efi_runtime int x86_sysreset_request(struct udevice *dev, > + enum sysreset_t type) > { > int value; > > @@ -31,6 +33,25 @@ static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type) > return -EINPROGRESS; > } > > +#ifdef CONFIG_EFI_LOADER > +void __efi_runtime EFIAPI efi_reset_system( > + enum efi_reset_type reset_type, > + efi_status_t reset_status, > + unsigned long data_size, void *reset_data) > +{ > + if (reset_type == EFI_RESET_COLD || > + reset_type == EFI_RESET_PLATFORM_SPECIFIC) > + x86_sysreset_request(NULL, SYSRESET_COLD); > + else if (reset_type == EFI_RESET_WARM) > + x86_sysreset_request(NULL, SYSRESET_WARM); > + > + /* TODO EFI_RESET_SHUTDOWN */ > + > + while (1) { } > +} > +#endif > + > + > static const struct udevice_id x86_sysreset_ids[] = { > { .compatible = "x86,reset" }, > { } >
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-control.html > > 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
> Am 31.01.2019 um 02:24 schrieb Simon Glass <sjg@chromium.org>: > > 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-control.html >> >> 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. It is the right short- to mid-term plan. I rather have a shed I can live in today than a palace in 5 years :). Well, not true, I probably want both :). Alex
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-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 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
On Thu, Jan 31, 2019 at 3:30 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > 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-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" > 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
On 1/31/19 8:31 AM, Bin Meng wrote: > On Thu, Jan 31, 2019 at 3:30 PM Bin Meng <bmeng.cn@gmail.com> wrote: >> >> 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-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 >
On Thu, Jan 31, 2019 at 7:38 PM Heinrich Schuchardt <xypron.glpk@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@gmail.com> wrote: > >> > >> 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-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
diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c index 20b958cfd4..009f376602 100644 --- a/drivers/sysreset/sysreset_x86.c +++ b/drivers/sysreset/sysreset_x86.c @@ -10,8 +10,10 @@ #include <sysreset.h> #include <asm/io.h> #include <asm/processor.h> +#include <efi_loader.h> -static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type) +static __efi_runtime int x86_sysreset_request(struct udevice *dev, + enum sysreset_t type) { int value; @@ -31,6 +33,25 @@ static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type) return -EINPROGRESS; } +#ifdef CONFIG_EFI_LOADER +void __efi_runtime EFIAPI efi_reset_system( + enum efi_reset_type reset_type, + efi_status_t reset_status, + unsigned long data_size, void *reset_data) +{ + if (reset_type == EFI_RESET_COLD || + reset_type == EFI_RESET_PLATFORM_SPECIFIC) + x86_sysreset_request(NULL, SYSRESET_COLD); + else if (reset_type == EFI_RESET_WARM) + x86_sysreset_request(NULL, SYSRESET_WARM); + + /* TODO EFI_RESET_SHUTDOWN */ + + while (1) { } +} +#endif + + static const struct udevice_id x86_sysreset_ids[] = { { .compatible = "x86,reset" }, { }
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 --- drivers/sysreset/sysreset_x86.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-)