On 28.01.19 20:31, Simon Glass wrote: > Hi Alex, > > On Mon, 28 Jan 2019 at 12:27, Alexander Graf <[email protected]> wrote: >> >> >> >> On 28.01.19 20:24, Simon Glass wrote: >>> Hi Alex, >>> >>> On Mon, 28 Jan 2019 at 12:15, Alexander Graf <[email protected]> wrote: >>>> >>>> >>>> >>>> On 28.01.19 20:13, Simon Glass wrote: >>>>> Hi, >>>>> >>>>> On Mon, 28 Jan 2019 at 08:42, Alexander Graf <[email protected]> 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 <[email protected]> >>>>>> --- >>>>>> 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? > > I did a change to build U-Boot as a library, perhaps it could build on > that. The 'run-time U-Boot' won't be any bigger than the code that is > actually used. Also I don't think memory usage is a concern in systems > that use UEFI :-)
It is, we're already exploding some constraints today. Furthermore, by moving all of U-Boot into RTS you obviously waste a few MB of RAM while Linux is up. And it's much harder to review that the code is only doing what you want it to do. > The problem with the current approach is that everything becomes > parallel to DM, duplicating existing code, and that is complicated > too. No, not everything. Only reset/shutdown. Well, and maybe variable services. Which may use SPI. Meh. Alex _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
