date:20160805

[edk2] [PATCHV2] IntelFsp2Pkg: Converted PatchFvUserManual from .docx to .md format

2016-08-05 Thread Giri P Mudusuru

Converted the the word format of the documentation into markdown format
for PatchFv.py

V2: updated the commit message descripton

Cc: Jiewen Yao 
Cc: Maurice Ma 
Cc: Satya Yarlagadda 
Cc: Satya Yarlagadda 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru 
---
 .../Tools/UserManuals/PatchFvUserManual.docx   | Bin 21481 -> 0 bytes
 .../Tools/UserManuals/PatchFvUserManual.md | 123 +
 2 files changed, 123 insertions(+)
 delete mode 100644 IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.docx
 create mode 100644 IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.md

diff --git a/IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.docx 
b/IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.docx
deleted file mode 100644
index 
ab1eda993e7b7d249a0390dc1db83ff4987395da..
GIT binary patch
literal 0
HcmV?d1

literal 21481
zcmeF2^Ot7LlBnOZZQHhOS9RI8ZQJbXQkT1I+cvvwSC{R&^?he%%{h0@z5l?>{vlVs
zd+!w)J2T>q^+aYU%7B2P0>A-~004jp07V)e6bJ+W#DM_-C;&)cZ4rAr7gIYIeHBj!
zQ)gXz4_h0;d{AJ@TmbOb`~Q3W51xUB6gh=pLBz02@(+kQb#-Wsl-1`!_it7$~
zk(CiY6Z6;mOFU_rvbsja{LR`8+)Cb2D=pf#sNGqBhRAwjv6TW+-I_-vs)=5{5{jX
zMiIUmGWc38{B*yjx9K81|C&13g4o9cIfL>)8z|>nDwIQ>@Jak`?)cbyWhaGA%jM^8!HATF%CcP_
zL5}LjEvgry8hx+h-AZSX?m_#k*vi*>eNd5~j4|SED8w@zAX_@G=FT=Iahh``vK_9H
zul=9-=NmyKWyaWC5d4%DYNBfqY;g_VQx^zj=cz)!cPBa4T%Mo+fX`15fa1S+E`B0*
z^X->8%6~Z~%$MitJDJ)zGtmFl{;$XW4|dak`t+EjHE9qb*sx2mEyEFCjx}iFxs^@H
zJa^(hAR*~zK<@Apg{xhi1%z#iYkG%wN8<{=GlMf1c#3(!s|__5bC)v>B(|(QY@4GY
z6g5Y*GlIo3Yds=!A}Rsk9~FNSt}LqMcSi|*_F
zDiU1JV8QtsZ(TAA(-aETe0B
zUaDQIdr|cc7(cc?=$B(3an0Dl5PA@wjlBZBW(cV*J{a(Q$o=Q?55v^RX
zl4LEVhSY+NV_aE?meCn@jiCgOz6|s)1`m?OWZD3RB$H8Jfnd|%35#TyLyl*v=q6i~
z5r1=@%Ge<5;%w_0)}U=j(H%2P=3fi}plj~C+oMk{eY*j|wkht%tb=2VZ^<7*otSzt
zB#mg>1$j5()`|Nj?B#kf;PE;Cbe
zY8PeM!|K-3yEgKX>dPCSUf(+p^+FK%bspgVos9_)mxQWd006lu007dL>HKYD|7=}n
zeAdouBZ*tpryn3ujhl5Sn&7?7^hT))+NyPxNw}Bip1Smipk!G>0YHMItIpqE32vxV
zM|0Nnoi=U(=HMWRq-2#1H0pKiKohbG3f)ER#YYPMAIy)jG8|EzjGPrJkCRb5;PRaJ
zLAU*5`kS#i%{1a!%e@N^{XKjYI_-`J(;J^}@dCPdvLfbO?!f~A^g(+A^hqX;
zSG!_oIxWsTn>pU{s6#unEAD;I(GKjlxQ~OXm~#3WW{aesTB3P-LrgIoHNi4GRW%of
zE1P|xI6WHmj2UZE9R%V>42N!ao~<76oeXCKnI2s~bVRnylHF18)l!uldH`P8z#($*
zl!9jro5W)i!YuT*Tqc-=BwZ0Y1O|}7Pkq`IMYXo}jDs-nbEdPT^hf-k7gkD@=0h^Y
zI%aTTiN0VmwWo~pKf$q-S1m4-dADDx)Kt%FtgFkbwyLdV6Rr~1|^n+vv`S236m!4uNu`aE|Rc4N6mYA#knI~{0-*10~5
zp8}jdp}$YHftH

[edk2] [PATCH] IntelFsp2Pkg: Converted GenCfgOptUserManual from .docx to .md format

2016-08-05 Thread Giri P Mudusuru

Converted the the word format of the documentation into markdown format
for GenCfgOpt.py

Cc: Jiewen Yao 
Cc: Maurice Ma 
Cc: Satya Yarlagadda 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru 
---
 .../Tools/UserManuals/GenCfgOptUserManual.docx | Bin 28336 -> 0 bytes
 .../Tools/UserManuals/GenCfgOptUserManual.md   | 353 +
 2 files changed, 353 insertions(+)
 delete mode 100644 IntelFsp2Pkg/Tools/UserManuals/GenCfgOptUserManual.docx
 create mode 100644 IntelFsp2Pkg/Tools/UserManuals/GenCfgOptUserManual.md

diff --git a/IntelFsp2Pkg/Tools/UserManuals/GenCfgOptUserManual.docx 
b/IntelFsp2Pkg/Tools/UserManuals/GenCfgOptUserManual.docx
deleted file mode 100644
index 
c8766d5775158a3a6d17d9a0ffda598c8ea516ca..
GIT binary patch
literal 0
HcmV?d1

