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 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. Should we just adjust it so that the whole of U-Boot is in there? How big is the UEFI run-time normally? >> >> That mesns we could either make a generic, broken version. Or we just >> convert one by one for systems that we can verify it on :). I hope that I >> designed the APIs easily enough that people who are not us enable RTS >> support on other platforms too :) > > > Ping! Anyone any comments on the two open questions of uppercase vs. > lowercase and placement of attribute? I prefer lower case :-) > > 1/2 should not be affected by those discussion points and already > featured in a second series (LS2080ARDB). Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
