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 :-) The problem with the current approach is that everything becomes parallel to DM, duplicating existing code, and that is complicated too. Regards, Simon _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
