On 12.08.16 19:21, Simon Glass wrote: > Hi Alex, > > On 11 August 2016 at 05:49, Alexander Graf <ag...@suse.de> wrote: >> >> >> On 08.08.16 23:44, Simon Glass wrote: >>> Hi, >>> >>> On 7 August 2016 at 10:59, Andreas Färber <afaer...@suse.de> wrote: >>>> Am 14.07.2016 um 08:18 schrieb Alexander Graf: >>>>>> Am 14.07.2016 um 06:48 schrieb Andreas Färber <afaer...@suse.de>: >>>>>> >>>>>> Hi Alex, >>>>>> >>>>>>> Am 05.06.2016 um 23:17 schrieb Alexander Graf: >>>>>>> If Linux finds an EFI implementation it always uses the EFI reset >>>>>>> handler to >>>>>>> reboot or power down the system. >>>>>> >>>>>> Hm, I thought my powerdown issues on the Jetson TK1 were for lack of >>>>>> CONFIG_AS3277_RESET - sounds like it could be due to EFI instead? >>>>> >>>>> It depends. IIRC the TK1 is 32bit, where you're probably using grub2 >>>>> which is not efi Linux aware, but instead boots over the zImage protocol. >>>>> In that case Linux doesn't know about efi runtime services. >>>> >>>> We've confirmed in the meantime that the Jetson TK1 issues were >>>> unrelated to EFI and could be worked around by enabling some as3722 >>>> kernel option. >>>> >>>>>>> Unfortunately we haven't implemented that one yet. In fact, while we >>>>>>> prepared >>>>>>> for RTS handling, we never actually implemented a single user. >>>>>>> >>>>>>> This is going to change today. This simple patch set enables RTS reset >>>>>>> support >>>>>>> for the RPi systems, allowing you to reboot and shut down the rpi if >>>>>>> booted >>>>>>> via EFI. >>>>>>> >>>>>>> It also lays the groundwork to show how to implement that functionality >>>>>>> at all, >>>>>>> so I expect more boards to follow. >>>>>>> >>>>>>> Alexander Graf (2): >>>>>>> efi_loader: Allow boards to implement get_time and reset_system >>>>>>> ARM: bcm283x: Implement EFI RTS reset_system >>>>>>> >>>>>>> arch/arm/mach-bcm283x/include/mach/wdog.h | 2 +- >>>>>>> arch/arm/mach-bcm283x/reset.c | 59 +++++++++++++++-- >>>>>>> cmd/bootefi.c | 4 ++ >>>>>>> include/efi_loader.h | 18 ++++++ >>>>>>> lib/efi_loader/efi_runtime.c | 101 >>>>>>> ++++++++++++++++++++++++++---- >>>>>>> 5 files changed, 166 insertions(+), 18 deletions(-) >>>>>> >>>>>> This all looks very non-generic and would mean that every board will >>>>>> need to be patched individually, which is unrealistic to be tested by >>>>>> just the two of us. >>>>>> >>>>>> Can't you patch the reset_cpu() declaration (common.h/sysreset.h) >>>>>> instead of all its implementations? We might still need to patch >>>>>> individual implementations but I don't see why any reset_cpu() >>>>>> implementation should be in a different section than others. >>>>> >>>>> Hmm. There are 2 minor problems: >>>>> >>>>> 1) Efi also supports power off on top of reset >>>>> 2) We would have to convert all boards at once, rather than one by one, >>>>> as we couldn't distinguish between efi aware and unaware ones >>>> >>>> I don't see why we would need to convert everything at once either way. >>>> >>>>> >>>>> And one major issue: >>>>> >>>>> All device memory pointers used by the reset functions need to be marked >>>>> as such in the efi memory map and live relocated when entering runtime >>>>> mode. So we need to manually touch every function either way. >>> >>> I'm worried about this. It means that any code used from this run-time >>> needs to be so marked. This could be large tracts of U-Boot. In >> >> We only need to mark the few bits that are actually executed and used >> within RTS. That's usually just 2 or 3 functions. >> > > At present you only have reset, and you've only implemented it for one > board. Are there other calls that we need to implement? This > EFI_RUNTIME is transitive - anything it calls must be in the runtime. > Does the linker prevent us from screwing up?
It doesn't (I couldn't find a way), but the runtime relocation code does: https://github.com/trini/u-boot/blob/master/lib/efi_loader/efi_runtime.c#L205 > >> Also, moving forward, we'll see more and more systems implement PSCI >> which means we can implement a generic PSCI RTS for reset/shutdown. > > What system can I get that uses that today? Anything that runs ATF: https://github.com/ARM-software/arm-trusted-firmware in EL3: - Pine64 - ZynqMP - S905X - Hikey - probably many many more I think the only AArch64 systems that I'm aware of that do *not* run ATF in EL3 are - Anything FSL LS - RPi3 - uniphier and in all 3 cases it's a bad design decision IMHO, but it's one that their respective creators did. > >> >>> particular, as I have mentioned a few times, I think the UEFI tables >>> should be 'live' and not just created before booting, which means that >>> much of driver/core needs to be in the UEFI section. >> >> I don't fully understand what you're aiming for here. The tables are >> always static in a uEFI world. I don't see how they could get more >> "live" than creating them right before boot. > > I'd prefer to see the EFI requests be processed as they are received, > rather than with pre-canned data. Your original justification (e.g. > for efi_disk_add_dev()) was that there was not authoritative list of > block devices in U-Boot. But there is now. > > So do you think it would be feasible to drop these tables, and efi_obj_list? Ah, we're talking about different tables. I was thinking "tables" as in what EFI calls tables. That would be the device tree or SMBIOS tables. Those are really just pointers to memory. > What happens with the tables if I run an app and then come back to U-Boot? So let me try to grasp what you mean by tables. I guess you mean the list of devices? It gets regenerated on every bootefi invocation. Or did you mean something different? Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
