[U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset
Alexander Graf
agraf at suse.de
Mon Jan 28 19:27:15 UTC 2019
On 28.01.19 20:24, Simon Glass wrote:
> Hi Alex,
>
> On Mon, 28 Jan 2019 at 12:15, Alexander Graf <agraf at suse.de> wrote:
>>
>>
>>
>> On 28.01.19 20:13, Simon Glass wrote:
>>> Hi,
>>>
>>> On Mon, 28 Jan 2019 at 08:42, Alexander Graf <agraf at suse.de> 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.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf at suse.de>
>>>> ---
>>>> drivers/sysreset/sysreset_x86.c | 23 +++++++++++++++++++++++
>>>> 1 file changed, 23 insertions(+)
>>>>
>>>> diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
>>>> index 20b958cfd4..efed45ccb7 100644
>>>> --- a/drivers/sysreset/sysreset_x86.c
>>>> +++ b/drivers/sysreset/sysreset_x86.c
>>>> @@ -10,6 +10,29 @@
>>>> #include <sysreset.h>
>>>> #include <asm/io.h>
>>>> #include <asm/processor.h>
>>>> +#include <efi_loader.h>
>>>> +
>>>> +#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)
>>>> +{
>>>> + u32 value = 0;
>>>> +
>>>> + if (reset_type == EFI_RESET_COLD)
>>>> + value = SYS_RST | RST_CPU | FULL_RST;
>>>> + else if (reset_type == EFI_RESET_WARM)
>>>> + value = SYS_RST | RST_CPU;
>>>
>>> The EFI should use the sysreset driver and sysreset_walk() or similar,
>>> rather than having a function called directly.
>>
>> It can't. At this point all of DM is long gone. We're in runtime space here.
>
> This has come up before. We'll end up with a lot of duplication if we
> cannot solve this. I think the run-time code will need to be built and
> linked separately so that all necessary code is pulled in.
It's mostly a question of size. We can even transform all of U-Boot into
huge runtime services if we keep the relocation tables around and apply
relocations manually for everything.
The problem is that if we do that, we'll become even bigger than we are
now, no?
Alex
More information about the U-Boot
mailing list