[U-Boot] [PATCH 1/6] x86: Add implementations of setjmp() and longjmp()

Bring in these functions from Linux v4.4. They will be needed for EFI loader support.
Signed-off-by: Simon Glass sjg@chromium.org ---
arch/x86/cpu/Makefile | 2 +- arch/x86/cpu/setjmp.S | 71 +++++++++++++++++++++++++++++++++++++++++++ arch/x86/include/asm/setjmp.h | 24 +++++++++++++++ 3 files changed, 96 insertions(+), 1 deletion(-) create mode 100644 arch/x86/cpu/setjmp.S create mode 100644 arch/x86/include/asm/setjmp.h
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile index 2667e0b..f5b8c9e 100644 --- a/arch/x86/cpu/Makefile +++ b/arch/x86/cpu/Makefile @@ -10,7 +10,7 @@
extra-y = start.o obj-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o -obj-y += interrupts.o cpu.o cpu_x86.o call64.o +obj-y += interrupts.o cpu.o cpu_x86.o call64.o setjmp.o
AFLAGS_REMOVE_call32.o := -mregparm=3 \ $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32) diff --git a/arch/x86/cpu/setjmp.S b/arch/x86/cpu/setjmp.S new file mode 100644 index 0000000..24e7d8a --- /dev/null +++ b/arch/x86/cpu/setjmp.S @@ -0,0 +1,71 @@ +/* + * Written by H. Peter Anvin hpa@zytor.com + * Brought in from Linux v4.4 and modified for U-Boot + * From Linux arch/um/sys-i386/setjmp.S + * + * SPDX-License-Identifier: GPL-2.0 + */ + +#include <asm/global_data.h> +#include <asm/msr-index.h> +#include <asm/processor-flags.h> + +#define _REGPARM + +/* + * The jmp_buf is assumed to contain the following, in order: + * %ebx + * %esp + * %ebp + * %esi + * %edi + * <return address> + */ + + /* + * rdi - 32-bit code segment selector + * rsi - target address + * rdx - table address (0 if none) + */ + .text + .align 4 + .globl setjmp + .type setjmp, @function +setjmp: +#ifdef _REGPARM + movl %eax,%edx +#else + movl 4(%esp),%edx +#endif + popl %ecx # Return address, and adjust the stack + xorl %eax,%eax # Return value + movl %ebx,(%edx) + movl %esp,4(%edx) # Post-return %esp! + pushl %ecx # Make the call/return stack happy + movl %ebp,8(%edx) + movl %esi,12(%edx) + movl %edi,16(%edx) + movl %ecx,20(%edx) # Return address + ret + + .size setjmp,.-setjmp + + .text + .align 4 + .globl longjmp + .type longjmp, @function +longjmp: +#ifdef _REGPARM + xchgl %eax,%edx +#else + movl 4(%esp),%edx # jmp_ptr address + movl 8(%esp),%eax # Return value +#endif + movl (%edx),%ebx + movl 4(%edx),%esp + movl 8(%edx),%ebp + movl 12(%edx),%esi + movl 16(%edx),%edi + jmp *20(%edx) + + .size longjmp,.-longjmp diff --git a/arch/x86/include/asm/setjmp.h b/arch/x86/include/asm/setjmp.h new file mode 100644 index 0000000..deef67e --- /dev/null +++ b/arch/x86/include/asm/setjmp.h @@ -0,0 +1,24 @@ +/* + * Written by H. Peter Anvin hpa@zytor.com + * Brought in from Linux v4.4 and modified for U-Boot + * From Linux arch/um/sys-i386/setjmp.S + * + * SPDX-License-Identifier: GPL-2.0 + */ + +#ifndef __setjmp_h +#define __setjmp_h + +struct jmp_buf_data { + unsigned int __ebx; + unsigned int __esp; + unsigned int __ebp; + unsigned int __esi; + unsigned int __edi; + unsigned int __eip; +}; + +int setjmp(struct jmp_buf_data *jmp_buf); +void longjmp(struct jmp_buf_data *jmp_buf); + +#endif

