Hi Alex, On Mon, 28 Jan 2019 at 12:39, Alexander Graf <[email protected]> wrote: > > > > On 28.01.19 20:36, Simon Glass wrote: > > Hi Alex, > > > > On Mon, 28 Jan 2019 at 12:34, Alexander Graf <[email protected]> wrote: > >> > >> > >> > >> 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. > > > > My suggest is not to move all of U-Boot into RTS. It is to build an > > RTS version of U-Boot with just those things that are needed, a bit > > like TPL or SPL. > > Yes, but the "loaded binary" to boot the system is then BTS + RTS. So if > U-Boot is 1MB and the RTS U-Boot build is 0.5MB, you need to store and > load 1.5MB from SD card or SPI or wherever your U-Boot is stored.
Yes that's right. Although I suspect it is only about half that. E.g. Raspberry Pi 2 is 431KB. I'd hope that RTS would be very small? > > > By morphing all of U-Boot over, the runtime cost is higher (1MB rather > than 0.5MB used while Linux is up), but the boot time cost is smaller > (only 1MB on storage). > > > I did not invent the run-time aspect of EFI, but I feel we are trying > > to support it with a hack. > > Well, it is a hack in edk2 as well. RTS are a terrible idea in my book. > But they're there and we need to support at least reset/shutdown and > *maybe* some sort of runtime variables. Yes, but at some point this all becomes unmanageable. I think we should adjust the approach now. > > > >>> 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. > > > > That should be a fairly small build, then. > > It still adds to the binary size. Yes. In fact EFI_LOADER adds about 50KB on the same rpi_2. This is a fact of life with EFI. I really don't think EFI is optimised for code size. I think we need a little build like SPL which pulls in just what is needed, but does use DM. Regards, Simon _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
