Hi Alex,
On Mon, 28 Jan 2019 at 12:27, Alexander Graf agraf@suse.de wrote:
On 28.01.19 20:24, Simon Glass wrote:
Hi Alex,
On Mon, 28 Jan 2019 at 12:15, Alexander Graf agraf@suse.de wrote:
On 28.01.19 20:13, Simon Glass wrote:
Hi,
On Mon, 28 Jan 2019 at 08:42, Alexander Graf agraf@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@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?
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