These are missing in some functions. Add them to keep things consistent.
Signed-off-by: Simon Glass sjg@chromium.org ---
cmd/bootefi.c | 7 +++++-- include/efi_loader.h | 2 +- lib/efi_loader/efi_boottime.c | 5 +++-- lib/efi_loader/efi_disk.c | 13 +++++++------ lib/efi_loader/efi_net.c | 4 ++-- 5 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c index d66892e..0536b63 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -14,6 +14,8 @@ #include <libfdt_env.h> #include <memalign.h> #include <asm/global_data.h> +#include <asm-generic/sections.h> +#include <linux/linkage.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -51,7 +53,7 @@ static struct efi_device_path_file_path bootefi_device_path[] = { } };
-static efi_status_t bootefi_open_dp(void *handle, efi_guid_t *protocol, +static efi_status_t EFIAPI bootefi_open_dp(void *handle, efi_guid_t *protocol, void **protocol_interface, void *agent_handle, void *controller_handle, uint32_t attributes) { @@ -144,7 +146,8 @@ static void *copy_fdt(void *fdt) */ static unsigned long do_bootefi_exec(void *efi, void *fdt) { - ulong (*entry)(void *image_handle, struct efi_system_table *st); + ulong (*entry)(void *image_handle, struct efi_system_table *st) + asmlinkage; ulong fdt_pages, fdt_size, fdt_start, fdt_end; bootm_headers_t img = { 0 };
diff --git a/include/efi_loader.h b/include/efi_loader.h index 9738835..aa4ae0e 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -93,7 +93,7 @@ void efi_net_set_dhcp_ack(void *pkt, int len); * Stub implementation for a protocol opener that just returns the handle as * interface */ -efi_status_t efi_return_handle(void *handle, +efi_status_t EFIAPI efi_return_handle(void *handle, efi_guid_t *protocol, void **protocol_interface, void *agent_handle, void *controller_handle, uint32_t attributes); diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index be6f5e8..798b566 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -159,7 +159,7 @@ static struct { u32 trigger_time; u64 trigger_next; unsigned long notify_tpl; - void (*notify_function) (void *event, void *context); + void (EFIAPI *notify_function) (void *event, void *context); void *notify_context; } efi_event = { /* Disable timers on bootup */ @@ -168,7 +168,8 @@ static struct {
static efi_status_t EFIAPI efi_create_event( enum efi_event_type type, ulong notify_tpl, - void (*notify_function) (void *event, void *context), + void (EFIAPI *notify_function) (void *event, + void *context), void *notify_context, void **event) { EFI_ENTRY("%d, 0x%lx, %p, %p", type, notify_tpl, notify_function, diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index c434c92..0a35d53 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -33,9 +33,10 @@ struct efi_disk_obj { lbaint_t offset; };
-static efi_status_t efi_disk_open_block(void *handle, efi_guid_t *protocol, - void **protocol_interface, void *agent_handle, - void *controller_handle, uint32_t attributes) +static efi_status_t EFIAPI efi_disk_open_block(void *handle, + efi_guid_t *protocol, void **protocol_interface, + void *agent_handle, void *controller_handle, + uint32_t attributes) { struct efi_disk_obj *diskobj = handle;
@@ -44,7 +45,7 @@ static efi_status_t efi_disk_open_block(void *handle, efi_guid_t *protocol, return EFI_SUCCESS; }
-static efi_status_t efi_disk_open_dp(void *handle, efi_guid_t *protocol, +static efi_status_t EFIAPI efi_disk_open_dp(void *handle, efi_guid_t *protocol, void **protocol_interface, void *agent_handle, void *controller_handle, uint32_t attributes) { @@ -107,7 +108,7 @@ static efi_status_t EFIAPI efi_disk_rw_blocks(struct efi_block_io *this, return EFI_EXIT(EFI_SUCCESS); }
-static efi_status_t efi_disk_read_blocks(struct efi_block_io *this, +static efi_status_t EFIAPI efi_disk_read_blocks(struct efi_block_io *this, u32 media_id, u64 lba, unsigned long buffer_size, void *buffer) { @@ -142,7 +143,7 @@ static efi_status_t efi_disk_read_blocks(struct efi_block_io *this, return EFI_EXIT(r); }
-static efi_status_t efi_disk_write_blocks(struct efi_block_io *this, +static efi_status_t EFIAPI efi_disk_write_blocks(struct efi_block_io *this, u32 media_id, u64 lba, unsigned long buffer_size, void *buffer) { diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c index dd3b485..9199518 100644 --- a/lib/efi_loader/efi_net.c +++ b/lib/efi_loader/efi_net.c @@ -191,7 +191,7 @@ static efi_status_t EFIAPI efi_net_receive(struct efi_simple_network *this, return EFI_EXIT(EFI_SUCCESS); }
-static efi_status_t efi_net_open_dp(void *handle, efi_guid_t *protocol, +static efi_status_t EFIAPI efi_net_open_dp(void *handle, efi_guid_t *protocol, void **protocol_interface, void *agent_handle, void *controller_handle, uint32_t attributes) { @@ -203,7 +203,7 @@ static efi_status_t efi_net_open_dp(void *handle, efi_guid_t *protocol, return EFI_SUCCESS; }
-static efi_status_t efi_net_open_pxe(void *handle, efi_guid_t *protocol, +static efi_status_t EFIAPI efi_net_open_pxe(void *handle, efi_guid_t *protocol, void **protocol_interface, void *agent_handle, void *controller_handle, uint32_t attributes) {

On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote:
These are missing in some functions. Add them to keep things consistent.
Signed-off-by: Simon Glass sjg@chromium.org
cmd/bootefi.c | 7 +++++-- include/efi_loader.h | 2 +- lib/efi_loader/efi_boottime.c | 5 +++-- lib/efi_loader/efi_disk.c | 13 +++++++------ lib/efi_loader/efi_net.c | 4 ++-- 5 files changed, 18 insertions(+), 13 deletions(-)
Reviewed-by: Bin Meng bmeng.cn@gmail.com

On 08/07/2016 01:23 AM, Simon Glass wrote:
These are missing in some functions. Add them to keep things consistent.
Signed-off-by: Simon Glass sjg@chromium.org
Is there any way to change the EFIAPI definition so that we get build warnings for non matching function types on aarch64 as well?
Reviewed-by: Alexander Graf agraf@suse.de
Alex

Hi Alex,
On 10 August 2016 at 05:40, Alexander Graf agraf@suse.de wrote:
On 08/07/2016 01:23 AM, Simon Glass wrote:
These are missing in some functions. Add them to keep things consistent.
Signed-off-by: Simon Glass sjg@chromium.org
Is there any way to change the EFIAPI definition so that we get build warnings for non matching function types on aarch64 as well?
Reviewed-by: Alexander Graf agraf@suse.de
It might be possible to add a bogus attribute that does nothing. Perhaps regparm(0)?
Regards, Simon

It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
Signed-off-by: Simon Glass sjg@chromium.org ---
arch/arm/lib/HelloWorld32.efi | Bin 0 -> 11712 bytes arch/arm/lib/Makefile | 6 ++++++ cmd/Kconfig | 10 ++++++++++ cmd/bootefi.c | 26 ++++++++++++++++++++------ include/asm-generic/sections.h | 2 ++ scripts/Makefile.lib | 19 +++++++++++++++++++ 6 files changed, 57 insertions(+), 6 deletions(-) create mode 100644 arch/arm/lib/HelloWorld32.efi
diff --git a/arch/arm/lib/HelloWorld32.efi b/arch/arm/lib/HelloWorld32.efi new file mode 100644 index 0000000000000000000000000000000000000000..7708451c04a99752ed468842090a9b3f3506090e GIT binary patch literal 11712 zcmcI~3sjS5p7-<S0wDwmH=*L?4R{Gg<qd&=78L@##G(ZOFK4H-H6;;JLxLf+XnUrh zo%wn?dKQd3g6NpBGrQfLne)MH{XX3(2Re54%<R@(Xzd)go!!0(b+y<t6Q^`YE1La1 zZxTesX~(l0{lCxce}DeZ|G6Bt{RMgCU)Lj3-X*N7BIFm0^lk@g0$IQ$GK7rg(R$>k zkr2WH1YM-fqM&g9Z**-0kM=9?AB?uu59yz;dvpzYq01EHo|_Nh5&PD8Y@Hs^QX8pV zv2rdumXJN`tQL<2odN~u5G&D~{gr`yo!jPcHKB|8EvmCv&SDV)Jky-!*Q%;&+Rn-O z>=qTDHuP%CNz;P&w7iBV!IY4O*P?7g87J1B4RL(iFk@~Temk3x#|Y`7lq%qKhvM+< z4Ecu0y3`Lyup?AAR2zgkL3c<i)^fKL0HZ0CWBw;i&J!eP2}Puw5-GniOSyZNaz~Uh zU8LkgY35&R(m+`m)$3MB29BFTgF|FZI%GaROIZ@7jN6g}jJ%NC{EkNc#PIbt=(FN{ z+b|g!T||f<V1pfP)g;KAC#2+Dd`)&|%}`toS-zy@Cnnjuax+s%g6Be^YlJNs?gQ@2 zfRlg)Z%7B*szJ%#g_3jd;5O}^@bpxe8`8DpUPv(;G$~Jnr*DMS+t#4}dbB^$yk3)p z{*S_{Z4>)+82K<dA~SE+C@}JFm`WrgA0r-q1$k>06Y?qQTTos{`AwASbMafhyDt~i zZ-P1(@?_?GjSSTP0BZGc5P186_aR{IC&BVKK8f$)!_z+sYll`|SZ1!!ECcT8aCrI@ z=s$~>y}!s@smVs47k$Towc<jCxk{6Xo>#+}HOpF<;+IGXJo?m^GVtjJ#_|hE<|jlO z4}=SNmS4|TVEo{haeUE`c4%J<o#Vdhm6O7AEcz?I<oMz1!EQ40d+20bLdZ5i8{i0R zd<A9l8}T*q=VX7M-BKTtCI0)f%(3wF55m&HZ-!(yWbiok0rhzZaTlI06Lm~6|3uWF z1X>rvk{hr@W&Ww?;dSApTC%(-l+NuN+SKyoP<VPJFy1i9-jkWnY2snok}y;FyK5{T z8Xj0m$i9_?{1#;o^a-O>oC{C?I?QloL@^wZ83+2cu)6FIm&)lJ-oB%P1l_K7@ZSmk zf4oxy{_^+az<9qr4j7-_iAf+MF&W3f|5Z(d|9jxC7$zj`9QEpN?oh8Lm{)5OK>M$E zayyTP;<zS!GItQoess5ib*7tK{evTyFB8z5|Q@2NEhdzG&It9Txm9hvmF)ad>(x zTs29`XiUXu+7K1Y9-p5beI~Hbgi>7};I_W(R~PvF>T=(9Qs?taiO(-n`}}QW`1;at zKFYP9(0)o&1U#112U1E8`}LsLbH44A-`Azt4w~%`p$V3){Y2GvG%#1cGU1uP{W`Lv zrU2E4TL4{HcVMBa%Wquj^BX0;?J{*Ybm{U3yAX3xesgsf`Q4{K<ws?vfCuGQw7A=! z0p1y@zU`D3<w^N<fggc>g!4_1QJ<d?eEw6CZsGf>8sSu$M(CQ0^Ht;E@z+vv;~pCH z^+o$;byq>=o`wMNLEfOxFDdgeutzGxHi)_(^$DuatDqy~J6Dy&=TF4k$ylFX&iVW= z(tZ_uG1nj9xp>d%tAx^%of8avDe++r!5`a<@_Eom$#<^Hz)KEZO7KbqFZ(0#Dt`#C zWpj89!mm^Z*z_gUNe;Qt<4YQYgV3ACdDqWKFg_&bSrrLNLuHe4M0MFecKr;Qn8YD_ zFvuPsKHFDKv~P}(T*k}viTUFe&6^A_W3eJf)HUjJ*)7@o`l{)gTYURG_K=JZ!qbo4 zj_h0E>4mo=`&K;mknnW;?KrGwgP!gp>ay^(WLP~+`O$skL##o%k4z&cE#TAnWx)Sz zh8vnh9!fG-i+N~rCOrKK`X<n)Fq_4-EzFP;Bv;Eb-u;T&DW5wR8L~Pg9SmZP{&WQ) zp97X4AGMvk_*wi)*=e%;xGCX-S4{EmO52#VvYU)7YlLspR(^J^ZMYqNi91a+2~RR@ zYW^{PHP8H*338!Cp6QqH`=649m}T{oQYJXg@{+-};X~l7ctd^e+k^2xX$;98mmVj_ z$#Uj63C4xwgVaU_*;d>)YJWVql>ghBqBAN!vnO?m)MdA1@TwDqXY#zsC*)(9XGor6 zgsjRuktC2j66|_8Jnfk&8Ol79e__B}JN5tfpF|#eb|xcOmaH0KR!LT+oWR&nN*_}y zyG1<d#~C5>O!|pW<tgunr+3YmhdB7J;<om}cj57)DMvtEGgJG=@beibB&(8z@N`ua z#{!%~!1?Qxmw~f>CcG-+1heXUUob3T4V|ecGR{;?N^;YB9xuy0v&6e(AbY5KD82u$ zkegqZmEHXOa9SS;u6#2|C!dn<Ai)<7t<Xuwl)AFuz@b+IIJ+oogN*7@Xtyu*WJce@ zO3K&JNjXZ(*6M1;lCG@Q?HZF`AvzNLUKgt~kEIAYooQ^1jvrGA>veHg^tyfTuG1OD zI9=12RM@K9IOfnjK4#S|@si-NuCyx+pseYRyP`z7{7@3Uszd7n7L=y$CVZdj-mP<u ztq8QEUfiv?(x%%x=0^SP?q+;#-C2PSopo$9*x%i$`{r0mplXWPUcXiqWaK}>S0X=) zuS|XhUxoY>zG`{@wLE$9WmP{gJ2V%PPbLqfwk$lBD5&~W{iH>vSM@IJ`9IfGCs$uc z9(XTAMrDR%?@QNIeKM{tBzs5IbKu%)`R<XbAS<W-;T|vG6Lbr%C^e~l%q``H)Pbdy zX_ekD7<JlH6_ZSEMt@@2r`J+Xu95%E4M`lidGIimyW?7F-zk2H*SP4se?`zJr`)Q7 zU5P~aF`pgmN|ul7f|A6Vsjiwxk6NPYe{5V2jbw&~kZfzR_iCmF8jCt@RrOrWTqKYY zdT!=cMfSoJEg=PfEue`v<ObuV(whpB-1FWiq)H~J`W5=^pGc}yz1cxoa{5SZkX67M zMRrh<oQ0MSwXS4#{9isBm8g#`8qx*XL>dWXO~*|lP5dBxs;gEpZZ*|FOWTbqxiYsl zxK@!VRQ^FNO`McU|KW2wPFBPT8!m`6B>n@kLM|wC<pR;DbJe|!fbX%Sn=d91Zw{~H z&HSZM;V4cbcN!<<lK(*c*Efh#HvZ;KlB|G6L|Mm6H57*gCnv`%DTazq7<%ibRHhzi z8u~}zC5$O=hPfElZzd_up~~|ZK}_Fdl&YJIDm%y~!>@?-!tU%KlUx?$y0fRqOC-3a zdto1HF4&o<7<rjD`>Uq9Y^we|#E7f_C$Uq>$Kbih44hJVFHpYYABC*m6~N1wBG$6t zW8LcGukk+qhkTx2)yG{(?w9HHAz5j1?^3T^P=QYYTB>79y<|D%u0Ec0vonEGr1(_> zx(mtC8BOk?b0pJm$6Tv=$r=(Ay4a|Pj@;_z*(Jy(x4L*A%DuNPg-Fk(kgRK^hU7?k zmc5>PQ0i?uDD%E{Q0|>L80XD>A>P~cg2MaS3klwd7nI)DYr@lqZ$AlrXpF}q3KD1I ziAwxw*K3{2UZ*^XccPQ==Ds5F<{kj&19TQ--ac^Ib6W>JXFXIZdMLuBRMkUt%l<B_ zH{pZaATe!U%I2xA9N8i-*dEG(b#k5j$}3OQhjM$ePWD#4I8M9~SufW_;=pj5ET_>C z@h6?hE+KUwqi^XwIcSMjiM&FVr}nFlKeveb@uSd{-hIM@*=mV5N%!PfYX5VKYJ|JK z_lUl4m=|A(Ts4>TS@3?bcf-86NxD@c@8u8hKFeza8c`Y{V#!CL(%$UZdSPz{C?X?j z)IJJndn2s`v6U5Vo#pB3TX<YP)zw6F*azB`BTSAYC!CvgEMuyxKHDoBui=mJ@+o3T z5wZrpVaoEVg##C|`WErh%41(JB(>8tNpiCLBqo`-76Mhl_kMTna#h(M7!5NiXBPFA zj9li2J|{0-3Ry=}#upCk;Zyn-ElL}BUB=v!7}C7)my3r;Zwa5?&*tKeF%wUvJ@s>} zf(>JIjj6}d`mvu?ruEV_n=oEIM0%JUieLNXE1!j@mxAK40gCg_H>8pu%g8NBN?Nb^ zGRf!1NDr4wF~ie|z}kddwhg)KTY%%(qx(?)7xLN^K#uwsDE|n!%Pqo-%1s>K1-Y!q zEfPtATQqv&d8*^Wv9y7dlWCP{UW%JE-aJH(QMpV`M8|h-#q$z@Vlrd!xB?b_W2|cP zyHxA`5Mi0h{t&~Z^-`-<<4+HL<7cF&gwH->nv~|I_dj07<b<dH9z4|j3gnuszV6B| zhL}R>n#JRan-bOKs*HDI@+pS}<1fw1Uy~cr_Pe*9;v@P>5CKFe<pqBD+M+(pQ*NIL z^V0v=06e%Ttv_P(-^s*ziCP?<-UsRPML+X#cv=_YhVn14I4xY#(_3#&D5am|rkuoW zwl}>$rIKo2b1OWZ8QMMcY+S<onSJ4D<_qnGG*J9TpAL$IP<UE_(S30Vm+5E@MpYR7 zP@nX~o#`*bnFFCk;2F%iuB^#BnT>Z8*%<csTbFT~`Oly0aHb0W6&Z=`QKvDNp8)8- z#r|TyKv>@dj*=VLxAzMwl=K{rp-E=6$FCve3E$`(9N;HMad9>laarK{F76k)rDd#y zJu9%NGts&a_}!9dKk7`h?t2UUOtc?$My&r#pt8D2q@PjO2}JGFOUPM)-v1<;lmJm% zOl4ewfTyb*synXjqTW;|Ce7!kHf+v4G?6&Bz4FjR{M>flp^43F4&?%0Lq_)pz+<%r z_5UdwZiK_DA7;nJ&4YgEZh{>-)Fuk_-f^+k=U31>9qvSL{a@6_wgr@fxQpOEq9m-K zRBHqon<L1$T$J^KoVzIC?l++%bwZ;0E!2-*EhOZIj9m?!)q(^xQqV{+F2%TdtQx$B zuhV-BmG{;hc^4s14SAw0DigFa&?+HM33-aqqX8NC$iYVm*@>d;qgS&a?+Upziyy<8 zD=T(arS?#Lsh)T@y+NSQ+&d?gPvy{YNtAC4XYL&|9e65o^g4%oqm(`7C%(vi6i;YM zGP*smfDnXo!-PUCcTV8tS1G~$?cb?PwGZv@Tqo+&;{7xgaZB%==ubm`*5A@L#t7Ly zVFbO5rS<v=tO@YkIU(M4!7CB>!e7qeCj$-b`#$Z1K4j20@ja1OT_C2%=i#t2hWGz~ zrz`^==9Ys#zYB*a8O{`tl2m^}R2J@^DbhNX8sk}ndnO>|BtqI|mwy@86eyMY{2zlR zHQ(i5j6Mn1BrJu^czk_z8QT<Kgu{UpypO23qgVBtAcvg3TKbnh|6<c&zk(dSS`FP~ z9JQ@sf`dGUD~Ie9Kl~xuNjRxm%KB1}2hvoK&%htgQ2%lk=)pwvAkYK8V7Wbk4X}Oj z#V)@}ee^2k@ah%cCI3#yNSUMGva+UtdO7a)YQg_jzC_SKM+JNID#IQQT-=QKW2C|c z=)Ab_u>Y;iQh~mAltOpR_0<h{1Np_%QeheA6mb_b7%PwpzepwmDLd>>gRHc<vS1ft z=%hHes_$g!F}_R<`3zzOa%sMc@ufN}V=Drb7nQfTyi1ftV^!tz`4QujD$K6}vG7Ca z`R%&H{vV)x8FJ5}>?Vi(htx-)=jrQ|XKZaM;0p%tJ4Agk@K!#3mpXl2!a@G1B*1V| z<Xnj$DQgs@b-xrC->Zn*zo2uvh^{BR01Axy2gq?dp+lGW-a_Mmfi8%z2^wFq_m%YM zx~A_cG;Rs0OQY+X<`PV%lForT8Y9c#mkh)Ra)5%VI~<^~L<HZ2Iu~*HOP_y18S)Nf zoK5!mkBoNt7qEx@4CfFSt|D+TnGs(5J?3L{kHD0@9FUVn{~_4(8FXF%AJDu)h;Jg6 zU&LI7_-4TKN;rJuIJO%(*(1<#^*IlJXZq|+<hA3@^qHB+YexcJJMK*P%qZ{@{z07d zefknWg2wX$v-O<w^xYA6SMmzpJm|Z!4DZSd@#=ABx)WShUWmghbR71?wi%Ys;|uu5 z>6>pk31*%rBi*3;SHPh`@nvR!=w`<79#Q?_hadi)=3#<gXZ0xmCDs-#H{S|RD$5%h zs_Gk`uHv^mT~%LSThD46JQhz!JG+rx;m%W%{Prfd#naT1-`?!7w72JX*!J4<9d@V1 z?OJQI?kmVQb=V!&e3Q-6?68?!7PmFOzG`b#c|+CH)fE+mCHdv`+w!+rZQESd4u`F7 zUvqwWTbsk)WbxQt&U~}Y;c)G8xxryhwX({zqdLF5!{e&9IoCB2%>&xyk-O*waYHnK zGE~Y;$s#ah2dN@F*+N)iCN|>0KNsq|@O7hZ1qJf-?C&ehgb7snt@dZ!7WaYt9dLum z<?=Mx+|SvYZ0(JfXB;*RK6C(PG;e9OG~3J;r`2I&H5*y2_Bof`%C631xjfR`(D-1V zso{aXM^UuC!|AcN+UC{uA!AhC`Uf?76zMUqpsaJ-ogT2}UG7$k=K<Ta+8tY-Y<x10 zjgGHmxlS(f)90}pH?kb5a5>vu^SIB{v3IY{{Q$=(`a^uKHM`vQgD$7X;;6TQZ3m4> z%7e>eSFU8WJ8f<cBK6)u%$3RUpzb@GEtPJ|^Y>3HP}gn}=Y5^Y?rF8OJ)mN}>-jCt zy{>Y%+j8Jf4mQ{i+St;Kte!M@+_a&M7~SZqw|P3;&b*BqX>Yx4e}~;|vwro;y)UFq zmUc0M!QJj`#w^WFN2G_HXF9gpoXwsVwv>Ikxvt6jG;i;;S<5|QN_ZL_+bo^-){fR4 zPJ5HfYKyRmkdR7Sy9Ze$=J9*h!mQxANb^XKhKqJC+FG{3)!}Zk<*}Ps2!u3bv`7z$ z;YZr+T6PZMBj9gjqqfAnu<_4#15^~}Rm<Dm?VgB-^288~%`()tHMyMDd&Us19SA~1 zgBHK&s`(beb}g%29l=C(>nd(lULKpz>JhYeNh<Bn?JyR08VV>er8O4jvGWtNYwn|c zK-?Cm$L4lg9A;Z*MT^DV=-PoL4xdN0fcQ<D*up%r8v6>3E2tG&%T&2JO4T>C*!Oy% z*MmxZl?W&a0kKK=({oVX-ek8&G>J}LEGXv00(86^L@^4WfBi_Bmnf#;SA<E77S6g? zMfScx*H)Oz>r3eVF{|xH8uO8Wx-aPA*89+5<s6&mi~rTpg;I(<tmilq(<~w&l67`k z935C}G-=*9J~yK88@eZ=?;E>Er+L^$CU0Je4K|CrspTGo2f~g<-Mx0ioF~ePt))5M znxoLy4vbi&fZ(p%=P-h|v2^FxV>R23H166Pq0}4m@`&hUWLY{1u{zgj;fOZUqPcNz z9uUy^$a%lq-I~7xE7{)cv{{k<A7!uKW@~l150v9j7dhb3y?>rQaIeErs67%k+Hxwh z)#mhIi<#4)nIgLF*V`<P2*oB=EXiFNVl>iB$aV73A9Z^)DMk+lI`I0lEuuT3cx0hw z#46&(7~@V4%WhBY-iQ=vEACRU!^+*%tc{##qM`Y4wE6kWC4S(D!08JNg+<2VlJ(`L zipnaUkbL}2R54&1zzR4B@B;n@Fa)>=_&2~Iz(;^j0DlC;ttKQBuo6%JcpR_=&;YOi zS^=GaZopB%X~2&FgMgm{{u%HQ;17TqKmzU}nSd1lJ-`I`bAxK$DTr+dn2KF?t9bq} zln^cNur#-02EK(z;PmW^^z>LF76qJGlyI?l(#|4NoJf%6u`j-eEE(g%bpl;Hbmoy# zXNSYVwu>9sCXz&wl+iAFtlku@H+R^ro9^z~;=0!xX?l*#-@Ga7o}m?7N$1)XT;c4e zpmPORKwFW@{Ut$%H9z_(w6ZL%ZlE8Gl<X#mzq{5%&e4T2n<CaCAS20qj<&UKdoxaE zj%X~3Yc%g+ylB#dQ>o|f&1Um+Y3OLeWvQL)vbde}FtEe9&*^&J$yPfKw6)CkR@xjk zkB#Lmc1MTXHru_+ZJ(z%y1*M<F1Df7;&9BOV`<`|P)Yy(Z>!5<Wvkq7mz!*HK8F-% zMHX>eS|P<vb~xKR+S*)h56;Xc;6)iyzmO+g9u~RBdI0BDde4h8iD**ic6n?~l&rSH z!y;kRO9VZ8wv(N>OtjkA3YXj6(dLOYc|;LdvfFG{yM>5fwyDM9Yz7M|iFb84t)yIZ z5%y-MUF@f9+i>ln+OW7mw83$t5rN0LIy@p>J555sEqA!7t_aj<`<aMUTPn8IMKy2a z8)H?fzN^XQm~~8(tF;XWa$ICt+<e+`7b4iGJK*&L>`uGOAs*IAMSVq-qRMHdR!6LX zlDG=ntgN<Ry?EG+whTCWMiF_t!#3;xtuVU-djM{9t!-{stGykx;$$^6mRHoUeEE*8 zjT>T<QTv?Dz1QJ-p0zvKy&cXb@!GJ$vhHiVPdwz7GkXZGx3yaAPOHt0Y=TaEyGy)A z;^C0~!pcbburJ=>NIyW0zZs?Qq)8v8j8J@KzWZN$KDqlqvd)UI`xC!5j5QXd8?p?G z4Q9huL!IGG!>HkH!><hQ7{&~j4I#sfffODu>?=G~=qvnT;p>I(6l#ms6mdm`MI}W? zih7EU7xfkWwn!*a8`F)7^}E+UwSLcf>-sm=pI`sx`t%JSmtHUZv@}>cRSH3BLbNCb z^>66U>)+Im>fhG?O8<_2On=1CV>oW;Gn_Jrs<MRaM&-D%&v?q{Gyc%{y74E*LE{_7 z^Ts!gqsF(5zcRjK95Y@vUNQdGC>TFBUN?Sf3>v45A>)jZ6w8Vg#j0X;ae8r9@#12( aczLn5cug@FLO%YJ#tpkS9NEyb;lBZO+uTI}
literal 0 HcmV?d00001
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index a8d1557..0f3ea0c 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -29,6 +29,12 @@ obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTM) += zimage.o obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o +ifdef CONFIG_ARM64 +# This option does not work for arm64, as there is no binary. +obj-$(CONFIG_CMD_BOOTEFI_HELLO) += HelloWorld64.o +else +obj-$(CONFIG_CMD_BOOTEFI_HELLO) += HelloWorld32.o +endif obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o else diff --git a/cmd/Kconfig b/cmd/Kconfig index d69b817..8df80b6 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -172,6 +172,16 @@ config CMD_BOOTEFI help Boot an EFI image from memory.
+config CMD_BOOTEFI_HELLO + bool "Allow booting a standard EFI hello word for testing" + depends on CMD_BOOTEFI + default y if CMD_BOOTEFI && !ARM64 + help + This adds a standard EFI hello world application to U-Boot so that + it can be used with the 'bootefi hello' command. This is useful + for testing that EFI is woring at a basic level, and for brining + up EFI support on a new architecture. + config CMD_ELF bool "bootelf, bootvx" default y diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 0536b63..ecf9968 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -229,13 +229,22 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
if (argc < 2) return 1; - saddr = argv[1]; +#ifdef CONFIG_CMD_BOOTEFI_HELLO + if (!strcmp(argv[1], "hello")) { + addr = CONFIG_SYS_LOAD_ADDR; + memcpy((char *)addr, __efi_hello_world_begin, + __efi_hello_world_end - __efi_hello_world_begin); + } else +#endif + { + saddr = argv[1];
- addr = simple_strtoul(saddr, NULL, 16); + addr = simple_strtoul(saddr, NULL, 16);
- if (argc > 2) { - sfdt = argv[2]; - fdt_addr = simple_strtoul(sfdt, NULL, 16); + if (argc > 2) { + sfdt = argv[2]; + fdt_addr = simple_strtoul(sfdt, NULL, 16); + } }
printf("## Starting EFI application at 0x%08lx ...\n", addr); @@ -253,7 +262,12 @@ static char bootefi_help_text[] = "<image address> [fdt address]\n" " - boot EFI payload stored at address <image address>.\n" " If specified, the device tree located at <fdt address> gets\n" - " exposed as EFI configuration table.\n"; + " exposed as EFI configuration table.\n" +#ifdef CONFIG_CMD_BOOTEFI_HELLO + "hello\n" + " - boot a sample Hello Word application stored within U-Boot" +#endif + ; #endif
U_BOOT_CMD( diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h index 328bc62..54ccac9 100644 --- a/include/asm-generic/sections.h +++ b/include/asm-generic/sections.h @@ -22,6 +22,8 @@ extern char __kprobes_text_start[], __kprobes_text_end[]; extern char __entry_text_start[], __entry_text_end[]; extern char __initdata_begin[], __initdata_end[]; extern char __start_rodata[], __end_rodata[]; +extern char __efi_hello_world_begin[]; +extern char __efi_hello_world_end[];
/* Start and end of .ctors section - used for constructor calls. */ extern char __ctors_start[], __ctors_end[]; diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index e720562..07469f0 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -321,6 +321,25 @@ cmd_S_ttf= \ $(obj)/%.S: $(src)/%.ttf $(call cmd,S_ttf)
+# EFI Hello World application +# --------------------------------------------------------------------------- + +# Generate an assembly file to wrap the EFI app +cmd_S_efi= \ +( \ + echo '.section .rodata.efi.init,"a"'; \ + echo '.balign 16'; \ + echo '.global __efi_hello_world_begin'; \ + echo '__efi_hello_world_begin:'; \ + echo '.incbin "$<" '; \ + echo '__efi_hello_world_end:'; \ + echo '.global __efi_hello_world_end'; \ + echo '.balign 16'; \ +) > $@ + +$(obj)/%.S: $(src)/%.efi + $(call cmd,S_efi) + # ACPI # --------------------------------------------------------------------------- quiet_cmd_acpi_c_asl= ASL $<

Hi Simon,
On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote:
It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/lib/HelloWorld32.efi | Bin 0 -> 11712 bytes arch/arm/lib/Makefile | 6 ++++++ cmd/Kconfig | 10 ++++++++++ cmd/bootefi.c | 26 ++++++++++++++++++++------ include/asm-generic/sections.h | 2 ++ scripts/Makefile.lib | 19 +++++++++++++++++++ 6 files changed, 57 insertions(+), 6 deletions(-) create mode 100644 arch/arm/lib/HelloWorld32.efi
[snip]
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index a8d1557..0f3ea0c 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -29,6 +29,12 @@ obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTM) += zimage.o obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o +ifdef CONFIG_ARM64 +# This option does not work for arm64, as there is no binary.
If so, can we just remove this for arm64?
+obj-$(CONFIG_CMD_BOOTEFI_HELLO) += HelloWorld64.o +else +obj-$(CONFIG_CMD_BOOTEFI_HELLO) += HelloWorld32.o +endif obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o else diff --git a/cmd/Kconfig b/cmd/Kconfig index d69b817..8df80b6 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -172,6 +172,16 @@ config CMD_BOOTEFI help Boot an EFI image from memory.
+config CMD_BOOTEFI_HELLO
bool "Allow booting a standard EFI hello word for testing"
depends on CMD_BOOTEFI
default y if CMD_BOOTEFI && !ARM64
help
This adds a standard EFI hello world application to U-Boot so that
it can be used with the 'bootefi hello' command. This is useful
for testing that EFI is woring at a basic level, and for brining
typo: working, bringing
up EFI support on a new architecture.
config CMD_ELF bool "bootelf, bootvx" default y diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 0536b63..ecf9968 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -229,13 +229,22 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
if (argc < 2) return 1;
saddr = argv[1];
+#ifdef CONFIG_CMD_BOOTEFI_HELLO
if (!strcmp(argv[1], "hello")) {
addr = CONFIG_SYS_LOAD_ADDR;
memcpy((char *)addr, __efi_hello_world_begin,
__efi_hello_world_end - __efi_hello_world_begin);
} else
+#endif
{
saddr = argv[1];
addr = simple_strtoul(saddr, NULL, 16);
addr = simple_strtoul(saddr, NULL, 16);
if (argc > 2) {
sfdt = argv[2];
fdt_addr = simple_strtoul(sfdt, NULL, 16);
if (argc > 2) {
sfdt = argv[2];
fdt_addr = simple_strtoul(sfdt, NULL, 16);
} } printf("## Starting EFI application at 0x%08lx ...\n", addr);
@@ -253,7 +262,12 @@ static char bootefi_help_text[] = "<image address> [fdt address]\n" " - boot EFI payload stored at address <image address>.\n" " If specified, the device tree located at <fdt address> gets\n"
" exposed as EFI configuration table.\n";
" exposed as EFI configuration table.\n"
+#ifdef CONFIG_CMD_BOOTEFI_HELLO
"hello\n"
" - boot a sample Hello Word application stored within U-Boot"
typo: World
+#endif
;
#endif
U_BOOT_CMD( diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h index 328bc62..54ccac9 100644 --- a/include/asm-generic/sections.h +++ b/include/asm-generic/sections.h @@ -22,6 +22,8 @@ extern char __kprobes_text_start[], __kprobes_text_end[]; extern char __entry_text_start[], __entry_text_end[]; extern char __initdata_begin[], __initdata_end[]; extern char __start_rodata[], __end_rodata[]; +extern char __efi_hello_world_begin[]; +extern char __efi_hello_world_end[];
/* Start and end of .ctors section - used for constructor calls. */ extern char __ctors_start[], __ctors_end[]; diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index e720562..07469f0 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -321,6 +321,25 @@ cmd_S_ttf= \ $(obj)/%.S: $(src)/%.ttf $(call cmd,S_ttf)
+# EFI Hello World application +# ---------------------------------------------------------------------------
+# Generate an assembly file to wrap the EFI app +cmd_S_efi= \ +( \
echo '.section .rodata.efi.init,"a"'; \
echo '.balign 16'; \
echo '.global __efi_hello_world_begin'; \
echo '__efi_hello_world_begin:'; \
nits: the ending \ is not aligned with other lines
echo '.incbin "$<" '; \
echo '__efi_hello_world_end:'; \
echo '.global __efi_hello_world_end'; \
nits: the ending \ is not aligned with other lines
echo '.balign 16'; \
+) > $@
+$(obj)/%.S: $(src)/%.efi
$(call cmd,S_efi)
# ACPI # --------------------------------------------------------------------------- quiet_cmd_acpi_c_asl= ASL $< --
Regards, Bin

Hi Bin,
On 9 August 2016 at 00:50, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote:
It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/lib/HelloWorld32.efi | Bin 0 -> 11712 bytes arch/arm/lib/Makefile | 6 ++++++ cmd/Kconfig | 10 ++++++++++ cmd/bootefi.c | 26 ++++++++++++++++++++------ include/asm-generic/sections.h | 2 ++ scripts/Makefile.lib | 19 +++++++++++++++++++ 6 files changed, 57 insertions(+), 6 deletions(-) create mode 100644 arch/arm/lib/HelloWorld32.efi
[snip]
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index a8d1557..0f3ea0c 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -29,6 +29,12 @@ obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTM) += zimage.o obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o +ifdef CONFIG_ARM64 +# This option does not work for arm64, as there is no binary.
If so, can we just remove this for arm64?
Actually I was hoping that Alexander might have a suitable arm64 HelloWorld.efi lying around. When I tried building UEFI for arm64, for some reason it did not create it.
+obj-$(CONFIG_CMD_BOOTEFI_HELLO) += HelloWorld64.o +else +obj-$(CONFIG_CMD_BOOTEFI_HELLO) += HelloWorld32.o +endif obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o else
[...]
Regards, Simon

Am 09.08.2016 um 20:16 schrieb Simon Glass sjg@chromium.org:
Hi Bin,
On 9 August 2016 at 00:50, Bin Meng bmeng.cn@gmail.com wrote: Hi Simon,
On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote: It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/lib/HelloWorld32.efi | Bin 0 -> 11712 bytes arch/arm/lib/Makefile | 6 ++++++ cmd/Kconfig | 10 ++++++++++ cmd/bootefi.c | 26 ++++++++++++++++++++------ include/asm-generic/sections.h | 2 ++ scripts/Makefile.lib | 19 +++++++++++++++++++ 6 files changed, 57 insertions(+), 6 deletions(-) create mode 100644 arch/arm/lib/HelloWorld32.efi
[snip]
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index a8d1557..0f3ea0c 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -29,6 +29,12 @@ obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTM) += zimage.o obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o +ifdef CONFIG_ARM64 +# This option does not work for arm64, as there is no binary.
If so, can we just remove this for arm64?
Actually I was hoping that Alexander might have a suitable arm64 HelloWorld.efi lying around. When I tried building UEFI for arm64, for some reason it did not create it.
Is it part of edk2? If so, Leif (CC'ed) might have one :). I usually use grub as my hello world application.
Alex

On Tue, Aug 09, 2016 at 10:55:31PM +0200, Alexander Graf wrote:
Am 09.08.2016 um 20:16 schrieb Simon Glass sjg@chromium.org:
Hi Bin,
On 9 August 2016 at 00:50, Bin Meng bmeng.cn@gmail.com wrote: Hi Simon,
On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote: It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/lib/HelloWorld32.efi | Bin 0 -> 11712 bytes arch/arm/lib/Makefile | 6 ++++++ cmd/Kconfig | 10 ++++++++++ cmd/bootefi.c | 26 ++++++++++++++++++++------ include/asm-generic/sections.h | 2 ++ scripts/Makefile.lib | 19 +++++++++++++++++++ 6 files changed, 57 insertions(+), 6 deletions(-) create mode 100644 arch/arm/lib/HelloWorld32.efi
[snip]
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index a8d1557..0f3ea0c 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -29,6 +29,12 @@ obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTM) += zimage.o obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o +ifdef CONFIG_ARM64 +# This option does not work for arm64, as there is no binary.
If so, can we just remove this for arm64?
Actually I was hoping that Alexander might have a suitable arm64 HelloWorld.efi lying around. When I tried building UEFI for arm64, for some reason it did not create it.
Is it part of edk2? If so, Leif (CC'ed) might have one :). I usually use grub as my hello world application.
There is a hello world application in EDK2, but it does not get built as part of a normal platform build. Currently it also fails to build for ARM* on its own :| See http://patchew.org/EDK2/1471021908-3509-1-git-send-email-leif.lindholm%40lin... for a hack of how to build one before upstream is resolved.
If cross compiling, prepend GCC5_AARCH64_PREFIX=aarch64-linux-gnu- to build command line.
/ Leif

Hi Leif,
On 15 August 2016 at 06:23, Leif Lindholm leif.lindholm@linaro.org wrote:
On Tue, Aug 09, 2016 at 10:55:31PM +0200, Alexander Graf wrote:
Am 09.08.2016 um 20:16 schrieb Simon Glass sjg@chromium.org:
Hi Bin,
On 9 August 2016 at 00:50, Bin Meng bmeng.cn@gmail.com wrote: Hi Simon,
On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote: It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/lib/HelloWorld32.efi | Bin 0 -> 11712 bytes arch/arm/lib/Makefile | 6 ++++++ cmd/Kconfig | 10 ++++++++++ cmd/bootefi.c | 26 ++++++++++++++++++++------ include/asm-generic/sections.h | 2 ++ scripts/Makefile.lib | 19 +++++++++++++++++++ 6 files changed, 57 insertions(+), 6 deletions(-) create mode 100644 arch/arm/lib/HelloWorld32.efi
[snip]
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index a8d1557..0f3ea0c 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -29,6 +29,12 @@ obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTM) += zimage.o obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o +ifdef CONFIG_ARM64 +# This option does not work for arm64, as there is no binary.
If so, can we just remove this for arm64?
Actually I was hoping that Alexander might have a suitable arm64 HelloWorld.efi lying around. When I tried building UEFI for arm64, for some reason it did not create it.
Is it part of edk2? If so, Leif (CC'ed) might have one :). I usually use grub as my hello world application.
There is a hello world application in EDK2, but it does not get built as part of a normal platform build. Currently it also fails to build for ARM* on its own :| See http://patchew.org/EDK2/1471021908-3509-1-git-send-email-leif.lindholm%40lin... for a hack of how to build one before upstream is resolved.
If cross compiling, prepend GCC5_AARCH64_PREFIX=aarch64-linux-gnu- to build command line.
Thanks for the pointer. Unfortunately that patch appears to make no differences for me. Are you able to build and send me a 64-bit HelloWorld.efi please?
/ Leif
Regards, Simon

On Mon, Sep 26, 2016 at 08:09:40AM -0600, Simon Glass wrote:
If so, can we just remove this for arm64?
Actually I was hoping that Alexander might have a suitable arm64 HelloWorld.efi lying around. When I tried building UEFI for arm64, for some reason it did not create it.
Is it part of edk2? If so, Leif (CC'ed) might have one :). I usually use grub as my hello world application.
There is a hello world application in EDK2, but it does not get built as part of a normal platform build. Currently it also fails to build for ARM* on its own :| See http://patchew.org/EDK2/1471021908-3509-1-git-send-email-leif.lindholm%40lin... for a hack of how to build one before upstream is resolved.
If cross compiling, prepend GCC5_AARCH64_PREFIX=aarch64-linux-gnu- to build command line.
Thanks for the pointer. Unfortunately that patch appears to make no differences for me. Are you able to build and send me a 64-bit HelloWorld.efi please?
So, I probably could, but if that isn't working for you, I'd quite like to know why.
To make that a little less painful though, I've added support for building the helloworld app to my set of scripts: https://git.linaro.org/uefi/uefi-tools.git
This still depends on this (updated) patch. https://lists.01.org/pipermail/edk2-devel/2016-September/002112.html
But with a current edk2, and a uefi-tools placed in the same directory as the edk2 clone, could you try executing:
../uefi-tools/uefi-build.sh -A AARCH64 hello
If the build fails and creates messy output due to being parallel, could you stick a -1 on that command line and send me the output (or pastebin)?
/ Leif

Hi Leif,
On 26 September 2016 at 19:53, Leif Lindholm leif.lindholm@linaro.org wrote:
On Mon, Sep 26, 2016 at 08:09:40AM -0600, Simon Glass wrote:
If so, can we just remove this for arm64?
Actually I was hoping that Alexander might have a suitable arm64 HelloWorld.efi lying around. When I tried building UEFI for arm64, for some reason it did not create it.
Is it part of edk2? If so, Leif (CC'ed) might have one :). I usually use grub as my hello world application.
There is a hello world application in EDK2, but it does not get built as part of a normal platform build. Currently it also fails to build for ARM* on its own :| See http://patchew.org/EDK2/1471021908-3509-1-git-send-email-leif.lindholm%40lin... for a hack of how to build one before upstream is resolved.
If cross compiling, prepend GCC5_AARCH64_PREFIX=aarch64-linux-gnu- to build command line.
Thanks for the pointer. Unfortunately that patch appears to make no differences for me. Are you able to build and send me a 64-bit HelloWorld.efi please?
So, I probably could, but if that isn't working for you, I'd quite like to know why.
To make that a little less painful though, I've added support for building the helloworld app to my set of scripts: https://git.linaro.org/uefi/uefi-tools.git
This still depends on this (updated) patch. https://lists.01.org/pipermail/edk2-devel/2016-September/002112.html
But with a current edk2, and a uefi-tools placed in the same directory as the edk2 clone, could you try executing:
../uefi-tools/uefi-build.sh -A AARCH64 hello
If the build fails and creates messy output due to being parallel, could you stick a -1 on that command line and send me the output (or pastebin)?
OK thanks. Please see:
Regards, Simon

On Mon, Oct 17, 2016 at 07:55:02PM -0600, Simon Glass wrote:
Hi Leif,
On 26 September 2016 at 19:53, Leif Lindholm leif.lindholm@linaro.org wrote:
Thanks for the pointer. Unfortunately that patch appears to make no differences for me. Are you able to build and send me a 64-bit HelloWorld.efi please?
So, I probably could, but if that isn't working for you, I'd quite like to know why.
To make that a little less painful though, I've added support for building the helloworld app to my set of scripts: https://git.linaro.org/uefi/uefi-tools.git
This still depends on this (updated) patch. https://lists.01.org/pipermail/edk2-devel/2016-September/002112.html
But with a current edk2, and a uefi-tools placed in the same directory as the edk2 clone, could you try executing:
../uefi-tools/uefi-build.sh -A AARCH64 hello
If the build fails and creates messy output due to being parallel, could you stick a -1 on that command line and send me the output (or pastebin)?
OK thanks. Please see:
Right ... so your terminal appears to be discarding stderr, but I'm guessing with that enabled it would look like: --- Processing meta-data ..
build.py... /work/git/edk2/MdeModulePkg/MdeModulePkg.dsc(...): error 4000: Instance of library class [ArmMmuLib] is not found in [/work/git/edk2/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf] [AARCH64] consumed by module [/work/git/edk2/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf]
- Failed - Build end time: 16:51:18, Oct.19 2016 Build total time: 00:00:03 ---
Which is what it looks without the aforementioned patch applied.
(But the no error messages thing really spooks me.)
/ Leif

On 19 October 2016 at 21:22, Leif Lindholm leif.lindholm@linaro.org wrote:
On Mon, Oct 17, 2016 at 07:55:02PM -0600, Simon Glass wrote:
Hi Leif,
On 26 September 2016 at 19:53, Leif Lindholm leif.lindholm@linaro.org wrote:
Thanks for the pointer. Unfortunately that patch appears to make no differences for me. Are you able to build and send me a 64-bit HelloWorld.efi please?
So, I probably could, but if that isn't working for you, I'd quite like to know why.
To make that a little less painful though, I've added support for building the helloworld app to my set of scripts: https://git.linaro.org/uefi/uefi-tools.git
This still depends on this (updated) patch. https://lists.01.org/pipermail/edk2-devel/2016-September/002112.html
But with a current edk2, and a uefi-tools placed in the same directory as the edk2 clone, could you try executing:
../uefi-tools/uefi-build.sh -A AARCH64 hello
If the build fails and creates messy output due to being parallel, could you stick a -1 on that command line and send me the output (or pastebin)?
OK thanks. Please see:
Right ... so your terminal appears to be discarding stderr, but I'm guessing with that enabled it would look like:
Processing meta-data ..
build.py... /work/git/edk2/MdeModulePkg/MdeModulePkg.dsc(...): error 4000: Instance of library class [ArmMmuLib] is not found in [/work/git/edk2/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf] [AARCH64] consumed by module [/work/git/edk2/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf]
- Failed -
Build end time: 16:51:18, Oct.19 2016 Build total time: 00:00:03
Which is what it looks without the aforementioned patch applied.
As a follow-up: I have now pushed the required patch to edk2, so with a fresh pull it should work without any manually added patches.
/ Leif

Hi Leif,
On 20 October 2016 at 02:19, Leif Lindholm leif.lindholm@linaro.org wrote:
On 19 October 2016 at 21:22, Leif Lindholm leif.lindholm@linaro.org wrote:
On Mon, Oct 17, 2016 at 07:55:02PM -0600, Simon Glass wrote:
Hi Leif,
On 26 September 2016 at 19:53, Leif Lindholm leif.lindholm@linaro.org wrote:
Thanks for the pointer. Unfortunately that patch appears to make no differences for me. Are you able to build and send me a 64-bit HelloWorld.efi please?
So, I probably could, but if that isn't working for you, I'd quite like to know why.
To make that a little less painful though, I've added support for building the helloworld app to my set of scripts: https://git.linaro.org/uefi/uefi-tools.git
This still depends on this (updated) patch. https://lists.01.org/pipermail/edk2-devel/2016-September/002112.html
But with a current edk2, and a uefi-tools placed in the same directory as the edk2 clone, could you try executing:
../uefi-tools/uefi-build.sh -A AARCH64 hello
If the build fails and creates messy output due to being parallel, could you stick a -1 on that command line and send me the output (or pastebin)?
OK thanks. Please see:
Right ... so your terminal appears to be discarding stderr, but I'm guessing with that enabled it would look like:
Processing meta-data ..
build.py... /work/git/edk2/MdeModulePkg/MdeModulePkg.dsc(...): error 4000: Instance of library class [ArmMmuLib] is not found in [/work/git/edk2/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf] [AARCH64] consumed by module [/work/git/edk2/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf]
- Failed -
Build end time: 16:51:18, Oct.19 2016 Build total time: 00:00:03
Which is what it looks without the aforementioned patch applied.
I really thought I applied it. But I don't understand the UEFI build system at all...
As a follow-up: I have now pushed the required patch to edk2, so with a fresh pull it should work without any manually added patches.
I think I'm going to build a simple hello world within the U-Boot tree, to avoiding needing to package a binary.
Regards, Simon

Add the required pieces to support the EFI loader on x86.
Since U-Boot only builds for 32-bit on x86, only a 32-bit EFI application is supported. If a 64-bit kernel must be booted, U-Boot supports this directly using FIT (see doc/uImage.FIT/kernel.its). U-Boot can act as a payload for both 32-bit and 64-bit EFI.
Signed-off-by: Simon Glass sjg@chromium.org ---
arch/x86/cpu/u-boot.lds | 36 +++++++++++++++++++++++++++++++++++- arch/x86/lib/Makefile | 1 + arch/x86/lib/sections.c | 12 ++++++++++++ include/efi.h | 3 ++- lib/efi_loader/efi_boottime.c | 9 +++++++++ lib/efi_loader/efi_runtime.c | 4 ++++ 6 files changed, 63 insertions(+), 2 deletions(-) create mode 100644 arch/x86/lib/sections.c
diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds index 36f59ea..cca536b 100644 --- a/arch/x86/cpu/u-boot.lds +++ b/arch/x86/cpu/u-boot.lds @@ -28,7 +28,10 @@ SECTIONS }
. = ALIGN(4); - .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } + .rodata : { + *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) + KEEP(*(.rodata.efi.init)); + }
. = ALIGN(4); .data : { *(.data*) } @@ -40,6 +43,37 @@ SECTIONS .got : { *(.got*) }
. = ALIGN(4); + + .__efi_runtime_start : { + *(.__efi_runtime_start) + } + + .efi_runtime : { + *(efi_runtime_text) + *(efi_runtime_data) + } + + .__efi_runtime_stop : { + *(.__efi_runtime_stop) + } + + .efi_runtime_rel_start : + { + *(.__efi_runtime_rel_start) + } + + .efi_runtime_rel : { + *(.relefi_runtime_text) + *(.relefi_runtime_data) + } + + .efi_runtime_rel_stop : + { + *(.__efi_runtime_rel_stop) + } + + . = ALIGN(4); + __data_end = .; __init_end = .;
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index e17f0bb..e46e7f1 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -28,6 +28,7 @@ obj-y += pirq_routing.o obj-y += relocate.o obj-y += physmem.o obj-$(CONFIG_X86_RAMTEST) += ramtest.o +obj-y += sections.o obj-y += sfi.o obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o obj-y += string.o diff --git a/arch/x86/lib/sections.c b/arch/x86/lib/sections.c new file mode 100644 index 0000000..6455e0f --- /dev/null +++ b/arch/x86/lib/sections.c @@ -0,0 +1,12 @@ +/* + * Copyright 2013 Albert ARIBAUD albert.u.boot@aribaud.net + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +char __efi_runtime_start[0] __attribute__((section(".__efi_runtime_start"))); +char __efi_runtime_stop[0] __attribute__((section(".__efi_runtime_stop"))); +char __efi_runtime_rel_start[0] + __attribute__((section(".__efi_runtime_rel_start"))); +char __efi_runtime_rel_stop[0] + __attribute__((section(".__efi_runtime_rel_stop"))); diff --git a/include/efi.h b/include/efi.h index 1dbc3b7..47b351f 100644 --- a/include/efi.h +++ b/include/efi.h @@ -15,6 +15,7 @@ #ifndef _EFI_H #define _EFI_H
+#include <linux/linkage.h> #include <linux/string.h> #include <linux/types.h>
@@ -22,7 +23,7 @@ /* EFI uses the Microsoft ABI which is not the default for GCC */ #define EFIAPI __attribute__((ms_abi)) #else -#define EFIAPI +#define EFIAPI asmlinkage #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
/* Called from do_bootefi_exec() */ void efi_save_gd(void) { +#ifdef CONFIG_ARM efi_gd = gd; +#endif }
/* Called on every callback entry */ void efi_restore_gd(void) { +#ifdef CONFIG_ARM /* Only restore if we're already in EFI context */ if (!efi_gd) return; @@ -63,12 +68,16 @@ void efi_restore_gd(void) if (gd != efi_gd) app_gd = gd; gd = efi_gd; +#endif }
/* Called on every callback exit */ efi_status_t efi_exit_func(efi_status_t ret) { +#ifdef CONFIG_ARM gd = app_gd; +#endif + return ret; }
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c index 99b5ef1..3793471 100644 --- a/lib/efi_loader/efi_runtime.c +++ b/lib/efi_loader/efi_runtime.c @@ -34,6 +34,10 @@ static efi_status_t EFI_RUNTIME_TEXT EFIAPI efi_invalid_parameter(void); #elif defined(CONFIG_ARM) #define R_RELATIVE 23 #define R_MASK 0xffULL +#elif defined(CONFIG_X86) +#include <asm/elf.h> +#define R_RELATIVE R_386_RELATIVE +#define R_MASK 0xffULL #else #error Need to add relocation awareness #endif

On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote:
Add the required pieces to support the EFI loader on x86.
Since U-Boot only builds for 32-bit on x86, only a 32-bit EFI application is supported. If a 64-bit kernel must be booted, U-Boot supports this directly using FIT (see doc/uImage.FIT/kernel.its). U-Boot can act as a payload for both 32-bit and 64-bit EFI.
Signed-off-by: Simon Glass sjg@chromium.org
arch/x86/cpu/u-boot.lds | 36 +++++++++++++++++++++++++++++++++++- arch/x86/lib/Makefile | 1 + arch/x86/lib/sections.c | 12 ++++++++++++ include/efi.h | 3 ++- lib/efi_loader/efi_boottime.c | 9 +++++++++ lib/efi_loader/efi_runtime.c | 4 ++++ 6 files changed, 63 insertions(+), 2 deletions(-) create mode 100644 arch/x86/lib/sections.c
Reviewed-by: Bin Meng bmeng.cn@gmail.com

On 08/07/2016 01:23 AM, Simon Glass wrote:
Add the required pieces to support the EFI loader on x86.
Since U-Boot only builds for 32-bit on x86, only a 32-bit EFI application is supported. If a 64-bit kernel must be booted, U-Boot supports this directly using FIT (see doc/uImage.FIT/kernel.its). U-Boot can act as a payload for both 32-bit and 64-bit EFI.
Signed-off-by: Simon Glass sjg@chromium.org
arch/x86/cpu/u-boot.lds | 36 +++++++++++++++++++++++++++++++++++- arch/x86/lib/Makefile | 1 + arch/x86/lib/sections.c | 12 ++++++++++++ include/efi.h | 3 ++- lib/efi_loader/efi_boottime.c | 9 +++++++++ lib/efi_loader/efi_runtime.c | 4 ++++ 6 files changed, 63 insertions(+), 2 deletions(-) create mode 100644 arch/x86/lib/sections.c
diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds index 36f59ea..cca536b 100644 --- a/arch/x86/cpu/u-boot.lds +++ b/arch/x86/cpu/u-boot.lds @@ -28,7 +28,10 @@ SECTIONS }
. = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
.rodata : {
*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
KEEP(*(.rodata.efi.init));
}
. = ALIGN(4); .data : { *(.data*) }
@@ -40,6 +43,37 @@ SECTIONS .got : { *(.got*) }
. = ALIGN(4);
- .__efi_runtime_start : {
*(.__efi_runtime_start)
- }
- .efi_runtime : {
*(efi_runtime_text)
*(efi_runtime_data)
- }
- .__efi_runtime_stop : {
*(.__efi_runtime_stop)
- }
- .efi_runtime_rel_start :
- {
*(.__efi_runtime_rel_start)
- }
- .efi_runtime_rel : {
*(.relefi_runtime_text)
*(.relefi_runtime_data)
- }
- .efi_runtime_rel_stop :
- {
*(.__efi_runtime_rel_stop)
- }
- . = ALIGN(4);
- __data_end = .; __init_end = .;
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index e17f0bb..e46e7f1 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -28,6 +28,7 @@ obj-y += pirq_routing.o obj-y += relocate.o obj-y += physmem.o obj-$(CONFIG_X86_RAMTEST) += ramtest.o +obj-y += sections.o obj-y += sfi.o obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o obj-y += string.o diff --git a/arch/x86/lib/sections.c b/arch/x86/lib/sections.c new file mode 100644 index 0000000..6455e0f --- /dev/null +++ b/arch/x86/lib/sections.c @@ -0,0 +1,12 @@ +/*
- Copyright 2013 Albert ARIBAUD albert.u.boot@aribaud.net
- SPDX-License-Identifier: GPL-2.0+
- */
+char __efi_runtime_start[0] __attribute__((section(".__efi_runtime_start"))); +char __efi_runtime_stop[0] __attribute__((section(".__efi_runtime_stop"))); +char __efi_runtime_rel_start[0]
__attribute__((section(".__efi_runtime_rel_start")));
+char __efi_runtime_rel_stop[0]
__attribute__((section(".__efi_runtime_rel_stop")));
diff --git a/include/efi.h b/include/efi.h index 1dbc3b7..47b351f 100644 --- a/include/efi.h +++ b/include/efi.h @@ -15,6 +15,7 @@ #ifndef _EFI_H #define _EFI_H
+#include <linux/linkage.h> #include <linux/string.h> #include <linux/types.h>
@@ -22,7 +23,7 @@ /* EFI uses the Microsoft ABI which is not the default for GCC */ #define EFIAPI __attribute__((ms_abi)) #else -#define EFIAPI +#define EFIAPI asmlinkage
Ah, this should trigger what I mentioned in my previous email. Since linkage.h is now included in efi.h, we no longer have to include the header in bootefi.c explicitly. How about you just move this part of the patch between patches 1/6 and 2/6?
#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?
Alex

Hi Alex,
On 10 August 2016 at 05:49, Alexander Graf agraf@suse.de wrote:
On 08/07/2016 01:23 AM, Simon Glass wrote:
Add the required pieces to support the EFI loader on x86.
Since U-Boot only builds for 32-bit on x86, only a 32-bit EFI application is supported. If a 64-bit kernel must be booted, U-Boot supports this directly using FIT (see doc/uImage.FIT/kernel.its). U-Boot can act as a payload for both 32-bit and 64-bit EFI.
Signed-off-by: Simon Glass sjg@chromium.org
arch/x86/cpu/u-boot.lds | 36 +++++++++++++++++++++++++++++++++++- arch/x86/lib/Makefile | 1 + arch/x86/lib/sections.c | 12 ++++++++++++ include/efi.h | 3 ++- lib/efi_loader/efi_boottime.c | 9 +++++++++ lib/efi_loader/efi_runtime.c | 4 ++++ 6 files changed, 63 insertions(+), 2 deletions(-) create mode 100644 arch/x86/lib/sections.c
diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds index 36f59ea..cca536b 100644 --- a/arch/x86/cpu/u-boot.lds +++ b/arch/x86/cpu/u-boot.lds @@ -28,7 +28,10 @@ SECTIONS } . = ALIGN(4);
.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
.rodata : {
*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
KEEP(*(.rodata.efi.init));
} . = ALIGN(4); .data : { *(.data*) }
@@ -40,6 +43,37 @@ SECTIONS .got : { *(.got*) } . = ALIGN(4);
.__efi_runtime_start : {
*(.__efi_runtime_start)
}
.efi_runtime : {
*(efi_runtime_text)
*(efi_runtime_data)
}
.__efi_runtime_stop : {
*(.__efi_runtime_stop)
}
.efi_runtime_rel_start :
{
*(.__efi_runtime_rel_start)
}
.efi_runtime_rel : {
*(.relefi_runtime_text)
*(.relefi_runtime_data)
}
.efi_runtime_rel_stop :
{
*(.__efi_runtime_rel_stop)
}
. = ALIGN(4);
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile__data_end = .; __init_end = .;
index e17f0bb..e46e7f1 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -28,6 +28,7 @@ obj-y += pirq_routing.o obj-y += relocate.o obj-y += physmem.o obj-$(CONFIG_X86_RAMTEST) += ramtest.o +obj-y += sections.o obj-y += sfi.o obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o obj-y += string.o diff --git a/arch/x86/lib/sections.c b/arch/x86/lib/sections.c new file mode 100644 index 0000000..6455e0f --- /dev/null +++ b/arch/x86/lib/sections.c @@ -0,0 +1,12 @@ +/*
- Copyright 2013 Albert ARIBAUD albert.u.boot@aribaud.net
- SPDX-License-Identifier: GPL-2.0+
- */
+char __efi_runtime_start[0] __attribute__((section(".__efi_runtime_start"))); +char __efi_runtime_stop[0] __attribute__((section(".__efi_runtime_stop"))); +char __efi_runtime_rel_start[0]
__attribute__((section(".__efi_runtime_rel_start")));
+char __efi_runtime_rel_stop[0]
__attribute__((section(".__efi_runtime_rel_stop")));
diff --git a/include/efi.h b/include/efi.h index 1dbc3b7..47b351f 100644 --- a/include/efi.h +++ b/include/efi.h @@ -15,6 +15,7 @@ #ifndef _EFI_H #define _EFI_H +#include <linux/linkage.h> #include <linux/string.h> #include <linux/types.h> @@ -22,7 +23,7 @@ /* EFI uses the Microsoft ABI which is not the default for GCC */ #define EFIAPI __attribute__((ms_abi)) #else -#define EFIAPI +#define EFIAPI asmlinkage
Ah, this should trigger what I mentioned in my previous email. Since linkage.h is now included in efi.h, we no longer have to include the header in bootefi.c explicitly. How about you just move this part of the patch between patches 1/6 and 2/6?
OK will take a look.
#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.
This series was just an attempt to get the EFI loader working on x86. 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.
Alex
Regards, Simon

On 08/10/2016 02:56 PM, Simon Glass wrote:
Hi Alex,
On 10 August 2016 at 05:49, Alexander Graf agraf@suse.de wrote:
On 08/07/2016 01:23 AM, Simon Glass wrote:
Add the required pieces to support the EFI loader on x86.
Since U-Boot only builds for 32-bit on x86, only a 32-bit EFI application is supported. If a 64-bit kernel must be booted, U-Boot supports this directly using FIT (see doc/uImage.FIT/kernel.its). U-Boot can act as a payload for both 32-bit and 64-bit EFI.
Signed-off-by: Simon Glass sjg@chromium.org
arch/x86/cpu/u-boot.lds | 36 +++++++++++++++++++++++++++++++++++- arch/x86/lib/Makefile | 1 + arch/x86/lib/sections.c | 12 ++++++++++++ include/efi.h | 3 ++- lib/efi_loader/efi_boottime.c | 9 +++++++++ lib/efi_loader/efi_runtime.c | 4 ++++ 6 files changed, 63 insertions(+), 2 deletions(-) create mode 100644 arch/x86/lib/sections.c
diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds index 36f59ea..cca536b 100644 --- a/arch/x86/cpu/u-boot.lds +++ b/arch/x86/cpu/u-boot.lds @@ -28,7 +28,10 @@ SECTIONS } . = ALIGN(4);
.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
.rodata : {
*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
KEEP(*(.rodata.efi.init));
} . = ALIGN(4); .data : { *(.data*) }
@@ -40,6 +43,37 @@ SECTIONS .got : { *(.got*) } . = ALIGN(4);
.__efi_runtime_start : {
*(.__efi_runtime_start)
}
.efi_runtime : {
*(efi_runtime_text)
*(efi_runtime_data)
}
.__efi_runtime_stop : {
*(.__efi_runtime_stop)
}
.efi_runtime_rel_start :
{
*(.__efi_runtime_rel_start)
}
.efi_runtime_rel : {
*(.relefi_runtime_text)
*(.relefi_runtime_data)
}
.efi_runtime_rel_stop :
{
*(.__efi_runtime_rel_stop)
}
. = ALIGN(4);
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile__data_end = .; __init_end = .;
index e17f0bb..e46e7f1 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -28,6 +28,7 @@ obj-y += pirq_routing.o obj-y += relocate.o obj-y += physmem.o obj-$(CONFIG_X86_RAMTEST) += ramtest.o +obj-y += sections.o obj-y += sfi.o obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o obj-y += string.o diff --git a/arch/x86/lib/sections.c b/arch/x86/lib/sections.c new file mode 100644 index 0000000..6455e0f --- /dev/null +++ b/arch/x86/lib/sections.c @@ -0,0 +1,12 @@ +/*
- Copyright 2013 Albert ARIBAUD albert.u.boot@aribaud.net
- SPDX-License-Identifier: GPL-2.0+
- */
+char __efi_runtime_start[0] __attribute__((section(".__efi_runtime_start"))); +char __efi_runtime_stop[0] __attribute__((section(".__efi_runtime_stop"))); +char __efi_runtime_rel_start[0]
__attribute__((section(".__efi_runtime_rel_start")));
+char __efi_runtime_rel_stop[0]
__attribute__((section(".__efi_runtime_rel_stop")));
diff --git a/include/efi.h b/include/efi.h index 1dbc3b7..47b351f 100644 --- a/include/efi.h +++ b/include/efi.h @@ -15,6 +15,7 @@ #ifndef _EFI_H #define _EFI_H +#include <linux/linkage.h> #include <linux/string.h> #include <linux/types.h> @@ -22,7 +23,7 @@ /* EFI uses the Microsoft ABI which is not the default for GCC */ #define EFIAPI __attribute__((ms_abi)) #else -#define EFIAPI +#define EFIAPI asmlinkage
Ah, this should trigger what I mentioned in my previous email. Since linkage.h is now included in efi.h, we no longer have to include the header in bootefi.c explicitly. How about you just move this part of the patch between patches 1/6 and 2/6?
OK will take a look.
#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.
Well, FS is a typical TLS register, so there's a good chance it is reserved for something. At least the EFI payload on x86 does explicitly not use fs, so maybe you are safe. Just double-check the spec :).
This series was just an attempt to get the EFI loader working on x86. 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, and it makes me happy so see how little effort it is to make x86 work :). Now we just need to wrap all the tables as well and you should be able to run Linux!
Alex

On 10/08/2016 14:56, Simon Glass wrote:
Hi Alex,
On 10 August 2016 at 05:49, Alexander Graf agraf@suse.de wrote:
On 08/07/2016 01:23 AM, Simon Glass wrote:
Add the required pieces to support the EFI loader on x86.
Since U-Boot only builds for 32-bit on x86, only a 32-bit EFI application is supported. If a 64-bit kernel must be booted, U-Boot supports this directly using FIT (see doc/uImage.FIT/kernel.its). U-Boot can act as a payload for both 32-bit and 64-bit EFI.
Signed-off-by: Simon Glass sjg@chromium.org
arch/x86/cpu/u-boot.lds | 36 +++++++++++++++++++++++++++++++++++- arch/x86/lib/Makefile | 1 + arch/x86/lib/sections.c | 12 ++++++++++++ include/efi.h | 3 ++- lib/efi_loader/efi_boottime.c | 9 +++++++++ lib/efi_loader/efi_runtime.c | 4 ++++ 6 files changed, 63 insertions(+), 2 deletions(-) create mode 100644 arch/x86/lib/sections.c
diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds index 36f59ea..cca536b 100644 --- a/arch/x86/cpu/u-boot.lds +++ b/arch/x86/cpu/u-boot.lds @@ -28,7 +28,10 @@ SECTIONS } . = ALIGN(4);
.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
.rodata : {
*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
KEEP(*(.rodata.efi.init));
} . = ALIGN(4); .data : { *(.data*) }
@@ -40,6 +43,37 @@ SECTIONS .got : { *(.got*) } . = ALIGN(4);
.__efi_runtime_start : {
*(.__efi_runtime_start)
}
.efi_runtime : {
*(efi_runtime_text)
*(efi_runtime_data)
}
.__efi_runtime_stop : {
*(.__efi_runtime_stop)
}
.efi_runtime_rel_start :
{
*(.__efi_runtime_rel_start)
}
.efi_runtime_rel : {
*(.relefi_runtime_text)
*(.relefi_runtime_data)
}
.efi_runtime_rel_stop :
{
*(.__efi_runtime_rel_stop)
}
. = ALIGN(4);
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile__data_end = .; __init_end = .;
index e17f0bb..e46e7f1 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -28,6 +28,7 @@ obj-y += pirq_routing.o obj-y += relocate.o obj-y += physmem.o obj-$(CONFIG_X86_RAMTEST) += ramtest.o +obj-y += sections.o obj-y += sfi.o obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o obj-y += string.o diff --git a/arch/x86/lib/sections.c b/arch/x86/lib/sections.c new file mode 100644 index 0000000..6455e0f --- /dev/null +++ b/arch/x86/lib/sections.c @@ -0,0 +1,12 @@ +/*
- Copyright 2013 Albert ARIBAUD albert.u.boot@aribaud.net
- SPDX-License-Identifier: GPL-2.0+
- */
+char __efi_runtime_start[0] __attribute__((section(".__efi_runtime_start"))); +char __efi_runtime_stop[0] __attribute__((section(".__efi_runtime_stop"))); +char __efi_runtime_rel_start[0]
__attribute__((section(".__efi_runtime_rel_start")));
+char __efi_runtime_rel_stop[0]
__attribute__((section(".__efi_runtime_rel_stop")));
diff --git a/include/efi.h b/include/efi.h index 1dbc3b7..47b351f 100644 --- a/include/efi.h +++ b/include/efi.h @@ -15,6 +15,7 @@ #ifndef _EFI_H #define _EFI_H +#include <linux/linkage.h> #include <linux/string.h> #include <linux/types.h> @@ -22,7 +23,7 @@ /* EFI uses the Microsoft ABI which is not the default for GCC */ #define EFIAPI __attribute__((ms_abi)) #else -#define EFIAPI +#define EFIAPI asmlinkage
Ah, this should trigger what I mentioned in my previous email. Since linkage.h is now included in efi.h, we no longer have to include the header in bootefi.c explicitly. How about you just move this part of the patch between patches 1/6 and 2/6?
OK will take a look.
#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.
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.
Alex

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

It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
Signed-off-by: Simon Glass sjg@chromium.org ---
arch/x86/lib/HelloWorld.efi | Bin 0 -> 11168 bytes arch/x86/lib/Makefile | 1 + 2 files changed, 1 insertion(+) create mode 100644 arch/x86/lib/HelloWorld.efi
diff --git a/arch/x86/lib/HelloWorld.efi b/arch/x86/lib/HelloWorld.efi new file mode 100644 index 0000000000000000000000000000000000000000..e59b84b4d1d5f5aeabb4f25094ec0724ac114b4e GIT binary patch literal 11168 zcmcIq3v?6LnI0KK1u+>zTxuF884^e=UY2B8wgV=9jROIJkdVn^9jaKuk|Rq*nhB=G ziRnluOefytoGmT8C3~EO?QwVM3EOo8%}J>p5)8Ci2%EIoxF;cLI2o^Kwn+&VgjD<8 zxg%MAkTlt|&bgZV_#fZ@-~ayipCOL>nXmlU{gpY#7@a)BtTW_~O`vy<x!!P{fnm6L z3{yLYF4g9tkM^x%I_B^oZQ@_=5=uwrXH8tx$A#CJpK7|-1bM)6ZZX3QOhxb&=avip zP651{jj${8%oWGM+~q#6;Kd~I1F=2x%%!UZwB=EMDAG!?W-yay?jPvtm;3w=iEY%D zj7{X3`$y<<$Dh~t$mcgVyQK>S%GbI145NrfrKKQoR+v@oHXgx5cl1`L)7`8tfROv| zL+3#_Qy#kaestHPE4^GOr+WMsA9!#}%dw2GB1J4vT8zzZwF9n^htw04GCm+U66qal zR6C|ID23ht1b3@8Oh6RoikzDR#8Gs9A7yj~c9E%LpbhLnPrX5(cS6U0s>3%y$61WW z={S=m7_Xy>&TpnVj%Rf|haNC(+z1^{OoJWAR3<CJkr;*@;fXpzS%M;$JI9XKsVv=& zlUW^W>3og@H7~Y|V4i_H-IifzcTE5r!3a05xM?Liu^ZsEhCnU4>g&{P$@7*0rRC~L zvH|X07YZ<&77Np2L0UBSJd^q?oel&+9$>KGRu$OtZ0|RTaa>|Rn4{F%@R;Rtxt(ce zJ}mBC3gW&(;cM!@%w?G5%sx(-t~wFGnhtFhidv*|23=u3<RWa;chl)KTs}WBEPj1s zU?-%s*988K0BywzB&$uJOz=jbyoWDzx&y?Y6rfxE36^wNg;T;Bul<aw>sNSVVtOf* zw6J>yG(c`l0nYvduu*kTOgBq4WXKR;pAcZ>fw^S))L%4U@=e4cDwicDLlC<HF?8Ci zDe*IuSZP?fe;*<L2xHg_*<=WEXW$7!eitPVQ}VIBkuDe&zCfw1+Q0Bdu>UN}PKFwL zA7L*Gyhx;%W!SZS)laEdpniw4-6(Y#!LynAxgk(WM1G3BCVt+m(_G?>2I1@OKnRQN zjg;nhI!!sHnV+~sobnW*;3>t=DaEr3;V1-K&rT+9v+6<s;0Sz1*D~Ae3cO9cc@JgW zNf))?Gj4XPUYG?qi2->?C{A3$;YKb=H<KVs3>?8C!>&$2gIk>e={N;)Dw9ZvUcSJo zMMQerQbe+P34q}X%K(D!nCIClDAs!N`DR5dbR*-aTL1vizIo{w%-$H-Ujl4*2Y!u* zdhRN9%}Ppg)97&oA0uFk3vU9|YD)D2rE)s4QSCTIMX#yNfm%>H-Rc$4_xOQOJEQK6 zMB#^^hr*kP!eW=EFz^=WsI<^TY4FTzYI`k&{S-u*GmE(B;ftKvGpjy>I3$*ymCq}V zB80PB{`FwexPmW;&0FCq?3yEW6&rRNg=xF*HB94+>yzgn&@hoqUI<tK-y>dBJcY-n zG0hFI!sS%&oDGGJi*Wt-WZSI_v->*vwV8wBIanmWsoMnZcBY3f29%;PG&q>dSPbq| zx}c(9bco^LzQV*X-AA4`%DgdYu?!@J+4w63@c7wJ_2WSTwb-deN`R!yfC!JP8?X#C za!NW^E2Rwc2W0+$#2?5baV^YV%Rbj~U|Ne&ZrPjs+7Q1N7#QdTx6q(=Qpt-EBtWVL zVVV|FVsUf8eKQpFWVMW3(X<Tl-%qC*W{BTMtV!0X72`!bHzvXz5QvC9SrI=T69Ha` zzzU=AxaEq5_$Se4*rT-u_W5~(=ZrJY+{S-j=8s^{WWG<~k06!JQ^Y={WpCmVyNB<t zemnZj?yhb|D54%@<G)6oqwr6TJboR+?E0W~0c=UlX5)Kjkj^6EdMP!FO<cuj<TQSU z_<o{si0>sRhWMw+NC76`(I8F0BBhqGaZ-(Kw@RtSY`m0oZ%7QV@%PY^QXCuq3=)#7 zrPLBO{@>_IsikcEBQj@`Qq|jUl2R5{x=$ls&c=VPQJC3yHD;1?rPMk${u^yB#Ky@5 zEv0<0pN$_Tit445n~mR!8)y4Bh#m1qrxOa8w-}v~A8I2n8=nCRDb>ox*J_=6+4#4> zKC)d~kFoJ{*tPAPl-kC|8#N?RP@w9RQf=sfXJnm5Dzb4i*4gi#*W`4v@f(SpGA!;o z%^1;r4M{{gZ5TPJJ@ZBewP*gwFSMs|<lnSs;mA+$#14T)<iHC3QdbEh&Qkbdg^~HE zlf?>OLVF9fm3jI~FP_pszRVYo_#s25!fc5)TQaf%v+@<`6i3CgjaL-UzG)uBlD4yw zYL;JH;@BspW^TXbVMqTg!wLB{neS(h)*;4bPV?*|VRiyxmV6y#REX>-ViWvK5()hj zEg+7ZN2)_;4Ds3#HSti<iydM{ZXvGw;G}dKrgdXNzI<u0Tbw1m`&sv^waGmBvV1~1 zS12yl44bQT6)P>pN~LrxUmhJy-;%st=_*lLN^)lI&?s-nP%4k-OUH0@i<5IQq?xG_ z`IPitzI4U#vnBI~NB>j$19xdKkLBMY0M^PU2GwZ`4ZHb60>HcjxY#`gC1dfWS8Bx@ zq?380Z%e;pj^M;FqwoCtvgA_vls4G)USTb^_zHtx@f((O5)m%W0ArpdeT2L(9On-) z&dtp|{7X*R(XXDNM_O_8OI^K;I9vXB<`v!lg0ZLTB~uC>hcADHFk&ocd&HLv$45uy zl<7?3EX$vfy80Q}b5NMm-F1i&t^=Xv?CQ}`1K%GX7G|XR{xsh!pZ=KvTLI;l264#V zgrrM@1~ze;bY970<H*g}uHNqRMz#_0v<}2%TS%16Cb49uQIv%E5`9pDyZX9aAEc4H zj+P=xf!%V_a@I1OiGqW~PPTDS=6grBLcS&qiJ_Q1jG%on8=A?v5Sp3O1C#2voE_p1 z!f3`aOl0+lFOJ-l5v0M=gPX#lgA$VRzeA1)xyn!B%*gzqo`!rmf1&z4jM&3}>S>rk zMmx#qc{eM)T%b4(xzN3yJv>03v&l~Z`MHk#%pyNC$&b<HY({wkYulOj+sOv1uFE8+ z*N&V9OwGbVMZ|F|mX7D+M2f}9>xs)m98b*1VhPE1ACt83ymLArLaH<0#U3ssooV=~ z&2t6@aus}(A_~mOM{=e2tS8bPInpsBJ0N|>eEFqa@8QmVyyu>@beY@EDYiWa7a%_t zNU7=D=PI_uUW|HLUaEeZO*{r9K;aC$m8<eGO(mCcKK7Kl|D}<C1id2eGl*J($3fRF zn>m@w25D8xx8ya(Bo>iqIBJJvT@sNp^1wI|ExL#s#zf54M0^5&Ld3`)@w`Sf92sGW ztd@O-mTTQN6wa@Rtd=R^=m%}&Fh~@~J_D(6ij-@h5_XszMM>dWaCBM8@C3&ly&En_ zZk;&0g3LN6%qH)eFmbeskeQ~M)%EF_Nxy#O)FSQZqKG*uJ9h8#?`90?^e%okDLG_E zT;k(-IH5=dVhN!o2ju5F5ihzlInjwh(lXi-Puitlk^v(wQ+f!A!p98>($Vw3mi!a^ zZecdk49<Tw-yeM=c?vxwv+6;%ft-CPG2l4XkZViUxWy)ge_C-ISi<+R&z&$ho&+8a zc*?X|<W{YaIv{(x+d0&Jd(&c{`q(Gr3~-948-)xh!TPXWO#G}6MUGpp@COWhMhK@k z`VuFF`6Q~@qsN@>2FTc`uA~yQI;dCiKzBd;+!=#MXJZpT&;kIgY+ON?f@n7r1RK@A zT-5Xv<&VHR`Ess=UGEa~vZGtPh3YQWnKk$u)xj*Y<t*T?pl~JBUE*Se??X{`8yMK5 z!)ft=TZ8LVd$K&q85-C07ZB=<{OPVgXv$i;S9tnaNsHQ+1BR9-i8%K88SK&Z2C-ae z=}Qa?OCfdeT_dE<9K6l3Ti!$Va-*ietuBQEMVo<NVb?S<PVSGMdkn&ZY5t(pb#R*K z>A5Fwg`-~&y%=_l_*nyfCk4KYS}OMt(d|oh@Mr!^cT1bqJdSNUn4AF~Jmpg(wV>Yh zOA<&VGDJHG2eKsyhp{bzH^n}@r;YPwvl^qqHL;mObJB4|1{o>9j;q7}lPUZAQ1)-6 zW&f+VLulE5FP2fP!!Q_vve?<q7>>0Y+$82^QAO%rD#AKCREr%DXq|6VcVR#DI^Pv| z2WK?!+pJgv6|1&T)-vgXTGTJ({lKV_PeD4LGqB_q@C|4APJXDv>081ZEoVo?1LS7w zCl~0Cv0ph~X0$i(60OKKDqVnHDD&^De*}N#W!M>LycO3}Szsd`Y9u51eHo;pQSK^` z`66B5hzFSP6$NixL;O`3iM#wN!t(Oii&g<X#;Jcx#gmI4u6z*hO#yN{2Yy5}%%&RD zASL4TS6aM>{uh=5Kg|-p|3_+MjT!IEmf@|^$_E)?X(BBwQkUrpsy~h5740hFBPBjn zaFFsfBwr=(=6Fk_ANiyUcsn$zZUocGo<=4w`{7T6JPamyM1$<2kY7b%LnYpyL1NR8 zbg#TQ1LT0tMu9xB2pn%@*>1}K`H!i9bP*u61jTP!jw$OF7ATDi$zFcsB%RTZFje%2 zJbBLj+UFq`d2hE<ZQ7?Q`exdGd*JC(IQ7T{%~xBMX_?n^x5kmL<HN_T%)4w4ag@d+ zQKm5-=|V{lf6@6Y`7lI3#HF1}wHVxiRC*DN*zk+mW+MdP&Gvlt6=H@45mP#+G3_+t ztIHEqKHN$_Jbr>P24f#k|C}Wl|KafgI<J3tEGJ?Adt&9;B#j92)$r-h`I}YecJr=H zTll6mTX>gigNrM53tmBtaW&kcsA(3nVA6_-DT}p6y+UiCEY=qC#$sine`~NT7Huu_ z`yRHI)r-N9ugu}|J0d<Y<S%pa>-ai1zvb?R23u9xn!0l9*rM~{wz9fy+d{!suMmuc z%U1hCp~&V)6asR(jeNc5?y@>jh}`WDFK=bWmWZFV@BeUZnkD^uR%_^X;{-AuhG&|X zH4MkBX8cSD|3%Q>jNd5wK4yXbuMh_62X2wKbdk?=C!VvIrbx8ID{u>HxYE)`BS9ax z*u<H?$a>gKj9M3bDC&*wDD%KIjpUO)CftILk4DQfLl{yoZr$pSPSVh}ro-FjU+oS1 zLjFmMpYQxB)YnHMg4-W`G}!8oZSp=8@&k&7YpMl+YIARzq_nNxJ!uZ!9s6r@O=kMi zNL^xB2zL0V1bdA&;MM-Vw62U3@N`ClVF7|lOFe7WZ(48S^o_rrGk2QlpT)%0)Np2| zArg*7rq~pH{u*0Wx;hdKemfEtydjq#{33~U;!m@QyZv^qwAmjOa013JBGT$ZlcUem z=5366w@(a8kS<%Lh0XH%pwQvnHfg(Dk?m{3TO)PRsCUQbF1mx?_H!$1I1A$zqGV7? z!*o-`<rl<g*i=(PW?lYA#9-9#gWEEGBdH@QY}iWaO)!plFyp%~wMF&bm|xo$vQL?g zwntfIbeDiJ7;c-WD+klmU~-u!dE@_%bWK?BN5kF_5N{6pgaEgaE3aZon?l~U7`*aW zDe()pleni!dsxldqsk0Rv`8z>5)&FaY2tS7L@vrmF?WJoqc$-s!(u4J#WZKEVrDb5 zXX#VqK&{gIZDP>3DzmE))UdkFWwDdAM%`i3Vv?zgwFZOw-gBknmKK?-I+ran+p<5_ z&P8S`8PU$fCxZ!Jnf_z*aUAL1Nq(?WbuWpXF>B~ivt?|e)@E_!pxqD+wgur`eQPz; zrfbR4jv19T-ms~qxW!iF$r!WQ8x13{I8XTDaAbR!yF0XFTOd2z=nwe?KiA|9hQz2p zJH0s?oMM*3<TgbjoV&vt3T4T0T#!o|$-f}4i+Ft;Zih&eSrdNL8^Uel^hUiM&=O@l z;h4B>TO=yrwAF)77f4PavpynlF2C2egK6}W6t4@RNSx7#;BO^t8$^MNYz1X3B1T~# z(~LCK;pZA6(Wtmh$PAkhMG(n3{Jx-<(SEtsfH&L*5kyl{L=5|wI?Y8~qdy$f=84#C z$czLHhupIbj$<|<@VJO5XnZk}7(iPWiV~~{RDJvqwQ5a+!>J?R)U+wnCGaDykx<q# zt&xsxC=_sqambl5WKqWLZx!M79b9uT64HtYroq*qbMRpwv6@-~khlf?KCaYSZDPho z<;b);VN)>V&-#BI%ocGEBk6Z+i$*$vG4N`eg&XG)yk+b_dkXExXfL9@fu^GU8Erbp zFmupeMt=dGOVFy&R-@gA7C;lwy3iD~J!t#Uo<n;9?HJl=w0F=xK>HZ&Gqi#QkcVbN zTZOh3?LM?Nv=~|(&1|uj+bZmpRn>L%4UK$LWAM>nETWYe<}aw-CX^2(3zGy42_Czx zv)t<PcX)$gpFfJk_NB8VkwnvV?qy47=v6WPvR&s7w`r+!OPjORx1}lA>G#zMT6wtz z6Ao`@utV(dgoCXSpP!1MEI0}=0SO{=&5kSIvbR+((G*v`e$SNVk}c!h+VL@Qt2iix zHk8YBhRM*=F}DoIBMagy(ARLfEg3J=a9`RDfT&&OrA@(TOrRdpb9{CQ=O+^Oja$Rf z5K(!c1VDPuT(^%QEidCr7gI`f*WF>h1D919XTkXyW66dJVJ7vI-DcvZX6BYo;GLu{ zbB(U{cQypP(M=H#DmD0AM*;P#R&h2Hvlx{JDFXnDRvQFd4k-M;8o{jsLU=N$FH!-J zP>|V#&)<X0{Q@NV=4FB+Cl-KlEQm53Aph$lX-cLH!Y>Gu4DTd}+=M{auG=b78)VVe zkeH_dH6iHXR#Hpkki*Ixo2QEZ#ri>6i6Y2iHczNJXsOxk4T=7#tCF0Ep1?XTq9?44 z!$c~B3G3s|LB?0Q$$oFNH874~QrMBGo4}>#3r$z%EaiAB2hd*~7@0@`!<gH11i{-l zx>Ms=%*9YO;7-)bDU*rOoQwjMY(l1Q?(~|OQaU2JajOXgnEYx<--B8$*cSHtkoTRq zQDd~u{8ASPd69PbJ0j5?b@)U;KNpY-Wr{g+yVMbd9saO@izR13@`GMrqi70IFso2% z0Thapj9_iYN&Yi;HtB!F+4}3DUVbfsEQb7jA8oDm4XbMX*jin_uDrSYnes#BFO;7z z|FHaWd8w_+=CQ?WKeGLk?X>M9+t(^eDwb5(DppjiskpboTM?+}tazg0>53m#9IiNC zak}ES71Qjq?049g+t=8g_7?kh?Xvw{`=|DsD;HHZR<5mls`BqE?NtY>p0Ao)T~h6- z-co&~MqRb$u79|z@2(f`(g5KfBAn>VGyk)BzNO64YzbNR+kR@hV#}|vR;;Xes^SL~ zA6BF)zF}WrFSBp3-)Dc;{;&35*x$6jXK$)>RCZQ=x3ahLt;%^-rYgL(Fbu~qe}l(f z%RWo5<$$Hna?o<f(r-CpdC@XpdD(Kp@*B$;%j=dmEx)&%v%GInEf*|*vRt&JELSaz zHQ#Eq7FY|dMb=_#iIuZ1w3b?zTFq7nobZ>2@gB6Ri)mY5Z!zbRe15$Ae|>fu``EPH KhvIm`-~R%zH!}tR
literal 0 HcmV?d00001
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index e46e7f1..e8172cb 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-y += cmd_boot.o obj-$(CONFIG_SEABIOS) += coreboot_table.o obj-$(CONFIG_EFI) += efi/ +obj-$(CONFIG_CMD_BOOTEFI_HELLO) += efi_hello_world.o obj-y += e820.o obj-y += gcc.o obj-y += init_helpers.o

On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote:
It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
Signed-off-by: Simon Glass sjg@chromium.org
arch/x86/lib/HelloWorld.efi | Bin 0 -> 11168 bytes arch/x86/lib/Makefile | 1 + 2 files changed, 1 insertion(+) create mode 100644 arch/x86/lib/HelloWorld.efi
Should we rename this to HelloWorld32.efi, just like ARM?
[snip]
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index e46e7f1..e8172cb 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o obj-y += cmd_boot.o obj-$(CONFIG_SEABIOS) += coreboot_table.o obj-$(CONFIG_EFI) += efi/ +obj-$(CONFIG_CMD_BOOTEFI_HELLO) += efi_hello_world.o
This should be HelloWorld.o, or if we do like ARM, HelloWorld32.o
obj-y += e820.o obj-y += gcc.o obj-y += init_helpers.o --
Regards, Bin

Enable this so that EFI applications (notably grub) can be run under U-Boot on x86 platforms.
Signed-off-by: Simon Glass sjg@chromium.org ---
lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 37a0dd6..8e7e8a5 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" - depends on (ARM64 || ARM) && OF_LIBFDT + depends on (ARM64 || ARM || X86) && OF_LIBFDT default y help Select this option if you want to run EFI applications (like grub2)

Hi Simon,
On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote:
Enable this so that EFI applications (notably grub) can be run under U-Boot on x86 platforms.
Signed-off-by: Simon Glass sjg@chromium.org
lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 37a0dd6..8e7e8a5 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,6 +1,6 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot"
depends on (ARM64 || ARM) && OF_LIBFDT
depends on (ARM64 || ARM || X86) && OF_LIBFDT default y help Select this option if you want to run EFI applications (like grub2)
--
Reviewed-by: Bin Meng bmeng.cn@gmail.com
Can you also update README.x86 to remove this EFI_LOADER from TODO list?
Regards, Bin

Hi Simon,
On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote:
Bring in these functions from Linux v4.4. They will be needed for EFI loader support.
Signed-off-by: Simon Glass sjg@chromium.org
arch/x86/cpu/Makefile | 2 +- arch/x86/cpu/setjmp.S | 71 +++++++++++++++++++++++++++++++++++++++++++ arch/x86/include/asm/setjmp.h | 24 +++++++++++++++ 3 files changed, 96 insertions(+), 1 deletion(-) create mode 100644 arch/x86/cpu/setjmp.S create mode 100644 arch/x86/include/asm/setjmp.h
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile index 2667e0b..f5b8c9e 100644 --- a/arch/x86/cpu/Makefile +++ b/arch/x86/cpu/Makefile @@ -10,7 +10,7 @@
extra-y = start.o obj-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o -obj-y += interrupts.o cpu.o cpu_x86.o call64.o +obj-y += interrupts.o cpu.o cpu_x86.o call64.o setjmp.o
AFLAGS_REMOVE_call32.o := -mregparm=3 \ $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32) diff --git a/arch/x86/cpu/setjmp.S b/arch/x86/cpu/setjmp.S new file mode 100644 index 0000000..24e7d8a --- /dev/null +++ b/arch/x86/cpu/setjmp.S @@ -0,0 +1,71 @@ +/*
- Written by H. Peter Anvin hpa@zytor.com
- Brought in from Linux v4.4 and modified for U-Boot
- From Linux arch/um/sys-i386/setjmp.S
- SPDX-License-Identifier: GPL-2.0
- */
+#include <asm/global_data.h> +#include <asm/msr-index.h> +#include <asm/processor-flags.h>
+#define _REGPARM
+/*
- The jmp_buf is assumed to contain the following, in order:
%ebx
%esp
%ebp
%esi
%edi
<return address>
- */
/*
* rdi - 32-bit code segment selector
* rsi - target address
* rdx - table address (0 if none)
*/
The comment above looks irrelevant.
.text
.align 4
.globl setjmp
.type setjmp, @function
+setjmp: +#ifdef _REGPARM
movl %eax,%edx
nits: needs space after ",". please fix this globally in this file.
+#else
movl 4(%esp),%edx
+#endif
popl %ecx # Return address, and adjust the stack
I believe # is deprecated. We should use /* */
xorl %eax,%eax # Return value
movl %ebx,(%edx)
movl %esp,4(%edx) # Post-return %esp!
pushl %ecx # Make the call/return stack happy
movl %ebp,8(%edx)
movl %esi,12(%edx)
movl %edi,16(%edx)
movl %ecx,20(%edx) # Return address
ret
.size setjmp,.-setjmp
What is this .size for?
.text
nits: not necessary
.align 4
.globl longjmp
.type longjmp, @function
+longjmp: +#ifdef _REGPARM
xchgl %eax,%edx
+#else
movl 4(%esp),%edx # jmp_ptr address
movl 8(%esp),%eax # Return value
+#endif
movl (%edx),%ebx
movl 4(%edx),%esp
movl 8(%edx),%ebp
movl 12(%edx),%esi
movl 16(%edx),%edi
jmp *20(%edx)
.size longjmp,.-longjmp
diff --git a/arch/x86/include/asm/setjmp.h b/arch/x86/include/asm/setjmp.h new file mode 100644 index 0000000..deef67e --- /dev/null +++ b/arch/x86/include/asm/setjmp.h @@ -0,0 +1,24 @@ +/*
- Written by H. Peter Anvin hpa@zytor.com
- Brought in from Linux v4.4 and modified for U-Boot
- From Linux arch/um/sys-i386/setjmp.S
- SPDX-License-Identifier: GPL-2.0
- */
+#ifndef __setjmp_h +#define __setjmp_h
+struct jmp_buf_data {
unsigned int __ebx;
unsigned int __esp;
unsigned int __ebp;
unsigned int __esi;
unsigned int __edi;
unsigned int __eip;
+};
+int setjmp(struct jmp_buf_data *jmp_buf); +void longjmp(struct jmp_buf_data *jmp_buf);
shouldn't it be void longjmp(struct jmp_buf_data *jmp_buf, int val)? I am wondering how EFI loader could work with this longjmp()?
+#endif
Regards, Bin

Hi Bin,
On 9 August 2016 at 00:49, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote:
Bring in these functions from Linux v4.4. They will be needed for EFI loader support.
Signed-off-by: Simon Glass sjg@chromium.org
arch/x86/cpu/Makefile | 2 +- arch/x86/cpu/setjmp.S | 71 +++++++++++++++++++++++++++++++++++++++++++ arch/x86/include/asm/setjmp.h | 24 +++++++++++++++ 3 files changed, 96 insertions(+), 1 deletion(-) create mode 100644 arch/x86/cpu/setjmp.S create mode 100644 arch/x86/include/asm/setjmp.h
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile index 2667e0b..f5b8c9e 100644 --- a/arch/x86/cpu/Makefile +++ b/arch/x86/cpu/Makefile @@ -10,7 +10,7 @@
extra-y = start.o obj-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o -obj-y += interrupts.o cpu.o cpu_x86.o call64.o +obj-y += interrupts.o cpu.o cpu_x86.o call64.o setjmp.o
AFLAGS_REMOVE_call32.o := -mregparm=3 \ $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32) diff --git a/arch/x86/cpu/setjmp.S b/arch/x86/cpu/setjmp.S new file mode 100644 index 0000000..24e7d8a --- /dev/null +++ b/arch/x86/cpu/setjmp.S @@ -0,0 +1,71 @@ +/*
- Written by H. Peter Anvin hpa@zytor.com
- Brought in from Linux v4.4 and modified for U-Boot
- From Linux arch/um/sys-i386/setjmp.S
- SPDX-License-Identifier: GPL-2.0
- */
+#include <asm/global_data.h> +#include <asm/msr-index.h> +#include <asm/processor-flags.h>
+#define _REGPARM
+/*
- The jmp_buf is assumed to contain the following, in order:
%ebx
%esp
%ebp
%esi
%edi
<return address>
- */
/*
* rdi - 32-bit code segment selector
* rsi - target address
* rdx - table address (0 if none)
*/
The comment above looks irrelevant.
OK, will drop.
.text
.align 4
.globl setjmp
.type setjmp, @function
+setjmp: +#ifdef _REGPARM
movl %eax,%edx
nits: needs space after ",". please fix this globally in this file.
+#else
movl 4(%esp),%edx
+#endif
popl %ecx # Return address, and adjust the stack
I believe # is deprecated. We should use /* */
OK
xorl %eax,%eax # Return value
movl %ebx,(%edx)
movl %esp,4(%edx) # Post-return %esp!
pushl %ecx # Make the call/return stack happy
movl %ebp,8(%edx)
movl %esi,12(%edx)
movl %edi,16(%edx)
movl %ecx,20(%edx) # Return address
ret
.size setjmp,.-setjmp
What is this .size for?
Size of the function code. It helps with nm --size-sort I think.
.text
nits: not necessary
.align 4
.globl longjmp
.type longjmp, @function
+longjmp: +#ifdef _REGPARM
xchgl %eax,%edx
+#else
movl 4(%esp),%edx # jmp_ptr address
movl 8(%esp),%eax # Return value
+#endif
movl (%edx),%ebx
movl 4(%edx),%esp
movl 8(%edx),%ebp
movl 12(%edx),%esi
movl 16(%edx),%edi
jmp *20(%edx)
.size longjmp,.-longjmp
diff --git a/arch/x86/include/asm/setjmp.h b/arch/x86/include/asm/setjmp.h new file mode 100644 index 0000000..deef67e --- /dev/null +++ b/arch/x86/include/asm/setjmp.h @@ -0,0 +1,24 @@ +/*
- Written by H. Peter Anvin hpa@zytor.com
- Brought in from Linux v4.4 and modified for U-Boot
- From Linux arch/um/sys-i386/setjmp.S
- SPDX-License-Identifier: GPL-2.0
- */
+#ifndef __setjmp_h +#define __setjmp_h
+struct jmp_buf_data {
unsigned int __ebx;
unsigned int __esp;
unsigned int __ebp;
unsigned int __esi;
unsigned int __edi;
unsigned int __eip;
+};
+int setjmp(struct jmp_buf_data *jmp_buf); +void longjmp(struct jmp_buf_data *jmp_buf);
shouldn't it be void longjmp(struct jmp_buf_data *jmp_buf, int val)? I am wondering how EFI loader could work with this longjmp()?
efi_exit() seems to not need the extra parameter.
+#endif
Regards, Bin
Regards, SImon

Hi Simon,
On Wed, Aug 10, 2016 at 2:16 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 9 August 2016 at 00:49, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sun, Aug 7, 2016 at 7:23 AM, Simon Glass sjg@chromium.org wrote:
Bring in these functions from Linux v4.4. They will be needed for EFI loader support.
Signed-off-by: Simon Glass sjg@chromium.org
arch/x86/cpu/Makefile | 2 +- arch/x86/cpu/setjmp.S | 71 +++++++++++++++++++++++++++++++++++++++++++ arch/x86/include/asm/setjmp.h | 24 +++++++++++++++ 3 files changed, 96 insertions(+), 1 deletion(-) create mode 100644 arch/x86/cpu/setjmp.S create mode 100644 arch/x86/include/asm/setjmp.h
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile index 2667e0b..f5b8c9e 100644 --- a/arch/x86/cpu/Makefile +++ b/arch/x86/cpu/Makefile @@ -10,7 +10,7 @@
extra-y = start.o obj-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o -obj-y += interrupts.o cpu.o cpu_x86.o call64.o +obj-y += interrupts.o cpu.o cpu_x86.o call64.o setjmp.o
AFLAGS_REMOVE_call32.o := -mregparm=3 \ $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32) diff --git a/arch/x86/cpu/setjmp.S b/arch/x86/cpu/setjmp.S new file mode 100644 index 0000000..24e7d8a --- /dev/null +++ b/arch/x86/cpu/setjmp.S @@ -0,0 +1,71 @@ +/*
- Written by H. Peter Anvin hpa@zytor.com
- Brought in from Linux v4.4 and modified for U-Boot
- From Linux arch/um/sys-i386/setjmp.S
- SPDX-License-Identifier: GPL-2.0
- */
+#include <asm/global_data.h> +#include <asm/msr-index.h> +#include <asm/processor-flags.h>
+#define _REGPARM
+/*
- The jmp_buf is assumed to contain the following, in order:
%ebx
%esp
%ebp
%esi
%edi
<return address>
- */
/*
* rdi - 32-bit code segment selector
* rsi - target address
* rdx - table address (0 if none)
*/
The comment above looks irrelevant.
OK, will drop.
.text
.align 4
.globl setjmp
.type setjmp, @function
+setjmp: +#ifdef _REGPARM
movl %eax,%edx
nits: needs space after ",". please fix this globally in this file.
+#else
movl 4(%esp),%edx
+#endif
popl %ecx # Return address, and adjust the stack
I believe # is deprecated. We should use /* */
OK
xorl %eax,%eax # Return value
movl %ebx,(%edx)
movl %esp,4(%edx) # Post-return %esp!
pushl %ecx # Make the call/return stack happy
movl %ebp,8(%edx)
movl %esi,12(%edx)
movl %edi,16(%edx)
movl %ecx,20(%edx) # Return address
ret
.size setjmp,.-setjmp
What is this .size for?
Size of the function code. It helps with nm --size-sort I think.
.text
nits: not necessary
.align 4
.globl longjmp
.type longjmp, @function
+longjmp: +#ifdef _REGPARM
xchgl %eax,%edx
+#else
movl 4(%esp),%edx # jmp_ptr address
movl 8(%esp),%eax # Return value
+#endif
movl (%edx),%ebx
movl 4(%edx),%esp
movl 8(%edx),%ebp
movl 12(%edx),%esi
movl 16(%edx),%edi
jmp *20(%edx)
.size longjmp,.-longjmp
diff --git a/arch/x86/include/asm/setjmp.h b/arch/x86/include/asm/setjmp.h new file mode 100644 index 0000000..deef67e --- /dev/null +++ b/arch/x86/include/asm/setjmp.h @@ -0,0 +1,24 @@ +/*
- Written by H. Peter Anvin hpa@zytor.com
- Brought in from Linux v4.4 and modified for U-Boot
- From Linux arch/um/sys-i386/setjmp.S
- SPDX-License-Identifier: GPL-2.0
- */
+#ifndef __setjmp_h +#define __setjmp_h
+struct jmp_buf_data {
unsigned int __ebx;
unsigned int __esp;
unsigned int __ebp;
unsigned int __esi;
unsigned int __edi;
unsigned int __eip;
+};
+int setjmp(struct jmp_buf_data *jmp_buf); +void longjmp(struct jmp_buf_data *jmp_buf);
shouldn't it be void longjmp(struct jmp_buf_data *jmp_buf, int val)? I am wondering how EFI loader could work with this longjmp()?
efi_exit() seems to not need the extra parameter.
This does not look good to me. See efi_start_image(), there is a test against return value of setjmp(), but longjmp() does not provide a return value, which means the return value is undetermined.
if (setjmp(&info->exit_jmp)) { /* We returned from the child image */ return EFI_EXIT(info->exit_status); }
Regards, Bin
participants (4)
-
Alexander Graf
-
Bin Meng
-
Leif Lindholm
-
Simon Glass