literal 28336
zcmeFYQ?qD6vn9H0+qP})W!tuGuf1$(CZJWKn)6sGJM)yBBT@U$E`7oAzkA|6x3x2UEnAIyUgoiS{frCgUz^q
ze#RJ!*&`1-8Xgh(WAy~bW~FakWlgii&4K7eI4~k%y5mwErWU_7w@vm(~AHuJ7fe
zcnLT#f4>1iEY8hkflR4v`aeI;%vrk#!+d2cDs6q9Pr4*$pa5|Yq)*K|=
z$NqeJpRp?1`(-7E^i3;;arA7+if!Bp5&`Rk_~32O#J!;1S)Q9o;JD9<*c1J3
z=DqjB?uHL`^`n7@BVW~FA>51T5Iy)|9|@tyik%2TYq`I@+tSI7fk!WG5{?*|O&
zVTy|Jng_U__*?g`^8cosWRbX;ZCdaQE?~!ea};4Y&)E10M!H1s{MO81W>MI1Bxc)OwC4)=uRuU{J$+dDq+
zSP&-U7IfEO%!hpwifCbdM?Bw+=n^<6{R+?xZmMXbr@N4#Lw-~DxdvQ(tV?%H5_l5?o$mOe-V63|4HW`OuqDW4~bv9jQxF+`ArkI0m{
zu24I8tVg*c4o3n~DK>rz`#Gwzqi6I<4LBpcWJ3ei!t7R{c~qTEZv{?=9m^NW^mc7B
z9CZxbz;2z+kjh$O#4*~E@|gz9nqihSJKnGgifzxLVEI}2S1r*JOk=~r|pS=B_96@-C17!I(BL)HhfCB=w|0=O#eTL
zVr*yRV)IV}|090?i!^}$6!2g6fA3M1*e^TC@DDWNT|+GVJ<7=G%1sP1Gp;tWw!*
z1ril%MVtl`GAgXXRqQs=j_Lhr<`E%Jb~*OEV?bNaQp?)H*db@eQw6$0vV9#0O3a
z9MKe8fQ>7UpO+6%sRZ{CQ#wW{+SH{rB$W9bV;Vq+8C+S{;uL1E1qq)(YlFX#K<_LP
zrrK^j>r7^uHBTuYFTYYm)@$IB<+`F%cJh@_q|DlsBqzHsyKX1qT~YT!OCB^Ro_bj*{L(%^9fUkr$4LoiB=m{_*)2{YWwzKo|H
z93zjW%rM+LV>wQ$Cs_Yt;*3~JV;$3&7%I7>EJz9wx8oxpfV0^NpvcxfN^l<_jBTe8
zxQjZ-!$EYp{Y>)zgUbJjy4#s@{CQ>o0PPt-0K|V8|Ao5$9dB1YpSGLgDX+iyb+>
z0FgI%qw~Wl*3-h=4Rqmd$lUf@-OLy;SWUv~S>gpLMF;K;z)##){GENTfS;>;V|=$6Xe$KBK
zd!d;#k!(v0xFE#0%l(DuxL-=&_&>9^_?F#y+?bw)Yl7&7WiJdjJzQ=->TA3nX8-QExbJClm}>iWIWgL#)Ch$B`Vg>tse1RdBj
zFKAKSh$9!^`*YESg#=w*oX&%>iTBV?e6B{nEBJ5s#2<9Z#_au-ff5`Q;gH?pWWu>i
zZ$U%w?;;$HP?K$6lPUfH*!L!9uneL4DBGWh=S-^Cuu@*^qCh`Axa?>mES?mW!8
z4M#Lyb5Psh*27JM={GceXZNuoz;NIjyXQ3-ylBvmXvD5T9pWc(CQu(~j$}fs_@vua
zU|6Vad0{ShpDq~EBje5^Kc3w>QG8@Rhz4|wjemj_aypvK%i*NI~T3sF3
zq5izO`eX8<#NrN&1#+bg+st_tdjnXDWlb(kf+hS
z_f8-x4d?jdp=5r!%mV&1!{Fc5(TiMpUH6kQQ2MmJ$ifLu075nuzLa?=Nmv6dX@~oA+f!q
ztHZfYVpW$hJn2uD>_>vIYVjRvybl=9g%ecQ8FbuI|JD=%ihJzpRw3F1k79ZX=80AhkS3*zR
ztU1LrS2bE3BF&%o9Z;f(`87RdahgF|#N}sl*BAuh
zv-MHLo+Or@`vWriNuK^vrtSdG@B0{`O!Hj_@RrdxDA=y|#7WRU)u8S){1yMkJ
zT*o1h`QjK|7S^+4c!zB>oGi-7O8`UB9)+JuUl9_D*hux$R8^YCdd}Lx771vK!O$F@
z#InnlxbUuS$9LtUx`Z>EXim~yE0lopu1<62z6I)@Dow(;B6|9M7h!K54U`oH%*2
zhP!3zU-=(sbIgRIiMYiB-I0MKu2_P||I@8-pcqlzZba&}!?KWXozdY;i
zywtEBd~$i}M93E1$Fq>$wl_R?clngC4Go*~gzsJ*UpxNbioikcPA{(4%M-q+Ual^K
zC~`bqzL0jwc~N$x7HHWk#t)K@Dmu3|XO{IoidsR*X-)P|pxWYPB
zy|}c?b8w4UyRRgzXstDIWhY8DPaOdNX_{@TiQMwBcF~pd8Ry9`0=GJ7FD8h<=d_hP
zE5eTY_}K<=K!KtGF+yu#1(iNXB!hl0Qs$t}4!;8vp=P-Q078O#axC^<;IVp0y+(G~
z^4PTsj6Ug3Hz=|uM0JYe?9V7{_qSB83`WNLmV|uK9-8UKCR9iD%vsEh>VWwW3u6ve
z@IHI12Nv_P3y1=^%7w9?#%)xlN{Ym3RU9$SXC@dTdGMUME<~fu+rO6^HUoXk>1vk-P85j|oI5=VgkRYMF=SJx#<1
zzA*whBO*WJj)g$vYCYO2{mwVWbz<0Q#7k#AnY%*CBrkPZC!&=BDTg2q{)O3u---~>
z9+W^qj(Cm>3(5^c^ola~eSha)zxo$@DS+UP(JqPqa3
zz34s*C0+vi3G!GlB~IfHeemGptOr7lr(|NVFliPeywCsa1ehI|WSlI7Be;ea5hk^_
zClHCZQ3{Q^^r_(LrEz6c$D4{-?@Y5nfN*_M#o`>K~R@$F7TuBzI(Hk~E#?bC|hj3-9NwC9WS
z8sm%c8kG?661x7ZVb1n55X$(HZVnKQKQ!5YBmr5ii>55dN`+#mBbBBN!NqQeT
z6;`wBmxMhF!hFp;dw0Ke!z!D{i;#~xQnZ)xM4;I>FtclX?a2i8w-~HDA
zD2mh!lhOojzW53bJb{DYv1GFyVevDH=%Z~S|Poo=Dc@3LI6Bn
z+^lTncx7rQch6j%oVNgUI`t52-TWuEOKiKqJz^~N4Eg=G{+)}&5kK6$Mj{^;`(eGs

Re: [edk2] Shell version 2.2

2016-08-05 Thread Rothman, Michael A

I think the ver should reflect the spec version on which the shell was built. 
I'm not sure why it would be 2.1 if built on 2.2 compliant code.

Thanks,
Michael A. Rothman
---
Let no excuse be a barrier to your success.

> On Aug 5, 2016, at 12:16 PM, Tim Lewis  wrote:
> 
> Yes,  but they are the same numbers. So I think this is probably a 
> 
> The specification says (in the Shell protocol section's Related Defintiions):
> 
> #define EFI_SHELL_MAJOR_VERSION 2
> #define EFI_SHELL_MINOR_VERSION 2
> 
> And, from ver.c:
> 
>ShellPrintHiiEx (
>  0,
>  gST->ConOut->Mode->CursorRow,
>  NULL,
>  STRING_TOKEN (STR_VER_OUTPUT_SIMPLE),
>  gShellLevel3HiiHandle,
>  gEfiShellProtocol->MajorVersion,
>  gEfiShellProtocol->MinorVersion
> );
> 
> And the shell protocol instance comes from ShellProtocol.c (see below):
> 
> EFI_SHELL_PROTOCOL mShellProtocol = {
>  EfiShellExecute,
>  EfiShellGetEnv,
>  EfiShellSetEnv,
>  EfiShellGetAlias,
>  EfiShellSetAlias,
>  EfiShellGetHelpText,
>  EfiShellGetDevicePathFromMap,
>  EfiShellGetMapFromDevicePath,
>  EfiShellGetDevicePathFromFilePath,
>  EfiShellGetFilePathFromDevicePath,
>  EfiShellSetMap,
>  EfiShellGetCurDir,
>  EfiShellSetCurDir,
>  EfiShellOpenFileList,
>  EfiShellFreeFileList,
>  EfiShellRemoveDupInFileList,
>  EfiShellBatchIsActive,
>  EfiShellIsRootShell,
>  EfiShellEnablePageBreak,
>  EfiShellDisablePageBreak,
>  EfiShellGetPageBreak,
>  EfiShellGetDeviceName,
>  (EFI_SHELL_GET_FILE_INFO)FileHandleGetInfo, //*
>  (EFI_SHELL_SET_FILE_INFO)FileHandleSetInfo, //*
>  EfiShellOpenFileByName,
>  EfiShellClose,
>  EfiShellCreateFile,
>  (EFI_SHELL_READ_FILE)FileHandleRead,//*
>  (EFI_SHELL_WRITE_FILE)FileHandleWrite,  //*
>  (EFI_SHELL_DELETE_FILE)FileHandleDelete,//*
>  EfiShellDeleteFileByName,
>  (EFI_SHELL_GET_FILE_POSITION)FileHandleGetPosition, //*
>  (EFI_SHELL_SET_FILE_POSITION)FileHandleSetPosition, //*
>  (EFI_SHELL_FLUSH_FILE)FileHandleFlush,  //*
>  EfiShellFindFiles,
>  EfiShellFindFilesInDir,
>  (EFI_SHELL_GET_FILE_SIZE)FileHandleGetSize, //*
>  EfiShellOpenRoot,
>  EfiShellOpenRootByHandle,
>  NULL,
>  SHELL_MAJOR_VERSION,
>  SHELL_MINOR_VERSION,
> 
>  // New for UEFI Shell 2.1
>  EfiShellRegisterGuidName,
>  EfiShellGetGuidName,
>  EfiShellGetGuidFromName,
>  EfiShellGetEnvEx
> };
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Carsey, Jaben
> Sent: Friday, August 05, 2016 12:10 PM
> To: Tim Lewis ; Meenakshi Aggarwal 
> ; edk2-devel@lists.01.org 
> Cc: Carsey, Jaben 
> Subject: Re: [edk2] Shell version 2.2
> 
> Tim,
> 
> Yes, ver command would output that the version of the shell is different.
> 
> The #define below is specifically the version of the Protocol, not the 
> version of the spec.
> 
> It could have been a miss on the part of the committee, but that was hoe I 
> interpreted the non-change to the protocol version.
> 
> -Jaben
> 
>> -Original Message-
>> From: Tim Lewis [mailto:tim.le...@insyde.com]
>> Sent: Friday, August 5, 2016 11:36 AM
>> To: Carsey, Jaben ; Meenakshi Aggarwal 
>> ; edk2-devel@lists.01.org > de...@ml01.01.org>
>> Subject: RE: Shell version 2.2
>> Importance: High
>> 
>> Jaben --
>> 
>> Are there no shell commands where the standard command-line parameters 
>> have changed?
>> 
>> Tim
>> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Carsey, Jaben
>> Sent: Friday, August 05, 2016 10:26 AM
>> To: Meenakshi Aggarwal ; edk2- 
>> de...@lists.01.org 
>> Cc: Carsey, Jaben 
>> Subject: Re: [edk2] Shell version 2.2
>> 
>> I think that that version (2.1) is correct for the version of the 
>> protocol.  The protocol API was not changed for the UEFI Shell 2.2.
>> 
>> That is the current version and should support the 2.2 spec.
>> 
>> -Jaben
>> 
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>>> Of Meenakshi Aggarwal
>>> Sent: Friday, August 5, 2016 2:20 AM
>>> To: edk2-devel@lists.01.org 
>>> Subject: [edk2] Shell version 2.2
>>> Importance: High
>>> 
>>> Hi,
>>> 
>>> 
>>> I can see UEFI shell specification 2.2
>>> (http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pd
>>> f) is available, But on edk2 master branch current version of Shell 
>>> is still showing
>> 2.1.
>>> 
>>> File:ShellPkg/Include/Protocol/EfiShell.h
>>> 
>>> enum ShellVersion {
>>>  SHELL_MAJOR_VERSION = 2,
>>>  SHELL_MINOR_VERSION = 1
>>> };
>>> 
>>> 
>>> 
>>> Please tell if I am looking at

Re: [edk2] Shell version 2.2

2016-08-05 Thread Bhupesh Sharma

Unfortunately the 'ver' command on the shell also shows up a 2.1 shell version 
with the latest edk2/master.

So, we think it is rather a bug.

Regards,
Bhupesh


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Tim Lewis
> Sent: Saturday, August 06, 2016 12:47 AM
> To: Carsey, Jaben ; Meenakshi Aggarwal
> ; edk2-devel@lists.01.org  de...@ml01.01.org>
> Subject: Re: [edk2] Shell version 2.2
> 
> Yes,  but they are the same numbers. So I think this is probably a
> 
> The specification says (in the Shell protocol section's Related
> Defintiions):
> 
> #define EFI_SHELL_MAJOR_VERSION 2
> #define EFI_SHELL_MINOR_VERSION 2
> 
> And, from ver.c:
> 
> ShellPrintHiiEx (
>   0,
>   gST->ConOut->Mode->CursorRow,
>   NULL,
>   STRING_TOKEN (STR_VER_OUTPUT_SIMPLE),
>   gShellLevel3HiiHandle,
>   gEfiShellProtocol->MajorVersion,
>   gEfiShellProtocol->MinorVersion
>  );
> 
> And the shell protocol instance comes from ShellProtocol.c (see below):
> 
> EFI_SHELL_PROTOCOL mShellProtocol = {
>   EfiShellExecute,
>   EfiShellGetEnv,
>   EfiShellSetEnv,
>   EfiShellGetAlias,
>   EfiShellSetAlias,
>   EfiShellGetHelpText,
>   EfiShellGetDevicePathFromMap,
>   EfiShellGetMapFromDevicePath,
>   EfiShellGetDevicePathFromFilePath,
>   EfiShellGetFilePathFromDevicePath,
>   EfiShellSetMap,
>   EfiShellGetCurDir,
>   EfiShellSetCurDir,
>   EfiShellOpenFileList,
>   EfiShellFreeFileList,
>   EfiShellRemoveDupInFileList,
>   EfiShellBatchIsActive,
>   EfiShellIsRootShell,
>   EfiShellEnablePageBreak,
>   EfiShellDisablePageBreak,
>   EfiShellGetPageBreak,
>   EfiShellGetDeviceName,
>   (EFI_SHELL_GET_FILE_INFO)FileHandleGetInfo, //*
>   (EFI_SHELL_SET_FILE_INFO)FileHandleSetInfo, //*
>   EfiShellOpenFileByName,
>   EfiShellClose,
>   EfiShellCreateFile,
>   (EFI_SHELL_READ_FILE)FileHandleRead,//*
>   (EFI_SHELL_WRITE_FILE)FileHandleWrite,  //*
>   (EFI_SHELL_DELETE_FILE)FileHandleDelete,//*
>   EfiShellDeleteFileByName,
>   (EFI_SHELL_GET_FILE_POSITION)FileHandleGetPosition, //*
>   (EFI_SHELL_SET_FILE_POSITION)FileHandleSetPosition, //*
>   (EFI_SHELL_FLUSH_FILE)FileHandleFlush,  //*
>   EfiShellFindFiles,
>   EfiShellFindFilesInDir,
>   (EFI_SHELL_GET_FILE_SIZE)FileHandleGetSize, //*
>   EfiShellOpenRoot,
>   EfiShellOpenRootByHandle,
>   NULL,
>   SHELL_MAJOR_VERSION,
>   SHELL_MINOR_VERSION,
> 
>   // New for UEFI Shell 2.1
>   EfiShellRegisterGuidName,
>   EfiShellGetGuidName,
>   EfiShellGetGuidFromName,
>   EfiShellGetEnvEx
> };
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Carsey, Jaben
> Sent: Friday, August 05, 2016 12:10 PM
> To: Tim Lewis ; Meenakshi Aggarwal
> ; edk2-devel@lists.01.org  de...@ml01.01.org>
> Cc: Carsey, Jaben 
> Subject: Re: [edk2] Shell version 2.2
> 
> Tim,
> 
> Yes, ver command would output that the version of the shell is
> different.
> 
> The #define below is specifically the version of the Protocol, not the
> version of the spec.
> 
> It could have been a miss on the part of the committee, but that was
> hoe I interpreted the non-change to the protocol version.
> 
> -Jaben
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Friday, August 5, 2016 11:36 AM
> > To: Carsey, Jaben ; Meenakshi Aggarwal
> > ; edk2-devel@lists.01.org  > de...@ml01.01.org>
> > Subject: RE: Shell version 2.2
> > Importance: High
> >
> > Jaben --
> >
> > Are there no shell commands where the standard command-line
> parameters
> > have changed?
> >
> > Tim
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> Of
> > Carsey, Jaben
> > Sent: Friday, August 05, 2016 10:26 AM
> > To: Meenakshi Aggarwal ; edk2-
> > de...@lists.01.org 
> > Cc: Carsey, Jaben 
> > Subject: Re: [edk2] Shell version 2.2
> >
> > I think that that version (2.1) is correct for the version of the
> > protocol.  The protocol API was not changed for the UEFI Shell 2.2.
> >
> > That is the current version and should support the 2.2 spec.
> >
> > -Jaben
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Meenakshi Aggarwal
> > > Sent: Friday, August 5, 2016 2:20 AM
> > > To: edk2-devel@lists.01.org 
> > > Subject: [edk2] Shell version 2.2
> > > Importance: High
> > >
> > > Hi,
> > >
> > >
> > > I can see UEFI shell specification 2.2
> > >
> (http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pd
> > > f) is available, But on edk2 master branch

Re: [edk2] [PATCH 2/2] MdeModulePkg/EbcDxe: cleanup

2016-08-05 Thread Ard Biesheuvel

On 5 August 2016 at 21:24, Daniil Egranov  wrote:
> Hi Ard,
>
>
>
> On 08/01/2016 09:22 AM, Ard Biesheuvel wrote:
>>
>> - indentation
>> - premature optimization of the thunking code, i.e., align function
>> prototypes
>>so we don't have to move arguments around or duplicate them on the
>> stack,
>>and perform tail calls where possible
>> - adhere to calling convention (stack frame layout)
>> - replace instruction buffer with a fixed struct, so that we no longer
>> have
>>to traverse it to find the entry point slots
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>   MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S | 188
>> ++-
>>   MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c  | 193
>> ++--
>>   2 files changed, 159 insertions(+), 222 deletions(-)
>>
>> diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
>> b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
>> index 3c1a461f5e87..d0a5a4c5a37d 100644
>> --- a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
>> +++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
>> @@ -1,10 +1,12 @@
>>   ///** @file
>>   //
>> -//This code provides low level routines that support the Virtual
>> Machine
>> -//   for option ROMs.
>> +//  This code provides low level routines that support the Virtual
>> Machine
>> +//  for option ROMs.
>>   //
>> -//  Copyright (c) 2015, The Linux Foundation. All rights reserved.
>> +//  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
>> +//  Copyright (c) 2015, The Linux Foundation. All rights reserved.
>>   //  Copyright (c) 2007 - 2014, Intel Corporation. All rights
>> reserved.
>> +//
>>   //  This program and the accompanying materials
>>   //  are licensed and made available under the terms and conditions of
>> the BSD License
>>   //  which accompanies this distribution.  The full text of the license
>> may be found at
>> @@ -15,9 +17,10 @@
>>   //
>>   //**/
>>   -ASM_GLOBAL ASM_PFX(CopyMem);
>> -ASM_GLOBAL ASM_PFX(EbcInterpret);
>> -ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
>> +ASM_GLOBAL ASM_PFX(EbcLLEbcInterpret);
>> +ASM_GLOBAL ASM_PFX(EbcLLExecuteEbcImageEntryPoint);
>> +
>> +ASM_GLOBAL ASM_PFX(mEbcInstructionBufferTemplate);
>
> The ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative); is missing here. The linking
> fails without it.
>

Thanks for the report. I had a single patch and split it into two, and
apparently, I was sloppy

>>
>> //
>>   // EbcLLCALLEX
>> @@ -30,102 +33,121 @@ ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
>>   //
>>
>> //
>>   // UINTN EbcLLCALLEXNative(UINTN FuncAddr, UINTN NewStackPointer, VOID
>> *FramePtr)
>> -ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative);
>>   ASM_PFX(EbcLLCALLEXNative):
>> -  stp  x19, x20, [sp, #-16]!
>> -  stp  x29, x30, [sp, #-16]!
>> -
>> -  mov  x19, x0
>> -  mov  x20, sp
>> -  sub  x2, x2, x1   // Length = NewStackPointer-FramePtr
>> -  sub  sp, sp, x2
>> -  sub  sp, sp, #64  // Make sure there is room for at least 8 args in
>> the new stack
>> -  mov  x0, sp
>> -
>> -  bl   CopyMem  // Sp, NewStackPointer, Length
>> -
>> -  ldp  x0, x1, [sp], #16
>> -  ldp  x2, x3, [sp], #16
>> -  ldp  x4, x5, [sp], #16
>> -  ldp  x6, x7, [sp], #16
>> -
>> -  blr  x19
>> -
>> -  mov  sp,  x20
>> -  ldp  x29, x30, [sp], #16
>> -  ldp  x19, x20, [sp], #16
>> -
>> -  ret
>> +mov x8, x0 // Preserve x0
>> +mov x9, x1 // Preserve x1
>> +
>> +//
>> +// If the EBC stack frame is smaller than or equal to 64 bytes, we
>> know there
>> +// are no stacked arguments #9 and beyond that we need to copy to the
>> native
>> +// stack. In this case, we can perform a tail call which is much more
>> +// efficient, since there is no need to touch the native stack at
>> all.
>> +//
>> +sub x3, x2, x1  // Length = NewStackPointer -
>> FramePtr
>> +cmp x3, #64
>> +b.gt1f
>> +
>> +adr x0, 0f
>> +sub x0, x0, x3, lsr #1
>> +br  x0
>> +
>> +ldr x7, [x9, #56]
>> +ldr x6, [x9, #48]
>> +ldr x5, [x9, #40]
>> +ldr x4, [x9, #32]
>> +ldr x3, [x9, #24]
>> +ldr x2, [x9, #16]
>> +ldr x1, [x9, #8]
>> +ldr x0, [x9]
>> +
>> +0:  br  x8
>> +
>> +//
>> +// More than 64 bytes: we need to build the full native stack frame
>> and copy
>> +// the part of the VM stack exceeding 64 bytes (which may contain
>> stacked
>> +// arguments) to the native stack
>> +//
>> +1:  stp x29, x30, [sp, #-16]!
>> +mov x29, sp
>> +
>> +//
>> +// Ensure that the stack pointer remains 16 byte aligned,
>> +// even if the

Re: [edk2] [PATCH 2/2] MdeModulePkg/EbcDxe: cleanup

2016-08-05 Thread Daniil Egranov


Hi Ard,


On 08/01/2016 09:22 AM, Ard Biesheuvel wrote:

- indentation
- premature optimization of the thunking code, i.e., align function prototypes
   so we don't have to move arguments around or duplicate them on the stack,
   and perform tail calls where possible
- adhere to calling convention (stack frame layout)
- replace instruction buffer with a fixed struct, so that we no longer have
   to traverse it to find the entry point slots

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
  MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S | 188 ++-
  MdeModulePkg/Universal/EbcDxe/AArch64/EbcSupport.c  | 193 ++--
  2 files changed, 159 insertions(+), 222 deletions(-)

diff --git a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S 
b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
index 3c1a461f5e87..d0a5a4c5a37d 100644
--- a/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
+++ b/MdeModulePkg/Universal/EbcDxe/AArch64/EbcLowLevel.S
@@ -1,10 +1,12 @@
  ///** @file
  //
-//This code provides low level routines that support the Virtual Machine
-//   for option ROMs.
+//  This code provides low level routines that support the Virtual Machine
+//  for option ROMs.
  //
-//  Copyright (c) 2015, The Linux Foundation. All rights reserved.
+//  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
+//  Copyright (c) 2015, The Linux Foundation. All rights reserved.
  //  Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+//
  //  This program and the accompanying materials
  //  are licensed and made available under the terms and conditions of the BSD 
License
  //  which accompanies this distribution.  The full text of the license may be 
found at
@@ -15,9 +17,10 @@
  //
  //**/
  
-ASM_GLOBAL ASM_PFX(CopyMem);

-ASM_GLOBAL ASM_PFX(EbcInterpret);
-ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
+ASM_GLOBAL ASM_PFX(EbcLLEbcInterpret);
+ASM_GLOBAL ASM_PFX(EbcLLExecuteEbcImageEntryPoint);
+
+ASM_GLOBAL ASM_PFX(mEbcInstructionBufferTemplate);
The ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative); is missing here. The linking 
fails without it.
  
  //

  // EbcLLCALLEX
@@ -30,102 +33,121 @@ ASM_GLOBAL ASM_PFX(ExecuteEbcImageEntryPoint);
  //
  //
  // UINTN EbcLLCALLEXNative(UINTN FuncAddr, UINTN NewStackPointer, VOID 
*FramePtr)
-ASM_GLOBAL ASM_PFX(EbcLLCALLEXNative);
  ASM_PFX(EbcLLCALLEXNative):
-  stp  x19, x20, [sp, #-16]!
-  stp  x29, x30, [sp, #-16]!
-
-  mov  x19, x0
-  mov  x20, sp
-  sub  x2, x2, x1   // Length = NewStackPointer-FramePtr
-  sub  sp, sp, x2
-  sub  sp, sp, #64  // Make sure there is room for at least 8 args in the 
new stack
-  mov  x0, sp
-
-  bl   CopyMem  // Sp, NewStackPointer, Length
-
-  ldp  x0, x1, [sp], #16
-  ldp  x2, x3, [sp], #16
-  ldp  x4, x5, [sp], #16
-  ldp  x6, x7, [sp], #16
-
-  blr  x19
-
-  mov  sp,  x20
-  ldp  x29, x30, [sp], #16
-  ldp  x19, x20, [sp], #16
-
-  ret
+mov x8, x0 // Preserve x0
+mov x9, x1 // Preserve x1
+
+//
+// If the EBC stack frame is smaller than or equal to 64 bytes, we know 
there
+// are no stacked arguments #9 and beyond that we need to copy to the 
native
+// stack. In this case, we can perform a tail call which is much more
+// efficient, since there is no need to touch the native stack at all.
+//
+sub x3, x2, x1  // Length = NewStackPointer - FramePtr
+cmp x3, #64
+b.gt1f
+
+adr x0, 0f
+sub x0, x0, x3, lsr #1
+br  x0
+
+ldr x7, [x9, #56]
+ldr x6, [x9, #48]
+ldr x5, [x9, #40]
+ldr x4, [x9, #32]
+ldr x3, [x9, #24]
+ldr x2, [x9, #16]
+ldr x1, [x9, #8]
+ldr x0, [x9]
+
+0:  br  x8
+
+//
+// More than 64 bytes: we need to build the full native stack frame and 
copy
+// the part of the VM stack exceeding 64 bytes (which may contain stacked
+// arguments) to the native stack
+//
+1:  stp x29, x30, [sp, #-16]!
+mov x29, sp
+
+//
+// Ensure that the stack pointer remains 16 byte aligned,
+// even if the size of the VM stack frame is not a multiple of 16
+//
+add x1, x1, #64 // Skip over [potential] reg params
+tbz x3, #3, 2f  // Multiple of 16?
+ldr x4, [x2, #-8]!  // No? Then push one word
+str x4, [sp, #-16]! // ... but use two slots
+b   3f
+
+2:  ldp x4, x5, [x2, #-16]!
+stp x4, x5, [sp, #-16]!
+3:  cmp x2, x1
+b.gt2b
+
+ldp x0, x1, [x9]
+ldp x2, x3, [x9, #16]
+ldp x4, x5, [x9, #32]
+ldp x6, x7, [x9, #48]
+
+blr x8
+
+

Re: [edk2] Shell version 2.2

2016-08-05 Thread Tim Lewis

Yes,  but they are the same numbers. So I think this is probably a 

The specification says (in the Shell protocol section's Related Defintiions):

#define EFI_SHELL_MAJOR_VERSION 2
#define EFI_SHELL_MINOR_VERSION 2

And, from ver.c:

ShellPrintHiiEx (
  0,
  gST->ConOut->Mode->CursorRow,
  NULL,
  STRING_TOKEN (STR_VER_OUTPUT_SIMPLE),
  gShellLevel3HiiHandle,
  gEfiShellProtocol->MajorVersion,
  gEfiShellProtocol->MinorVersion
 );

And the shell protocol instance comes from ShellProtocol.c (see below):

EFI_SHELL_PROTOCOL mShellProtocol = {
  EfiShellExecute,
  EfiShellGetEnv,
  EfiShellSetEnv,
  EfiShellGetAlias,
  EfiShellSetAlias,
  EfiShellGetHelpText,
  EfiShellGetDevicePathFromMap,
  EfiShellGetMapFromDevicePath,
  EfiShellGetDevicePathFromFilePath,
  EfiShellGetFilePathFromDevicePath,
  EfiShellSetMap,
  EfiShellGetCurDir,
  EfiShellSetCurDir,
  EfiShellOpenFileList,
  EfiShellFreeFileList,
  EfiShellRemoveDupInFileList,
  EfiShellBatchIsActive,
  EfiShellIsRootShell,
  EfiShellEnablePageBreak,
  EfiShellDisablePageBreak,
  EfiShellGetPageBreak,
  EfiShellGetDeviceName,
  (EFI_SHELL_GET_FILE_INFO)FileHandleGetInfo, //*
  (EFI_SHELL_SET_FILE_INFO)FileHandleSetInfo, //*
  EfiShellOpenFileByName,
  EfiShellClose,
  EfiShellCreateFile,
  (EFI_SHELL_READ_FILE)FileHandleRead,//*
  (EFI_SHELL_WRITE_FILE)FileHandleWrite,  //*
  (EFI_SHELL_DELETE_FILE)FileHandleDelete,//*
  EfiShellDeleteFileByName,
  (EFI_SHELL_GET_FILE_POSITION)FileHandleGetPosition, //*
  (EFI_SHELL_SET_FILE_POSITION)FileHandleSetPosition, //*
  (EFI_SHELL_FLUSH_FILE)FileHandleFlush,  //*
  EfiShellFindFiles,
  EfiShellFindFilesInDir,
  (EFI_SHELL_GET_FILE_SIZE)FileHandleGetSize, //*
  EfiShellOpenRoot,
  EfiShellOpenRootByHandle,
  NULL,
  SHELL_MAJOR_VERSION,
  SHELL_MINOR_VERSION,

  // New for UEFI Shell 2.1
  EfiShellRegisterGuidName,
  EfiShellGetGuidName,
  EfiShellGetGuidFromName,
  EfiShellGetEnvEx
};

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Friday, August 05, 2016 12:10 PM
To: Tim Lewis ; Meenakshi Aggarwal 
; edk2-devel@lists.01.org 
Cc: Carsey, Jaben 
Subject: Re: [edk2] Shell version 2.2

Tim,

Yes, ver command would output that the version of the shell is different.

The #define below is specifically the version of the Protocol, not the version 
of the spec.

It could have been a miss on the part of the committee, but that was hoe I 
interpreted the non-change to the protocol version.

-Jaben

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Friday, August 5, 2016 11:36 AM
> To: Carsey, Jaben ; Meenakshi Aggarwal 
> ; edk2-devel@lists.01.org  de...@ml01.01.org>
> Subject: RE: Shell version 2.2
> Importance: High
> 
> Jaben --
> 
> Are there no shell commands where the standard command-line parameters 
> have changed?
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Carsey, Jaben
> Sent: Friday, August 05, 2016 10:26 AM
> To: Meenakshi Aggarwal ; edk2- 
> de...@lists.01.org 
> Cc: Carsey, Jaben 
> Subject: Re: [edk2] Shell version 2.2
> 
> I think that that version (2.1) is correct for the version of the 
> protocol.  The protocol API was not changed for the UEFI Shell 2.2.
> 
> That is the current version and should support the 2.2 spec.
> 
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Meenakshi Aggarwal
> > Sent: Friday, August 5, 2016 2:20 AM
> > To: edk2-devel@lists.01.org 
> > Subject: [edk2] Shell version 2.2
> > Importance: High
> >
> > Hi,
> >
> >
> > I can see UEFI shell specification 2.2
> > (http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pd
> > f) is available, But on edk2 master branch current version of Shell 
> > is still showing
> 2.1.
> >
> > File:ShellPkg/Include/Protocol/EfiShell.h
> >
> > enum ShellVersion {
> >   SHELL_MAJOR_VERSION = 2,
> >   SHELL_MINOR_VERSION = 1
> > };
> >
> >
> >
> > Please tell if I am looking at correct file, actually I want to 
> > update my shell to 2.2, but it looks like edk2 master branch doesn't 
> > support shell
> specification 2.2.
> >
> > Is my understanding correct?
> >
> >
> >
> > Thanks & Regards,
> > Meenakshi
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
>

Re: [edk2] Shell version 2.2

2016-08-05 Thread Carsey, Jaben

Tim,

Yes, ver command would output that the version of the shell is different.

The #define below is specifically the version of the Protocol, not the version 
of the spec.

It could have been a miss on the part of the committee, but that was hoe I 
interpreted the non-change to the protocol version.

-Jaben

> -Original Message-
> From: Tim Lewis [mailto:tim.le...@insyde.com]
> Sent: Friday, August 5, 2016 11:36 AM
> To: Carsey, Jaben ; Meenakshi Aggarwal
> ; edk2-devel@lists.01.org  de...@ml01.01.org>
> Subject: RE: Shell version 2.2
> Importance: High
> 
> Jaben --
> 
> Are there no shell commands where the standard command-line parameters
> have changed?
> 
> Tim
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Carsey, Jaben
> Sent: Friday, August 05, 2016 10:26 AM
> To: Meenakshi Aggarwal ; edk2-
> de...@lists.01.org 
> Cc: Carsey, Jaben 
> Subject: Re: [edk2] Shell version 2.2
> 
> I think that that version (2.1) is correct for the version of the protocol.  
> The
> protocol API was not changed for the UEFI Shell 2.2.
> 
> That is the current version and should support the 2.2 spec.
> 
> -Jaben
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Meenakshi Aggarwal
> > Sent: Friday, August 5, 2016 2:20 AM
> > To: edk2-devel@lists.01.org 
> > Subject: [edk2] Shell version 2.2
> > Importance: High
> >
> > Hi,
> >
> >
> > I can see UEFI shell specification 2.2
> > (http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf)
> > is available, But on edk2 master branch current version of Shell is still 
> > showing
> 2.1.
> >
> > File:ShellPkg/Include/Protocol/EfiShell.h
> >
> > enum ShellVersion {
> >   SHELL_MAJOR_VERSION = 2,
> >   SHELL_MINOR_VERSION = 1
> > };
> >
> >
> >
> > Please tell if I am looking at correct file, actually I want to update
> > my shell to 2.2, but it looks like edk2 master branch doesn't support shell
> specification 2.2.
> >
> > Is my understanding correct?
> >
> >
> >
> > Thanks & Regards,
> > Meenakshi
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]

2016-08-05 Thread Laszlo Ersek

On 08/05/16 18:12, Cohen, Eugene wrote:
> We've been hit by this same kind of issue and it's really painful, especially 
> as it affects shipping systems.
> 
> Long term I think we need an extensible/revisioned data format so we can get 
> forwards and backwards compatibility between NVRAM data and FW.

In OVMF we have a (very rudimentary) implementation for this, see
PlatformConfigLoad() in "OvmfPkg/PlatformDxe/PlatformConfig.c".

The idea is shamelessly stolen from UEFI protocols:
- we store the config structure in some NV variable under some
  namespace GUID,
- new fields can only be added after existing fields to the structure,
- if a new field would change the meaning of a preexistent field, or
  some preexistent fields would have to be dropped / replaced, then the
  change is deemed incompatible, and a new variable name or namespace
  GUID is required.

The number of bytes the config reader function reads from the variable
is the minimum of:
(a) the size of the variable,
(b) the size of largest structure version known to the config reader.

If a==b, then it's a version match. If a>b, then it's a firmware
downgrade (unknown fields are ignored). If a

Re: [edk2] Shell version 2.2

2016-08-05 Thread Tim Lewis

Jaben --

Are there no shell commands where the standard command-line parameters have 
changed? 

Tim

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, 
Jaben
Sent: Friday, August 05, 2016 10:26 AM
To: Meenakshi Aggarwal ; edk2-devel@lists.01.org 

Cc: Carsey, Jaben 
Subject: Re: [edk2] Shell version 2.2

I think that that version (2.1) is correct for the version of the protocol.  
The protocol API was not changed for the UEFI Shell 2.2. 

That is the current version and should support the 2.2 spec.

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Meenakshi Aggarwal
> Sent: Friday, August 5, 2016 2:20 AM
> To: edk2-devel@lists.01.org 
> Subject: [edk2] Shell version 2.2
> Importance: High
> 
> Hi,
> 
> 
> I can see UEFI shell specification 2.2
> (http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) is
> available, But on edk2 master branch current version of Shell is still 
> showing 2.1.
> 
> File:ShellPkg/Include/Protocol/EfiShell.h
> 
> enum ShellVersion {
>   SHELL_MAJOR_VERSION = 2,
>   SHELL_MINOR_VERSION = 1
> };
> 
> 
> 
> Please tell if I am looking at correct file, actually I want to update my 
> shell to
> 2.2, but it looks like edk2 master branch doesn't support shell specification 
> 2.2.
> 
> Is my understanding correct?
> 
> 
> 
> Thanks & Regards,
> Meenakshi
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/2] ArmVirtPkg/PrePi: use correct callee saved regs

2016-08-05 Thread Laszlo Ersek

On 08/05/16 16:53, Ard Biesheuvel wrote:
> Both the ARM and the AARCH64 versions of the PrePi code (shared between
> ArmVirtQemuKernel and ArmVirtXen) 'preserve' values across a function
> call using registers that are not in fact callee saved. So fix that.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 24 ++--
>  ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S | 10 
>  2 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S 
> b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
> index 68049d5df2bf..e61f5df12e89 100644
> --- a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
> +++ b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
> @@ -71,7 +71,7 @@ ASM_PFX(_ModuleEntryPoint):
>// Get ID of this CPU in Multicore system
>blASM_PFX(ArmReadMpidr)
>// Keep a copy of the MpId register value
> -  mov   x10, x0
> +  mov   x20, x0
>  
>  // Check if we can install the stack at the top of the System Memory or if 
> we need
>  // to install the stacks at the bottom of the Firmware Device (case the FD 
> is located
> @@ -113,39 +113,39 @@ _SetupStack:
>// Because the 'push' instruction is equivalent to 'stmdb' (decrement 
> before), we need to increment
>// one to the top of the stack. We check if incrementing one does not 
> overflow (case of DRAM at the
>// top of the memory space)
> -  adds  x11, x1, #1
> +  adds  x21, x1, #1
>b.cs  _SetupOverflowStack
>  
>  _SetupAlignedStack:
> -  mov   x1, x11
> +  mov   x1, x21
>b _GetBaseUefiMemory
>  
>  _SetupOverflowStack:
>// Case memory at the top of the address space. Ensure the top of the 
> stack is EFI_PAGE_SIZE
>// aligned (4KB)
>LoadConstantToReg (EFI_PAGE_MASK, x11)
> -  and   x11, x11, x1
> -  sub   x1, x1, x11
> +  and   x21, x21, x1
> +  sub   x1, x1, x21
>  
>  _GetBaseUefiMemory:
>// Calculate the Base of the UEFI Memory
> -  sub   x11, x1, x4
> +  sub   x21, x1, x4
>  
>  _GetStackBase:
>// r1 = The top of the Mpcore Stacks
>// Stack for the primary core = PrimaryCoreStack
>LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), x2)
> -  sub   x12, x1, x2
> +  sub   x22, x1, x2
>  
>// Stack for the secondary core = Number of Cores - 1
>LoadConstantToReg (FixedPcdGet32(PcdCoreCount), x0)
>sub   x0, x0, #1
>LoadConstantToReg (FixedPcdGet32(PcdCPUCoreSecondaryStackSize), x1)
>mul   x1, x1, x0
> -  sub   x12, x12, x1
> +  sub   x22, x22, x1
>  
>// x12 = The base of the MpCore Stacks (primary stack & secondary stacks)
> -  mov   x0, x12
> +  mov   x0, x22
>mov   x1, x10
>//ArmPlatformStackSet(StackBase, MpId, PrimaryStackSize, 
> SecondaryStackSize)
>LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), x2)
> @@ -159,9 +159,9 @@ _GetStackBase:
>bne   _PrepareArguments
>  
>  _PrepareArguments:
> -  mov   x0, x10
> -  mov   x1, x11
> -  mov   x2, x12
> +  mov   x0, x20
> +  mov   x1, x21
> +  mov   x2, x22
>  
>// Move sec startup address into a data register
>// Ensure we're jumping to FV version of the code (not boot remapped alias)
> diff --git a/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S 
> b/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
> index 441db36857de..3215c7d55876 100644
> --- a/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
> +++ b/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
> @@ -154,17 +154,17 @@ _GetStackBase:
>// r1 = The top of the Mpcore Stacks
>// Stack for the primary core = PrimaryCoreStack
>LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), r2)
> -  sub   r12, r1, r2
> +  sub   r9, r1, r2
>  
>// Stack for the secondary core = Number of Cores - 1
>LoadConstantToReg (FixedPcdGet32(PcdCoreCount), r0)
>sub   r0, r0, #1
>LoadConstantToReg (FixedPcdGet32(PcdCPUCoreSecondaryStackSize), r1)
>mul   r1, r1, r0
> -  sub   r12, r12, r1
> +  sub   r9, r9, r1
>  
> -  // r12 = The base of the MpCore Stacks (primary stack & secondary stacks)
> -  mov   r0, r12
> +  // r9 = The base of the MpCore Stacks (primary stack & secondary stacks)
> +  mov   r0, r9
>mov   r1, r10
>//ArmPlatformStackSet(StackBase, MpId, PrimaryStackSize, 
> SecondaryStackSize)
>LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), r2)
> @@ -180,7 +180,7 @@ _GetStackBase:
>  _PrepareArguments:
>mov   r0, r10
>mov   r1, r11
> -  mov   r2, r12
> +  mov   r2, r9
>  
>// Move sec startup address into a data register
>// Ensure we're jumping to FV version of the code (not boot remapped alias)
> 

Callee saved, caller saved... Bah! :)

Acked-by: Laszlo Ersek 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Shell version 2.2

2016-08-05 Thread Carsey, Jaben

I think that that version (2.1) is correct for the version of the protocol.  
The protocol API was not changed for the UEFI Shell 2.2. 

That is the current version and should support the 2.2 spec.

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Meenakshi Aggarwal
> Sent: Friday, August 5, 2016 2:20 AM
> To: edk2-devel@lists.01.org 
> Subject: [edk2] Shell version 2.2
> Importance: High
> 
> Hi,
> 
> 
> I can see UEFI shell specification 2.2
> (http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) is
> available, But on edk2 master branch current version of Shell is still 
> showing 2.1.
> 
> File:ShellPkg/Include/Protocol/EfiShell.h
> 
> enum ShellVersion {
>   SHELL_MAJOR_VERSION = 2,
>   SHELL_MINOR_VERSION = 1
> };
> 
> 
> 
> Please tell if I am looking at correct file, actually I want to update my 
> shell to
> 2.2, but it looks like edk2 master branch doesn't support shell specification 
> 2.2.
> 
> Is my understanding correct?
> 
> 
> 
> Thanks & Regards,
> Meenakshi
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg SmbiosView: Show "SocketDesignation" instead of "Socket" for Type 4

2016-08-05 Thread Carsey, Jaben

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Zeng, Star
> Sent: Friday, August 5, 2016 2:02 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Chan, Amy ; Ni,
> Ruiyu ; Carsey, Jaben 
> Subject: [PATCH] ShellPkg SmbiosView: Show "SocketDesignation" instead of
> "Socket" for Type 4
> Importance: High
> 
> It is to make the info shown more aligned with SMBIOS spec.
> 
> Cc: Amy Chan 
> Cc: Ruiyu Ni 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c | 4 ++-
> -
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> index 3f99dc4825dc..7e17b69d5afa 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> @@ -1,7 +1,7 @@
>  /** @file
>Module for clarifying the content of the smbios structure element 
> information.
> 
> -  Copyright (c) 2005 - 2015, Intel Corporation. All rights reserved.
> +  Copyright (c) 2005 - 2016, Intel Corporation. All rights
> + reserved.
>(C) Copyright 2014 Hewlett-Packard Development Company, L.P.
>(C) Copyright 2015 Hewlett Packard Enterprise Development LP
>This program and the accompanying materials @@ -399,7 +399,7 @@
> SmbiosPrintStructure (
>// Processor Information (Type 4)
>//
>case 4:
> -PRINT_PENDING_STRING (Struct, Type4, Socket);
> +PRINT_SMBIOS_STRING (Struct, Struct->Type4->Socket,
> + SocketDesignation)
>  DisplayProcessorType (Struct->Type4->ProcessorType, Option);
>  if (AE_SMBIOS_VERSION (0x2, 0x6) && (Struct->Hdr->Length > 0x28) &&
>  (Struct->Type4->ProcessorFamily == 0xFE)) {
> --
> 2.8.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

2016-08-05 Thread evan . lloyd

From: Alexei 

This commit fixes a bug in the GIC v2 and v3 drivers where the GICC_EOIR
(End Of Interrupt Register) is written twice for a single interrupt.
GicV(2|3)IrqInterruptHandler() calls the Interrupt Handler and then
GicV(2|3)EndOfInterrupt() on exit:

 InterruptHandler = gRegisteredInterruptHandlers[GicInterrupt];
 if (InterruptHandler != NULL) {
   // Call the registered interrupt handler.
   InterruptHandler (GicInterrupt, SystemContext);
 } else {
   DEBUG ((EFI_D_ERROR, "Spurious GIC interrupt: 0x%x\n", GicInterrupt));
 }

 GicV2EndOfInterrupt (, GicInterrupt);

, although gInterrupt->EndOfInterrupt() has already been called by
InterruptHandler().

The fix moves the EndOfInterrupt() call inside the else case for
unregistered/spurious interrupts.  This removes a potential race
condition that might have lost interrupts.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Alexei Fedorov 
Signed-off-by: Evan Lloyd 
---

Code is available at:
https://github.com/EvanLloyd/tianocore/tree/EOIR_v1

 ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c | 5 ++---
 ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c | 5 ++---
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c 
b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
index 
036eb5cd6bf6845dd2b03b62c933c1dedaef7251..34d4be3867647e0fdad7356c949af8cd3ede7164
 100644
--- a/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
+++ b/ArmPkg/Drivers/ArmGic/GicV2/ArmGicV2Dxe.c
@@ -2,7 +2,7 @@
 
 Copyright (c) 2009, Hewlett-Packard Company. All rights reserved.
 Portions copyright (c) 2010, Apple Inc. All rights reserved.
-Portions copyright (c) 2011-2015, ARM Ltd. All rights reserved.
+Portions copyright (c) 2011-2016, ARM Ltd. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -178,9 +178,8 @@ GicV2IrqInterruptHandler (
 InterruptHandler (GicInterrupt, SystemContext);
   } else {
 DEBUG ((EFI_D_ERROR, "Spurious GIC interrupt: 0x%x\n", GicInterrupt));
+GicV2EndOfInterrupt (, GicInterrupt);
   }
-
-  GicV2EndOfInterrupt (, GicInterrupt);
 }
 
 //
diff --git a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c 
b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
index 
106c669fcb8777dfaad609c0ce9f5b572727a3ff..983936f3738a74bb5d5e08e012973df240958a8b
 100644
--- a/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
+++ b/ArmPkg/Drivers/ArmGic/GicV3/ArmGicV3Dxe.c
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
+*  Copyright (c) 2011-2016, ARM Limited. All rights reserved.
 *
 *  This program and the accompanying materials
 *  are licensed and made available under the terms and conditions of the BSD 
License
@@ -169,9 +169,8 @@ GicV3IrqInterruptHandler (
 InterruptHandler (GicInterrupt, SystemContext);
   } else {
 DEBUG ((EFI_D_ERROR, "Spurious GIC interrupt: 0x%x\n", GicInterrupt));
+GicV3EndOfInterrupt (, GicInterrupt);
   }
-
-  GicV3EndOfInterrupt (, GicInterrupt);
 }
 
 //
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]

2016-08-05 Thread Cohen, Eugene

We've been hit by this same kind of issue and it's really painful, especially 
as it affects shipping systems.

Long term I think we need an extensible/revisioned data format so we can get 
forwards and backwards compatibility between NVRAM data and FW.

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Larry Cleeton
> Sent: Friday, August 05, 2016 9:35 AM
> To: Ye, Ting ; edk2-devel@lists.01.org
> Subject: Re: [edk2] Breaking change issue with
> NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]
> 
> I agree with your assessment about leaving the data structure as it is.   I 
> just
> wanted to highlight it as it may impact others.
> 
> The bottom line is my development group is entirely responsible for vetting
> any changes coming from the EDK2 into our product.  This one slipped by us.
> 
> --Larry
> 
> -Original Message-
> From: Ye, Ting [mailto:ting...@intel.com]
> Sent: Thursday, August 4, 2016 8:25 PM
> To: Larry Cleeton ; edk2-devel@lists.01.org
> Subject: RE: Breaking change issue with
> NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]
> 
> Hi Larry,
> 
> We are very sorry about the impact you suffered today. We made the
> change in early 2013 to support the existing NVRAM variable when firmware
> image was updated from IA32 to X64. Unfortunately we introduced an
> incompatibility issue as you raised. Now we prefer to keep the existing
> definition, since if we change it back that would introduce another similar
> incompatibility issue. What do you think about this?
> 
> Best Regards,
> Ye Ting
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Larry Cleeton
> Sent: Wednesday, August 03, 2016 4:55 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Breaking change issue with
> NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]
> 
> This commit (fdc4b0b147b386e966e99893526181dfae9eaeef) changed a data
> structure that is stored in an NVRAM variable.
> See NetworkPkg/Ip6Dxe/Ip6ConfigImpl.[c,h]
> 
> This data structure:
> 
> typedef struct {
>   UINT16Offset;
>   UINTN DataSize;
>   EFI_IP6_CONFIG_DATA_TYPE  DataType;
> } IP6_CONFIG_DATA_RECORD;
> 
> Is now:
> 
> typedef struct {
>   UINT16Offset;
>   UINT32 DataSize;< changed size in 
> 64bit
> environments
>   EFI_IP6_CONFIG_DATA_TYPE  DataType;
> } IP6_CONFIG_DATA_RECORD;
> 
> Unfortunately with a 64bit implementation this current structure is now
> *not* compatible with an existing NVRAM variable written with the previous
> version of the structure. It's causing me considerable grief so I'm just 
> sharing
> the discovery.  It would only impact you if you update some 64bit machine's
> firmware with a new version containing this change.
> 
> --Larry
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]

2016-08-05 Thread Larry Cleeton

I agree with your assessment about leaving the data structure as it is.   I 
just wanted to highlight it as it may impact others.  

The bottom line is my development group is entirely responsible for vetting any 
changes coming from the EDK2 into our product.  This one slipped by us.

--Larry

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com] 
Sent: Thursday, August 4, 2016 8:25 PM
To: Larry Cleeton ; edk2-devel@lists.01.org
Subject: RE: Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]

Hi Larry,

We are very sorry about the impact you suffered today. We made the change in 
early 2013 to support the existing NVRAM variable when firmware image was 
updated from IA32 to X64. Unfortunately we introduced an incompatibility issue 
as you raised. Now we prefer to keep the existing definition, since if we 
change it back that would introduce another similar incompatibility issue. What 
do you think about this?

Best Regards,
Ye Ting

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Larry 
Cleeton
Sent: Wednesday, August 03, 2016 4:55 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, 
h]

This commit (fdc4b0b147b386e966e99893526181dfae9eaeef) changed a data structure 
that is stored in an NVRAM variable. 
See NetworkPkg/Ip6Dxe/Ip6ConfigImpl.[c,h]

This data structure:

typedef struct {
  UINT16Offset;
  UINTN DataSize;
  EFI_IP6_CONFIG_DATA_TYPE  DataType;
} IP6_CONFIG_DATA_RECORD;

Is now:

typedef struct {
  UINT16Offset;
  UINT32 DataSize;< changed size in 
64bit environments
  EFI_IP6_CONFIG_DATA_TYPE  DataType;
} IP6_CONFIG_DATA_RECORD;

Unfortunately with a 64bit implementation this current structure is now *not* 
compatible with an existing NVRAM variable written with the previous version of 
the structure. It's causing me considerable grief so I'm just sharing the 
discovery.  It would only impact you if you update some 64bit machine's 
firmware with a new version containing this change.

--Larry
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] IntelFsp2Pkg: Converted PatchFvUserManual from .docx to .md format

2016-08-05 Thread Giri P Mudusuru

Converted the the word format of the documentation into markdown format
for PatchFvUserManual

Cc: Jiewen Yao 
Cc: Maurice Ma 
Cc: Satya Yarlagadda 
Cc: Satya Yarlagadda 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru 
---
 .../Tools/UserManuals/PatchFvUserManual.docx   | Bin 21481 -> 0 bytes
 .../Tools/UserManuals/PatchFvUserManual.md | 123 +
 2 files changed, 123 insertions(+)
 delete mode 100644 IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.docx
 create mode 100644 IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.md

diff --git a/IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.docx 
b/IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.docx
deleted file mode 100644
index 
ab1eda993e7b7d249a0390dc1db83ff4987395da..
GIT binary patch
literal 0
HcmV?d1

literal 21481
zcmeF2^Ot7LlBnOZZQHhOS9RI8ZQJbXQkT1I+cvvwSC{R&^?he%%{h0@z5l?>{vlVs
zd+!w)J2T>q^+aYU%7B2P0>A-~004jp07V)e6bJ+W#DM_-C;&)cZ4rAr7gIYIeHBj!
zQ)gXz4_h0;d{AJ@TmbOb`~Q3W51xUB6gh=pLBz02@(+kQb#-Wsl-1`!_it7$~
zk(CiY6Z6;mOFU_rvbsja{LR`8+)Cb2D=pf#sNGqBhRAwjv6TW+-I_-vs)=5{5{jX
zMiIUmGWc38{B*yjx9K81|C&13g4o9cIfL>)8z|>nDwIQ>@Jak`?)cbyWhaGA%jM^8!HATF%CcP_
zL5}LjEvgry8hx+h-AZSX?m_#k*vi*>eNd5~j4|SED8w@zAX_@G=FT=Iahh``vK_9H
zul=9-=NmyKWyaWC5d4%DYNBfqY;g_VQx^zj=cz)!cPBa4T%Mo+fX`15fa1S+E`B0*
z^X->8%6~Z~%$MitJDJ)zGtmFl{;$XW4|dak`t+EjHE9qb*sx2mEyEFCjx}iFxs^@H
zJa^(hAR*~zK<@Apg{xhi1%z#iYkG%wN8<{=GlMf1c#3(!s|__5bC)v>B(|(QY@4GY
z6g5Y*GlIo3Yds=!A}Rsk9~FNSt}LqMcSi|*_F
zDiU1JV8QtsZ(TAA(-aETe0B
zUaDQIdr|cc7(cc?=$B(3an0Dl5PA@wjlBZBW(cV*J{a(Q$o=Q?55v^RX
zl4LEVhSY+NV_aE?meCn@jiCgOz6|s)1`m?OWZD3RB$H8Jfnd|%35#TyLyl*v=q6i~
z5r1=@%Ge<5;%w_0)}U=j(H%2P=3fi}plj~C+oMk{eY*j|wkht%tb=2VZ^<7*otSzt
zB#mg>1$j5()`|Nj?B#kf;PE;Cbe
zY8PeM!|K-3yEgKX>dPCSUf(+p^+FK%bspgVos9_)mxQWd006lu007dL>HKYD|7=}n
zeAdouBZ*tpryn3ujhl5Sn&7?7^hT))+NyPxNw}Bip1Smipk!G>0YHMItIpqE32vxV
zM|0Nnoi=U(=HMWRq-2#1H0pKiKohbG3f)ER#YYPMAIy)jG8|EzjGPrJkCRb5;PRaJ
zLAU*5`kS#i%{1a!%e@N^{XKjYI_-`J(;J^}@dCPdvLfbO?!f~A^g(+A^hqX;
zSG!_oIxWsTn>pU{s6#unEAD;I(GKjlxQ~OXm~#3WW{aesTB3P-LrgIoHNi4GRW%of
zE1P|xI6WHmj2UZE9R%V>42N!ao~<76oeXCKnI2s~bVRnylHF18)l!uldH`P8z#($*
zl!9jro5W)i!YuT*Tqc-=BwZ0Y1O|}7Pkq`IMYXo}jDs-nbEdPT^hf-k7gkD@=0h^Y
zI%aTTiN0VmwWo~pKf$q-S1m4-dADDx)Kt%FtgFkbwyLdV6Rr~1|^n+vv`S236m!4uNu`aE|Rc4N6mYA#knI~{0-*10~5
zp8}jdp}$YHftH

[edk2] [PATCH 2/2] ArmPlatformPkg/PrePi: use correct callee saved regs

2016-08-05 Thread Ard Biesheuvel

The AARCH64 version of the PrePi code 'preserves' values across a function
call using registers that are not in fact callee saved. So fix that.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S | 32 ++--
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S 
b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
index 9538c70a237c..e939d2c5aa5e 100644
--- a/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
+++ b/ArmPlatformPkg/PrePi/AArch64/ModuleEntryPoint.S
@@ -36,7 +36,7 @@ ASM_PFX(_ModuleEntryPoint):
   // Get ID of this CPU in Multicore system
   blASM_PFX(ArmReadMpidr)
   // Keep a copy of the MpId register value
-  mov   x10, x0
+  mov   x20, x0
 
 _SetSVCMode:
 // Check if we can install the stack at the top of the System Memory or if we 
need
@@ -88,55 +88,55 @@ _SetupStack:
   // Because the 'push' instruction is equivalent to 'stmdb' (decrement 
before), we need to increment
   // one to the top of the stack. We check if incrementing one does not 
overflow (case of DRAM at the
   // top of the memory space)
-  adds  x11, x1, #1
+  adds  x21, x1, #1
   b.cs  _SetupOverflowStack
 
 _SetupAlignedStack:
-  mov   x1, x11
+  mov   x1, x21
   b _GetBaseUefiMemory
 
 _SetupOverflowStack:
   // Case memory at the top of the address space. Ensure the top of the stack 
is EFI_PAGE_SIZE
   // aligned (4KB)
-  LoadConstantToReg (EFI_PAGE_MASK, x11)
-  and   x11, x11, x1
-  sub   x1, x1, x11
+  LoadConstantToReg (EFI_PAGE_MASK, x21)
+  and   x21, x21, x1
+  sub   x1, x1, x21
 
 _GetBaseUefiMemory:
   // Calculate the Base of the UEFI Memory
-  sub   x11, x1, x4
+  sub   x21, x1, x4
 
 _GetStackBase:
   // r1 = The top of the Mpcore Stacks
   // Stack for the primary core = PrimaryCoreStack
   LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), x2)
-  sub   x12, x1, x2
+  sub   x22, x1, x2
 
   // Stack for the secondary core = Number of Cores - 1
   LoadConstantToReg (FixedPcdGet32(PcdCoreCount), x0)
   sub   x0, x0, #1
   LoadConstantToReg (FixedPcdGet32(PcdCPUCoreSecondaryStackSize), x1)
   mul   x1, x1, x0
-  sub   x12, x12, x1
+  sub   x22, x22, x1
 
-  // x12 = The base of the MpCore Stacks (primary stack & secondary stacks)
-  mov   x0, x12
-  mov   x1, x10
+  // x22 = The base of the MpCore Stacks (primary stack & secondary stacks)
+  mov   x0, x22
+  mov   x1, x20
   //ArmPlatformStackSet(StackBase, MpId, PrimaryStackSize, SecondaryStackSize)
   LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), x2)
   LoadConstantToReg (FixedPcdGet32(PcdCPUCoreSecondaryStackSize), x3)
   blASM_PFX(ArmPlatformStackSet)
 
   // Is it the Primary Core ?
-  mov   x0, x10
+  mov   x0, x20
   blASM_PFX(ArmPlatformIsPrimaryCore)
   cmp   x0, #1
   bne   _PrepareArguments
 
 _PrepareArguments:
-  mov   x0, x10
-  mov   x1, x11
-  mov   x2, x12
+  mov   x0, x20
+  mov   x1, x21
+  mov   x2, x22
 
   // Move sec startup address into a data register
   // Ensure we're jumping to FV version of the code (not boot remapped alias)
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/2] ArmVirtPkg/PrePi: use correct callee saved regs

2016-08-05 Thread Ard Biesheuvel

Both the ARM and the AARCH64 versions of the PrePi code (shared between
ArmVirtQemuKernel and ArmVirtXen) 'preserve' values across a function
call using registers that are not in fact callee saved. So fix that.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S | 24 ++--
 ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S | 10 
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S 
b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
index 68049d5df2bf..e61f5df12e89 100644
--- a/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
+++ b/ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S
@@ -71,7 +71,7 @@ ASM_PFX(_ModuleEntryPoint):
   // Get ID of this CPU in Multicore system
   blASM_PFX(ArmReadMpidr)
   // Keep a copy of the MpId register value
-  mov   x10, x0
+  mov   x20, x0
 
 // Check if we can install the stack at the top of the System Memory or if we 
need
 // to install the stacks at the bottom of the Firmware Device (case the FD is 
located
@@ -113,39 +113,39 @@ _SetupStack:
   // Because the 'push' instruction is equivalent to 'stmdb' (decrement 
before), we need to increment
   // one to the top of the stack. We check if incrementing one does not 
overflow (case of DRAM at the
   // top of the memory space)
-  adds  x11, x1, #1
+  adds  x21, x1, #1
   b.cs  _SetupOverflowStack
 
 _SetupAlignedStack:
-  mov   x1, x11
+  mov   x1, x21
   b _GetBaseUefiMemory
 
 _SetupOverflowStack:
   // Case memory at the top of the address space. Ensure the top of the stack 
is EFI_PAGE_SIZE
   // aligned (4KB)
   LoadConstantToReg (EFI_PAGE_MASK, x11)
-  and   x11, x11, x1
-  sub   x1, x1, x11
+  and   x21, x21, x1
+  sub   x1, x1, x21
 
 _GetBaseUefiMemory:
   // Calculate the Base of the UEFI Memory
-  sub   x11, x1, x4
+  sub   x21, x1, x4
 
 _GetStackBase:
   // r1 = The top of the Mpcore Stacks
   // Stack for the primary core = PrimaryCoreStack
   LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), x2)
-  sub   x12, x1, x2
+  sub   x22, x1, x2
 
   // Stack for the secondary core = Number of Cores - 1
   LoadConstantToReg (FixedPcdGet32(PcdCoreCount), x0)
   sub   x0, x0, #1
   LoadConstantToReg (FixedPcdGet32(PcdCPUCoreSecondaryStackSize), x1)
   mul   x1, x1, x0
-  sub   x12, x12, x1
+  sub   x22, x22, x1
 
   // x12 = The base of the MpCore Stacks (primary stack & secondary stacks)
-  mov   x0, x12
+  mov   x0, x22
   mov   x1, x10
   //ArmPlatformStackSet(StackBase, MpId, PrimaryStackSize, SecondaryStackSize)
   LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), x2)
@@ -159,9 +159,9 @@ _GetStackBase:
   bne   _PrepareArguments
 
 _PrepareArguments:
-  mov   x0, x10
-  mov   x1, x11
-  mov   x2, x12
+  mov   x0, x20
+  mov   x1, x21
+  mov   x2, x22
 
   // Move sec startup address into a data register
   // Ensure we're jumping to FV version of the code (not boot remapped alias)
diff --git a/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S 
b/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
index 441db36857de..3215c7d55876 100644
--- a/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
+++ b/ArmVirtPkg/PrePi/Arm/ModuleEntryPoint.S
@@ -154,17 +154,17 @@ _GetStackBase:
   // r1 = The top of the Mpcore Stacks
   // Stack for the primary core = PrimaryCoreStack
   LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), r2)
-  sub   r12, r1, r2
+  sub   r9, r1, r2
 
   // Stack for the secondary core = Number of Cores - 1
   LoadConstantToReg (FixedPcdGet32(PcdCoreCount), r0)
   sub   r0, r0, #1
   LoadConstantToReg (FixedPcdGet32(PcdCPUCoreSecondaryStackSize), r1)
   mul   r1, r1, r0
-  sub   r12, r12, r1
+  sub   r9, r9, r1
 
-  // r12 = The base of the MpCore Stacks (primary stack & secondary stacks)
-  mov   r0, r12
+  // r9 = The base of the MpCore Stacks (primary stack & secondary stacks)
+  mov   r0, r9
   mov   r1, r10
   //ArmPlatformStackSet(StackBase, MpId, PrimaryStackSize, SecondaryStackSize)
   LoadConstantToReg (FixedPcdGet32(PcdCPUCorePrimaryStackSize), r2)
@@ -180,7 +180,7 @@ _GetStackBase:
 _PrepareArguments:
   mov   r0, r10
   mov   r1, r11
-  mov   r2, r12
+  mov   r2, r9
 
   // Move sec startup address into a data register
   // Ensure we're jumping to FV version of the code (not boot remapped alias)
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Platforms/ARM/Juno: limit ACPI support to v5.0 and higher

2016-08-05 Thread Sudeep Holla


Hi Evan,

On 27/07/16 15:23, Leif Lindholm wrote:

Looks sensible to me.

Unless Evan has any objections?

On 27 July 2016 at 10:53, Sudeep Holla  wrote:

The ACPI spec predates the AARCH64 architecture by 5 versions, so there
is no point in supporting anything below v5.0. So set the PCD that
controls the ACPI table generation to the appropriate value.

Based on the commit e0692789058e ("ArmVirtPkg/ArmVirtQemu: limit ACPI
support to v5.0 and higher") in the upstream TianoCore by Ard Biesheuvel

Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Leif Lindholm 
Reviewed-by: Ard Biesheuvel 
Signed-off-by: Sudeep Holla 
---
 Platforms/ARM/Juno/ArmJuno.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platforms/ARM/Juno/ArmJuno.dsc b/Platforms/ARM/Juno/ArmJuno.dsc
index 45d9950decba..2e9ccfbad396 100644
--- a/Platforms/ARM/Juno/ArmJuno.dsc
+++ b/Platforms/ARM/Juno/ArmJuno.dsc
@@ -174,6 +174,8 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }

+  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
+
 [PcdsPatchableInModule]
   # Console Resolution (Full HD)
   gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|1920



And any feedback on this too ?

--
Regards,
Sudeep
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Platforms/ARM/Juno: Add support for ACPI 6.0 LPI(Low Power Idle) states

2016-08-05 Thread Sudeep Holla


Hi Evan,

On 27/07/16 15:24, Leif Lindholm wrote:

Graeme/Evan?

On 27 July 2016 at 10:58, Sudeep Holla  wrote:

ACPI 6.0 introduced LPI(Low Power Idle) states that provides an alternate
method to describe processor idle states.

LPI extensions leverages the processor container device(again introduced
in ACPI 6.0) allowing to express which parts of the system are affected
by a given LPI state. It defines the local power states for each node
in a hierarchical processor topology. The OSPM can use _LPI object to
select a local power state for each level of processor hierarchy in the
system.

This patch adds LPI support on Juno.

Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Signed-off-by: Sudeep Holla 
---
 Platforms/ARM/Juno/AcpiTables/Dsdt.asl | 232 ++---
 1 file changed, 213 insertions(+), 19 deletions(-)

Hi Lief,

The support in the kernel is now added(latest mainline as of today) and
is enabled in defconfig. It's easy to test, just examine the sysfs entries:

/sys/devices/system/cpu/cpu*/cpuidle/state*/desc - Describes the cpuidle state
/sys/devices/system/cpu/cpu*/cpuidle/state*/{usage,time} - Should keep ticking
with time signifying that the idle states are entered and exited
correctly



Any feedback on this ?

--
Regards,
Sudeep
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] BaseTools X64: fold PLT relocations into simple relative references

2016-08-05 Thread Ard Biesheuvel

For X64/GCC, we use position independent code with hidden visibility
to inform the compiler that symbols references are never resolved at
runtime, which removes the need for PLTs and GOTs. However, in some
cases GCC has been reported to still emit PLT based relocations, which
we need to handle in the ELF to PE/COFF perform by GenFw.

Unlike GOT based relocations, which are non-trivial to handle since the
indirections in the code can not be fixed up easily (although relocation
types exist for X64 that annotate relocation targets as suitable for
relaxation), PLT relocations simply point to jump targets, and we can
relax such relocations by resolving them using the symbol directly rather
than via a PLT entry that does nothing more than tail call the function
we already know it is going to call (since all symbol references are
resolved in the same module).

So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation.

Suggested-by: Steven Shi 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 BaseTools/Source/C/GenFw/Elf64Convert.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 944c94b8f8b4..708c1a1d91a7 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -785,6 +785,17 @@ WriteSections64 (
 *(INT32 *)Targ = (INT32)((INT64)(*(INT32 *)Targ) - 
SymShdr->sh_addr + mCoffSectionsOffset[Sym->st_shndx]);
 VerboseMsg ("Relocation:  0x%08X", *(UINT32*)Targ);
 break;
+
+  case R_X86_64_PLT32:
+//
+// Treat R_X86_64_PLT32 relocations as R_X86_64_PC32: this is
+// possible since we know all code symbol references resolve to
+// definitions in the same module (UEFI has no shared libraries),
+// and so there is never a reason to jump via a PLT entry,
+// allowing us to resolve the reference using the symbol directly.
+//
+VerboseMsg ("Treating R_X86_64_PLT32 as R_X86_64_PC32 ...");
+/* fall through */
   case R_X86_64_PC32:
 //
 // Relative relocation: Symbol - Ip + Addend
@@ -935,6 +946,7 @@ WriteRelocations64 (
 switch (ELF_R_TYPE(Rel->r_info)) {
 case R_X86_64_NONE:
 case R_X86_64_PC32:
+case R_X86_64_PLT32:
   break;
 case R_X86_64_64:
   VerboseMsg ("EFI_IMAGE_REL_BASED_DIR64 Offset: 0x%08X", 
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] BaseTools GCC/ARM: add -fno-builtin to CC flags

2016-08-05 Thread Ard Biesheuvel

On 4 August 2016 at 18:01, Michael Zimmermann  wrote:
> not directly related but could we add nostdinc too? At least for my platform
> that works perfectly and it prevents you from accidentally including any
> libc/libgcc/whatever headers from your toolchain.(nostdlib is already
> enabled)
>

That sounds like a sensible idea, yes.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] BaseTools GCC/ARM: add -fno-builtin to CC flags

2016-08-05 Thread Ard Biesheuvel

On 5 August 2016 at 16:26, Gao, Liming  wrote:
> Reviewed-by: Liming Gao 
>

Thanks all

Pushed as

59ceaa0a871d ArmPkg/ArmSoftFloatLib: disable LTO build for GCC
f8c51389c6db ArmPkg/CompilerIntrinsicsLib: make the default memset() weak
0667e985270b BaseTools GCC/ARM: add -fno-builtin to CC flags


> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, August 4, 2016 10:43 PM
> To: Zhu, Yonghong ; Gao, Liming 
> ; edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org; eug...@hp.com; Ard Biesheuvel 
> 
> Subject: [PATCH 3/3] BaseTools GCC/ARM: add -fno-builtin to CC flags
>
> Avoid build errors when including OpensslLib, which may throw
> undefined reference errors for builtin functions if -fno-builtin
> is not specified (and it is already set for IA32, X64 and AARCH64)
> So set it for ARM as well.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  BaseTools/Conf/tools_def.template | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 88af82a683d9..4f1dd4be378e 100644
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4334,7 +4334,7 @@ DEFINE GCC_ALL_CC_FLAGS= -g -Os 
> -fshort-wchar -fno-strict-aliasing -
>  DEFINE GCC_IA32_CC_FLAGS   = DEF(GCC_ALL_CC_FLAGS) -m32 
> -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 
> -mno-stack-arg-probe
>  DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone 
> -Wno-address -mno-stack-arg-probe
>  DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) 
> -minline-int-divide-min-latency
> -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
> -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft
> +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections 
> -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -mthumb 
> -mfloat-abi=soft
>  DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian 
> -fno-short-enums -fverbose-asm -funsigned-char  -ffunction-sections 
> -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address 
> -fno-asynchronous-unwind-tables
>  DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align
>  DEFINE GCC_DLINK_FLAGS_COMMON  = -nostdlib --pie
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/3] Build fixes for ARM/OpenSSL

2016-08-05 Thread Leif Lindholm

I'm happy with these changes.
For the series:
Reviewed-by: Leif Lindholm 

On 4 August 2016 at 15:42, Ard Biesheuvel  wrote:
> This series addresses some issues that cause the build to be broken
> for ARM GCC5 at the moment when including OpensslLib in the build.
>
> Ard Biesheuvel (3):
>   ArmPkg/ArmSoftFloatLib: disable LTO build for GCC
>   ArmPkg/CompilerIntrinsicsLib: make the default memset() weak
>   BaseTools GCC/ARM: add -fno-builtin to CC flags
>
>  ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf | 2 +-
>  ArmPkg/Library/CompilerIntrinsicsLib/Arm/memset.S  | 8 
>  BaseTools/Conf/tools_def.template  | 2 +-
>  3 files changed, 10 insertions(+), 2 deletions(-)
>
> --
> 2.7.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] IntelFsp2Pkg: Converted PatchFvUserManual from .docx to .md format

2016-08-05 Thread Giri P Mudusuru

Converted the the word format of the documentation into markdown format
for PatchFvUserManual

Cc: Jiewen Yao 
Cc: Maurice Ma 
Cc: Satya Yarlagadda 
Cc: Satya Yarlagadda 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru 
---
 .../Tools/UserManuals/PatchFvUserManual.docx   | Bin 21481 -> 0 bytes
 .../Tools/UserManuals/PatchFvUserManual.md | 123 +
 2 files changed, 123 insertions(+)
 delete mode 100644 IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.docx
 create mode 100644 IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.md

diff --git a/IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.docx 
b/IntelFsp2Pkg/Tools/UserManuals/PatchFvUserManual.docx
deleted file mode 100644
index 
ab1eda993e7b7d249a0390dc1db83ff4987395da..
GIT binary patch
literal 0
HcmV?d1

literal 21481
zcmeF2^Ot7LlBnOZZQHhOS9RI8ZQJbXQkT1I+cvvwSC{R&^?he%%{h0@z5l?>{vlVs
zd+!w)J2T>q^+aYU%7B2P0>A-~004jp07V)e6bJ+W#DM_-C;&)cZ4rAr7gIYIeHBj!
zQ)gXz4_h0;d{AJ@TmbOb`~Q3W51xUB6gh=pLBz02@(+kQb#-Wsl-1`!_it7$~
zk(CiY6Z6;mOFU_rvbsja{LR`8+)Cb2D=pf#sNGqBhRAwjv6TW+-I_-vs)=5{5{jX
zMiIUmGWc38{B*yjx9K81|C&13g4o9cIfL>)8z|>nDwIQ>@Jak`?)cbyWhaGA%jM^8!HATF%CcP_
zL5}LjEvgry8hx+h-AZSX?m_#k*vi*>eNd5~j4|SED8w@zAX_@G=FT=Iahh``vK_9H
zul=9-=NmyKWyaWC5d4%DYNBfqY;g_VQx^zj=cz)!cPBa4T%Mo+fX`15fa1S+E`B0*
z^X->8%6~Z~%$MitJDJ)zGtmFl{;$XW4|dak`t+EjHE9qb*sx2mEyEFCjx}iFxs^@H
zJa^(hAR*~zK<@Apg{xhi1%z#iYkG%wN8<{=GlMf1c#3(!s|__5bC)v>B(|(QY@4GY
z6g5Y*GlIo3Yds=!A}Rsk9~FNSt}LqMcSi|*_F
zDiU1JV8QtsZ(TAA(-aETe0B
zUaDQIdr|cc7(cc?=$B(3an0Dl5PA@wjlBZBW(cV*J{a(Q$o=Q?55v^RX
zl4LEVhSY+NV_aE?meCn@jiCgOz6|s)1`m?OWZD3RB$H8Jfnd|%35#TyLyl*v=q6i~
z5r1=@%Ge<5;%w_0)}U=j(H%2P=3fi}plj~C+oMk{eY*j|wkht%tb=2VZ^<7*otSzt
zB#mg>1$j5()`|Nj?B#kf;PE;Cbe
zY8PeM!|K-3yEgKX>dPCSUf(+p^+FK%bspgVos9_)mxQWd006lu007dL>HKYD|7=}n
zeAdouBZ*tpryn3ujhl5Sn&7?7^hT))+NyPxNw}Bip1Smipk!G>0YHMItIpqE32vxV
zM|0Nnoi=U(=HMWRq-2#1H0pKiKohbG3f)ER#YYPMAIy)jG8|EzjGPrJkCRb5;PRaJ
zLAU*5`kS#i%{1a!%e@N^{XKjYI_-`J(;J^}@dCPdvLfbO?!f~A^g(+A^hqX;
zSG!_oIxWsTn>pU{s6#unEAD;I(GKjlxQ~OXm~#3WW{aesTB3P-LrgIoHNi4GRW%of
zE1P|xI6WHmj2UZE9R%V>42N!ao~<76oeXCKnI2s~bVRnylHF18)l!uldH`P8z#($*
zl!9jro5W)i!YuT*Tqc-=BwZ0Y1O|}7Pkq`IMYXo}jDs-nbEdPT^hf-k7gkD@=0h^Y
zI%aTTiN0VmwWo~pKf$q-S1m4-dADDx)Kt%FtgFkbwyLdV6Rr~1|^n+vv`S236m!4uNu`aE|Rc4N6mYA#knI~{0-*10~5
zp8}jdp}$YHftH

[edk2] [PATCHV2] IntelFsp2Pkg: Converted PatchFvUserManual from .docx to .md format

[edk2] [PATCH] IntelFsp2Pkg: Converted GenCfgOptUserManual from .docx to .md format

Re: [edk2] Shell version 2.2

Re: [edk2] Shell version 2.2

Re: [edk2] [PATCH 2/2] MdeModulePkg/EbcDxe: cleanup

Re: [edk2] [PATCH 2/2] MdeModulePkg/EbcDxe: cleanup

Re: [edk2] Shell version 2.2

Re: [edk2] Shell version 2.2

Re: [edk2] Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]

Re: [edk2] Shell version 2.2

Re: [edk2] [PATCH 1/2] ArmVirtPkg/PrePi: use correct callee saved regs

Re: [edk2] Shell version 2.2

Re: [edk2] [PATCH] ShellPkg SmbiosView: Show "SocketDesignation" instead of "Socket" for Type 4

[edk2] [PATCH] ArmPkg: Fix double GIC EIOR write per interrupt

Re: [edk2] Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]

Re: [edk2] Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h]

[edk2] [PATCH] IntelFsp2Pkg: Converted PatchFvUserManual from .docx to .md format

[edk2] [PATCH 2/2] ArmPlatformPkg/PrePi: use correct callee saved regs

[edk2] [PATCH 1/2] ArmVirtPkg/PrePi: use correct callee saved regs

Re: [edk2] [PATCH] Platforms/ARM/Juno: limit ACPI support to v5.0 and higher

Re: [edk2] [PATCH] Platforms/ARM/Juno: Add support for ACPI 6.0 LPI(Low Power Idle) states

[edk2] [PATCH v2] BaseTools X64: fold PLT relocations into simple relative references

Re: [edk2] [PATCH 3/3] BaseTools GCC/ARM: add -fno-builtin to CC flags

Re: [edk2] [PATCH 3/3] BaseTools GCC/ARM: add -fno-builtin to CC flags

Re: [edk2] [PATCH 0/3] Build fixes for ARM/OpenSSL

[edk2] [PATCH] IntelFsp2Pkg: Converted PatchFvUserManual from .docx to .md format

26 matches

Site Navigation

Mail list logo

Footer information