Hi Alex,
On 25 October 2016 at 15:33, Alexander Graf agraf@suse.de wrote:
On 10/08/2016 14:56, Simon Glass wrote:
Hi Alex,
[...]
#endif struct efi_device_path; diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 798b566..e027bd3 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -39,6 +39,7 @@ static bool efi_is_direct_boot = true; */ static struct efi_configuration_table EFI_RUNTIME_DATA efi_conf_table[1]; +#ifdef CONFIG_ARM /*
- The "gd" pointer lives in a register on ARM and AArch64 that we
declare
- fixed when compiling U-Boot. However, the payload does not know about
that @@ -46,16 +47,20 @@ static struct efi_configuration_table EFI_RUNTIME_DATA efi_conf_table[1];
- EFI callback entry/exit.
*/ static volatile void *efi_gd, *app_gd; +#endif
So is fs reserved for firmware use on x86?
No I don't think so. The correct approach would be to save and restore the FS register, but it seems to work this way, so I haven't taken it any further.
Can you make sure you save/restore %fs on x86 in the next round then? Finding bugs like these is very hard once the code is in.
I still haven't done this. In fact I'm starting to wonder what other registers we might have a problem with. Looking at the setjmp()/longjmp() that I have, it doesn't save everything.
This series was just an attempt to get the EFI loader working on x86.
Yes, and it's very very very much appreciated :).
Since we have the 32/64-bit limitation on x86 and U-Boot runs in 32-bit at present, it's not going to be very useful yet IMO. But it is a start.
I agree. It's a really good start.
I suspect that it will be quite a bit of work to get U-Boot running in 64-bit mode. I sent a series about a month ago, but it still lacks quite a few features.
Regards, Simon