Am 18.08.2016 um 05:44 schrieb Simon Glass sjg@chromium.org:
Hi Alex,
On 16 August 2016 at 13:08, Alexander Graf agraf@suse.de wrote: EFI allows an OS to leverage firmware drivers while the OS is running. In the generic code we so far had to stub those implementations out, because we would need board specific knowledge about MMIO setups for it.
However, boards can easily implement those themselves. This patch provides the framework so that a board can implement its own versions of get_time and reset_system which would actually do something useful.
While at it we also introduce a simple way for code to reserve MMIO pointers as runtime available.
Signed-off-by: Alexander Graf agraf@suse.de
cmd/bootefi.c | 4 ++ include/efi_loader.h | 18 ++++++++ lib/efi_loader/efi_runtime.c | 101 ++++++++++++++++++++++++++++++++++++++----- 3 files changed, 112 insertions(+), 11 deletions(-)
Instead of weak functions, can you use the existing driver model sysreset uclass?
Unfortunately not, at least not generically.
The EFI RTS code gets dynamically relocated by the executing OS (like Linux) and expects any pointers to dynamically move to where the OS remaps things to. So memory at 0x1234 during boot time might become 0x75995234 in RTS.
While we can automatically catch all linker relocations, dynamically created objects or pointers that rely on the 1:1 map will fail to work once we're in Linux because of the above.
So the "obvious" path forward would be for systems that implement the sysreset uclass to provide an efi rts reset function which calls into their sysreset device. In a patch that enables this, whoever does it would also have to go through all the the dm code, annotate it as efi runtime and wrap all pointers in the dynamic efi relocation call. The same goes for pointers to device memory that needs to get accessed, which then also needs to get annotated as efi mmio regions in the efi memory map.
This is insanely tedious and very hard to get right. The less complexity we have in RTS code, the better we are off.
The less obvious - but imho more sane - route would be to just implement PSCI on armv8 systems. York has patches in the works to make U-Boot be a PSCI provider on armv8, armv7 already has PSCI provider code. In EL3 / TZ you can maintain your 1:1 map, don't need to swizzle pointers and could just reuse dm as much as you like. Linux gets secondary smp bootup (and core power off for power saving) for free and efi reset would "just work" with this patch set. Even better yet, it would "just work" without efi too ;).
Alex