[edk2-devel] [edk2-non-osi][PATCH 1/1] Platform/RaspberryPi: Update TF-A to v2.9 to fix rainbow screen on reboot

[Pete Batard via groups.io]

The newly released TF-A v2.9 contains a fix for an issue that has been
affecting some Raspberry Pi 3 users, when trying to issue a reboot with
some types of SD cards (See: pftf/RPi3#17, pftf/RPi3#24).

This fix is documented at:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20297

We also use this opportunity to update the TF-A binaries for RPi4.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md |   8 
 Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin   | Bin 18853 -> 18853 bytes
 Platform/RaspberryPi/RPi3/TrustedFirmware/fip.bin   | Bin 53988 -> 53988 bytes
 Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md |   6 +++---
 Platform/RaspberryPi/RPi4/TrustedFirmware/bl31.bin  | Bin 45163 -> 45163 bytes
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md 
b/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
index 4b8373493d55..23348e0dc98b 100644
--- a/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
+++ b/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
@@ -2,14 +2,14 @@ ARM Trusted Firmware for Raspberry Pi 3
 ===
 
 The `bl1.bin` and `fip.bin` TF-A binaries found in this directory were built 
from the
-[official TF-A 2.6 
release](https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.6)
+[official TF-A 2.9 
release](https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.9)
 through a [GitHub build 
script](https://github.com/pftf/pitf/blob/master/.github/workflows/build.yml)
 that is designed to provide evidence that these binaries match the vanilla 
TF-A source.
 
-Per the [GitHub Actions log](https://github.com/pftf/pitf/runs/1668471269),
+Per the [GitHub Actions 
log](https://github.com/pftf/pitf/actions/runs/5071490963),
 the SHA-256 sums for the blobs can be validated to be as follows:
-- `bl1.bin`: `787acb2ca1c99678dcdec70a64b9602f8f8f658a4abb0b3f7edfa5f5efb22f73`
-- `fip.bin`: `fd85f9a230aad88f6a59cf0c5d88e6067f23fb8080c6b8bdc61f1a5f6cbbf9ec`
+- `bl1.bin`: `de32a81d17a3a1251245dd6d9b0a807e6ec54d5b50eecfda31fc9cd2ffb1d5ba`
+- `fip.bin`: `7463cec7914469998d3cfab80b80710e371e8d5673959b303a7c851e37b179bb`
 
 For Raspberry Pi 3 usage, TF-A was built using the command:
 ```
diff --git a/Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin 
b/Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin
index 
cbbde5f744a7e2f50232a2e6c1a9de1d5254669c..e3076b1dc9898fcd6f6db694b2507a69fb371874
 100644
GIT binary patch
delta 5103
zcmZ`+3s6*7n*Ptd4K$$GbT24${hz}HkuY?OYK4y)H*x9ubQ#KM^U(q0HbRg5W
z(a8%<<$5q?j1^GFjNMZ+>w<2=mWc$dnM}D!DF%0w&6bU5RzotQsL`uv?{{u@qo!(`
zx}5X>=Rg1X&;LFLIXlQ%GR6A3TGBu4Crfts`BJ(211?{i~K^%%?I
zsp)l$Y8ss;GHE`HE_IaVB0BZ5_C*?7rCoBQegLZD3UymC{*tI^KE69HGt-pr
zdopR)7c##qYv$Qf6J5LcyyX9k$n7M0hfZ3wUz@1u8a}c8CzBwrEoxhRLE80X`54?cNWbcX9A_2<9+RO^=D(1AtQ$
z(y-qPX{hN27CVTFdN3M?zGu~P!62T<-Xo_3gwz+oC`xD0EVgNx#-aB7{o%v
zJk0CAY}${ZP@1u)#jYhqXtzPQ>kDU=`ES}3{a)RPL-i)I8$>_YwOiP5ukKSrE7ucA
zhxCCkgB0z)p-x-idZO6Zc}SP}CV4sY@c)rZ*{cO=t#9Ktt=FB
zcgRc53Ey>Yp4+};(a76mq6N;)@$Gl`v+;FPU?tayh|*(!->W<3-v-<^CCl&~
z;jll+Qb0Jd&?J%Cbt{wf-|(RcV~19oDEWw#)_4N^n)ojgp0@9UX?}tQmNDo@j>#9N
z^WPhC}=zliXJ{=xp7A1qR$=@>Z`(H4%EI>ZRw}_6=z)}1sZT8qJQ2g$N9Pr
zq_^}}L9iuM-_OX`#WFs`$Y3ftKo;K~Pb=w8%am@7_LZSvbgvxDvdV}5zorB#(5JzWWGekvb3wEuU8C7kUX%Vh{Ku
zcn{1X;;f>6SlN=x;u}1#onW_OmVD@IuQd?`gGjgm&>>Xg7yfd!%fw9AxUh
zSLh5XH4<%bgtimvU=xL_5bC!|JYtGWVC=3!v%R4f`p02tsXKK9;VMV%1Em_(tSbqx|
z6hR@ZZqUA*5vKKIYB!-x12-hH|8RzOHHrh>UCa$$xg)d}!As;#5hKirnAmKcm@yxB
ztb%_M9j+`TS}pw3*l?0}S|_j~-f#WKvcEu4!W@bWwIl8HR4^?BTnpd}V-;QC_A@%-
zOI6yJ5bGNwBT}r?-di0`ZUg*HnbI<Ra#mJ8bpkf#1Wti)RxXjSlnZAx?
zZL3$fP~=vX0zQQT$3-r(9PX;7m91ROSmeG7FS%ED((pD^?|=s)k|Jph>_Nz%5|+S5
zoZxmq(qLS31~XG~l$I@`c9ABwVUOqlctPeImc}<`PWGOZ$R3R$p*aylqRK=&5+v+=
zF1^|njwcG#CRLmb0=EgVcP_ShkBFsPh^4g6wmllJnJ`>oPk9>E8MX<+Qe;
zVb3|>mP?ZN)NN$wp!|5Cr-bxB=YF*(SW5cFd7~P?+e+;hU#Iq9+%tI
zUxsXcsYKBaNQ&+w*0@EAX>=hLJSMU>Q+nUyadhVMI5-`p_HD}M!>Fd5Y>hp_
z#IO(gUUzV-(tb3@i{4cp9w0~+#DPIDPM4`MI9<^lG`w%jK*){YI+FvPij6I3AC{
z;$W$QT14OPgHHD%d=xZk1mV?KI_jCAv{wUW;8`_++Npj6uO|9~6A|DsDXlFM=@)S6
zOLAI%Pl22fFez$fP|ghW(|73?zDx-q~P44P8N54pahnUb6M6JUM%W_pgRCH{*6I
zakxWfeP%u6Zn+yOs@}d~=OE*s@qGKvJ4Z6ZlFmL?4bfx_q*_s)8%gQFnNU+=ZuVb
z3D~v#g`CMTb8m-s2l%d>f06DpK5JzDsDlN}LWqNl`OMNxF?~VY*?IJm$l%&;F
z=nmA5ws%KPV!82qr*~i3O?n=yYmMKVX*|x%=+DgT)mC$IcDG0)-1*pIXER=H{aY3N
z>R%T4tyr)q+1-WsdSRXWb`bZk%9H}8?!DH~+X~BF*WNyjTAez1p
z!oeN&^9Pdi*cf&617gdV2gDxCA0pn>HZ}k6lF4=l1+HM6)07}4}hSk)Id9mUT
z_stX#p+B7H^wf%BS_=QoxRT<1+2qay6~lKFp+no*0>@&@c5@p;eYr9>9xkh77<
zajsVn?LLS4^}pOTe!}o>KtVa{R9ze`=#?|`FUaZnWlXKy!dH%8=XJB<6e!
zb=P0r>5_v6TEr?79K(y$4Q{F)f
zDzeDx`;dkOlwL^)GDZG?qxBWCWQ%WU%%`eOMzg)b$jT|eFp?fx4+?kn8D
z)hQA>>}H0rNjaV6FnO1Hju+f+ryZ=4%HD
zfOrbP{3t;wWWap9tiMBDjqmC+eR!@}_9(G!fxj9Fp$t0X8W
zyF7}XH;8_ey#D{eZy&

[edk2-devel] [edk2-non-osi][PATCH 1/1] Platform/RaspberryPi: Update TF-A to v2.6 to enable the PCI SMCCC interface

[Pete Batard]

The RPi4 has a single nonstandard PCI config region. It is broken into two
pieces, the root port config registers and a window to a single device's
config space which can move between devices. However there isn't (yet) an
authoritative public document on this since the available BCM2711 reference
notes that there is a PCIe root port in the memory map but doesn't describe
it.

Considering that it's not ECAM compliant, yet relatively simple, it is
however possible to make use of the newly introduced PCI SMCCC interface
that was added for the RPi4 platform as part of the TF-A 2.6 release.

As a result, we update the RPi4 TF-A to the 2.6 release version, and, for
good measure, the RPi3 also, using binaries that were built in an open and
verifiable manner through the GitHub Actions build script located at
https://github.com/pftf/pitf.

For more details on the SMCCC interface, see DEN0115 available from:
https://developer.arm.com/documentation/den0115/latest

Tested for regression on Pi 3 Model B and Pi 4 Model B.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md |   6 +++---
 Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin   | Bin 18853 -> 18853 bytes
 Platform/RaspberryPi/RPi3/TrustedFirmware/fip.bin   | Bin 53988 -> 53988 bytes
 Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md |   6 +++---
 Platform/RaspberryPi/RPi4/TrustedFirmware/bl31.bin  | Bin 41067 -> 45163 bytes
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md 
b/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
index cd88e0345c91..a136cfb9e413 100644
--- a/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
+++ b/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
@@ -2,14 +2,14 @@ ARM Trusted Firmware for Raspberry Pi 3
 ===
 
 The `bl1.bin` and `fip.bin` TF-A binaries found in this directory were built 
from the
-[official TF-A 2.5 
release](https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.5)
+[official TF-A 2.6 
release](https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.6)
 through a [GitHub build 
script](https://github.com/pftf/pitf/blob/master/.github/workflows/build.yml)
 that is designed to provide evidence that these binaries match the vanilla 
TF-A source.
 
 Per the [GitHub Actions log](https://github.com/pftf/pitf/runs/2822874196),
 the SHA-256 sums for the blobs can be validated to be as follows:
-- `bl1.bin`: `5ba701a7e977d308a19928e19937107387677d52a1a4d628a5c2bb4e795aae8b`
-- `fip.bin`: `0c3f8a3e8192e5dcb3bdc5867976e4277e9d948159a92ee71a54e92cb8dce9a3`
+- `bl1.bin`: `787acb2ca1c99678dcdec70a64b9602f8f8f658a4abb0b3f7edfa5f5efb22f73`
+- `fip.bin`: `fd85f9a230aad88f6a59cf0c5d88e6067f23fb8080c6b8bdc61f1a5f6cbbf9ec`
 
 For Raspberry Pi 3 usage, TF-A was built using the command:
 ```
diff --git a/Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin 
b/Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin
index 
edfb46702e801a102c9d18e4a52bb4ab9bd72a47..cbbde5f744a7e2f50232a2e6c1a9de1d5254669c
 100644
GIT binary patch
delta 3943
zcmZ`*4RBP|6+ZX9&1SQSu)o=`n`Czr0?C5;;U_{s@{>kf4xwfFQ@a8
zFCi+@R=C`qL8#MgR4`e!qzTr>sw`0%t*woVtDTIa3F7ErYcT=I6TL?p
z`MKXc_uO;OIrkl5gsVT?1GrjPT>Ej04F=p`XD?1FZhpx?k7yt;DFp(2+V>)O8bk<~XG(pRAkd2<
zgc5M-(#SO%1kjI)V#w9BVJr;rij1ZN&`?+^*Z6e7-?^Id$4(0{hi}T6(KK=~f?5u+ghp$tx-QmNca86S
zt8=FYEO|KgEqgB`zgdU78sB-MYg`2S3eFned9w2@k?Y>*asljze;Fws8?7Z>vr+c1
zHqnb_P`?p~K-XR`k4>iaC_fjA9efXM=HWYv;lOig9M(WxKFU@JD9&&8
zitNt}vVY^E3wbi(2}p;EKQkgyfJ-d5O5
z{~e3j)H!=BbZ!FMhR%)FS}`tWN#SuhgmF>F;!DSn;HL
z=vbLiwo{TJDVSx)iB^vMS;s0!iFLi5uB*1I@v&+oWk?h~lSTF@ai*>CDrepT>RZl^
zk{xNcdli1%u#`;`+V5{z*5^ZqeMC0#oZ5{ez6P&?XJmQ;`7b30bpm`hB(~b~Fxu5F
zpl3FV%6i#BpVa`z)$}){^}*HH+>H!_`4{z6`N;*)PN3D!N<{m0i`R%V
zgh4B77H=f=>}AnL?qctVb;hNl!V|Uf_BhRJU>=P<^I|FlxY~v8@+1Kbta3H5)tc#o
ziXwpY8ujx#RS3tjCQ(0IuK%F-05
zdmQ~bg$5m|4Sj7i_=Y*wp*;R6SuU)3eCy?7sA=8CjW_$W>Sd{hd?Tq4as=
zc@{~Z-YnTD2oSgr-zT*YaBbOjpjm)#WL#LyhyfcNL#KGz@tjYZII4};NwPlXXe8CO
z??n=FV~O*U4+un0mdcSXv}?xhF%)b$(5{6>zW{ry(7s=gde($ZQlDs8d|Cq6O@86w
zo_?*=R}F@8zwl6x|A$@b1Qo1p=y78|aL?4$R$?)Q(STbAt2n<0d2Tpv^q!t7T&&~w
zpfH1Bi%H$Z_AL4`!9Iq>-k;S4c^Wj``#`<2ru%YL84=66fyy!`-q;wnr
zoAV?{cC)T|w*E&+)752DsnsDq2`vYDO-RzX{Wir6Fo2E{B
z06Ve;B!!>Ji!>t95=q{Rd!v)!sd+x^Dv0=nJ<8HR9ixio1Hu4l$5_;Wp;g8
zNq6v+SJ`;|9F*1eWSFW;0^aa)3a(@neV?1_{*`V7e!+M*>0#P(buJ7Gw22>mu=JKG!NntahXWDRDjlqpb3r$
z?~2Nhb9;{q%bkaaw}~W%hcE>V9SKZR8#TP^Rq!7A(2Wh~$V{mRdHMp@$5(j29p!a`
zRD<|7q$1J{NYBJ#=c|$8+IIB@;AOa0xOSjJexNg0L0U;O;1tNprpN>YJWDsdDYgO9J
z@fMEhRog{eawJ)Bcprp#9L$hONmx)M46zG>Bm5`AcNMyLu{PVGuLzHV=OI9MO(nns
z*rMuG;~(YFJAm!Yn3k=Ii*xA(T*sFw^~nOL&1eK=_O_`|sE@I4O_|nb@zi;CNg`%Z
zKIWg7&_OoEJcE3~ZZSLcpWrypu9k7O)m%Xivo7=Qy!lxC@uUB%8VtV{=p5{)-=J~q
zblvU!-2~8}KSvy^1iv4qLpK=bu^j;diTbANhz~wK}YWUIj4a`SlA>`7yQ^PwOBn
z{z1wj^@_`INP0-iF@~GVjLkG@Bp4hi!M__neJus~mXKE`

Re: [edk2-devel] [PATCH] Maintainers.txt: Replace Pete with Jeremy as RPi reviewer

[Pete Batard]

Thanks Jeremy!

On 2021.12.17 17:52, Jeremy Linton wrote:

First a huge thank you to Pete Batard for all the hard work
landing the RPi code here, and keeping everyone in line.

But, he has lots of commitments, and its time to give him
a breather. As such, I will take over as a platform reviewer.

Cc: Pete Batard 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Andrei Warkentin 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
---
  Maintainers.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 2cad0a597d..a6ce4eee0f 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -346,7 +346,7 @@ F: Platform/RaspberryPi/
  F: Silicon/Broadcom/
  M: Ard Biesheuvel 
  M: Leif Lindholm 
-R: Pete Batard 
+R: Jeremy Linton 
  
  RPMB driver for OP-TEE

  F: Drivers/OpTee/OpteeRpmbPkg/


Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85083): https://edk2.groups.io/g/devel/message/85083
Mute This Topic: https://groups.io/mt/87792984/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi/RPi4: Add _DSM ACPI method for 32-bit MMIO xHCI access

[Pete Batard]

With the upcoming release of Windows 11, Microsoft has introduced a new USB
Device-Specific Method (_DSM) function to enforce 64-bit xHCI registers to
be accessed through two sequential 32-bit requests. The new function (Query
controller register access type - Function 6) is documented at:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/usb-device-specific-method---dsm-

Support for this feature is required on the raspberry Pi 4 where there is
a bug/limitation in the xHCI stack that prevents full range 64-bit access
from working correctly. It should be noted that an equivalent for this _DSM
is not required on Linux, as 64-bit xHCI register access is already broken
down into 2x32-bit by the drivers there.

With this _DSM, and unlike what is the case for Windows 10, Windows 11 can
now be installed on the Raspberry Pi 4 without having to alter any of the
installation files, as we were able to validate using the latest Windows 11
Build 22000 Insider image.

Signed-off-by: Pete Batard 
Tested-by: Pete Batard 
---
 Platform/RaspberryPi/AcpiTables/Xhci.asl | 21 
 1 file changed, 21 insertions(+)

diff --git a/Platform/RaspberryPi/AcpiTables/Xhci.asl 
b/Platform/RaspberryPi/AcpiTables/Xhci.asl
index 9b37277956d9..00b0cd29c69c 100644
--- a/Platform/RaspberryPi/AcpiTables/Xhci.asl
+++ b/Platform/RaspberryPi/AcpiTables/Xhci.asl
@@ -138,6 +138,27 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", 
"RPI4XHCI", 2)
 Debug = "xHCI enable"
 Store (0x6, CMND)
 }
+
+/*
+ * Microsoft's USB Device-Specific Methods. See:
+ * 
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/usb-device-specific-method---dsm-
+ */
+Name (DSMU, ToUUID ("ce2ee385-00e6-48cb-9f05-2edb927c4899"))
+
+Method (_DSM, 4, Serialized) {
+If (LEqual (Arg0, DSMU)) {  // USB capabilities UUID
+Switch (ToInteger (Arg2)) {
+Case (0) {  // Function 0: List of 
supported functions
+Return (Buffer () { 0x41 }) // 0x41 - Functions 0 and 
6 supported
+}
+Case (6) {  // Function 6: 
RegisterAccessType
+Return (Buffer () { 0x01 }) // 0x01 - Must use 32bit 
register access
+}
+Default { } // Unsupported
+}
+}
+return (Buffer () { 0x00 }) // Return 0x00 for 
anything unsupported
+}
   } // end XHC0
 } //end SCB0
   } //end scope sb
-- 
2.30.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#80106): https://edk2.groups.io/g/devel/message/80106
Mute This Topic: https://groups.io/mt/85307462/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH v5 1/2] Platform/RaspberryPi: Enable Boot Discovery Policy.

[Pete Batard]

*  Copyright (c) 2015-2016, Red Hat, Inc.
   *  Copyright (c) 2014-2021, ARM Ltd. All rights reserved.
   *  Copyright (c) 2004-2016, Intel Corporation. All rights reserved.
+ *  Copyright (c) 2021, Semihalf All rights reserved.
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
   *
@@ -19,10 +20,12 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -598,6 +601,89 @@ PlatformBootManagerBeforeConsole (
FilterAndProcess (, NULL, Connect);
  }

+/**
+  Connect device specified by BootDiscoverPolicy variable and refresh
+  Boot order for newly discovered boot device.
+
+  @retval  EFI_SUCCESS  Devices connected succesfully or connection
+not required.
+  @retval  others   Return values from GetVariable(), LocateProtocol()
+and ConnectDeviceClass().
+--*/
+STATIC
+EFI_STATUS
+BootDiscoveryPolicyHandler (
+  VOID
+  )
+{
+  EFI_STATUS   Status;
+  UINT32   DiscoveryPolicy;
+  UINTNSize;
+  EFI_BOOT_MANAGER_POLICY_PROTOCOL *BMPolicy;
+  EFI_GUID *Class;
+
+  Size = sizeof (DiscoveryPolicy);
+  Status = gRT->GetVariable (
+  BOOT_DISCOVERY_POLICY_VAR,
+  ,
+  NULL,
+  ,
+  
+  );
+  if (Status == EFI_NOT_FOUND) {
+Status = PcdSet32S (PcdBootDiscoveryPolicy, PcdGet32
(PcdBootDiscoveryPolicy));
+DiscoveryPolicy = PcdGet32 (PcdBootDiscoveryPolicy);
+if (Status == EFI_NOT_FOUND) {
+  return EFI_SUCCESS;
+} else if (EFI_ERROR (Status)) {
+  return Status;
+}
+  } else if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  if (DiscoveryPolicy == BDP_CONNECT_MINIMAL) {
+return EFI_SUCCESS;
+  }
+
+  switch (DiscoveryPolicy) {
+case BDP_CONNECT_NET:
+  Class = 
+  break;
+case BDP_CONNECT_ALL:
+  Class = 
+  break;
+default:
+  DEBUG ((
+DEBUG_INFO,
+"%a - Unexpected DiscoveryPolicy (0x%x). Run Minimal Discovery
Policy\n",
+__FUNCTION__,
+DiscoveryPolicy
+));
+  return EFI_SUCCESS;
+  }
+
+  Status = gBS->LocateProtocol (
+  ,
+  NULL,
+  (VOID **)
+  );
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a - Failed to locate
gEfiBootManagerPolicyProtocolGuid - %r\n", __FUNCTION__, Status));
+return Status;
+  }
+
+  Status = BMPolicy->ConnectDeviceClass (BMPolicy, Class);
+  if (EFI_ERROR (Status)){
+DEBUG ((DEBUG_ERROR, "%a - ConnectDeviceClass returns - %r\n",
__FUNCTION__, Status));
+return Status;
+  }
+
+  EfiBootManagerRefreshAllBootOption();
+
+  return EFI_SUCCESS;
+}
+
  /**
Do the platform specific action after the console is ready
Possible things that can be done in PlatformBootManagerAfterConsole:
@@ -644,6 +730,11 @@ PlatformBootManagerAfterConsole (
  DEBUG ((DEBUG_INFO, "Boot Policy is Fast Boot. Skip connecting all
devices\n"));
}

+  Status = BootDiscoveryPolicyHandler ();
+  if (EFI_ERROR(Status)) {
+DEBUG ((DEBUG_INFO, "Error applying Boot Discovery Policy:%r\n",
Status));
+  }
+
Status = gBS->LocateProtocol (, NULL,
(VOID**));
if (!EFI_ERROR (Status)) {
  EsrtManagement->SyncEsrtFmp ();
--
2.25.1


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


Reviewed-by: Pete Batard 
Tested-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78592): https://edk2.groups.io/g/devel/message/78592
Mute This Topic: https://groups.io/mt/84609667/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Fix SetTime issues

[Pete Batard]

Hi Sunny,

Good catch for both these issues. Thanks for fixing them.

With this:

On 2021.07.23 10:04, Sunny Wang wrote:

This patch fixes two issues below:
1. SCT SetTime_Func failures.
- https://github.com/pftf/RPi4/issues/164
2. Using shell time and date commands to set time can't work.

The problem is that gRT->SetTime always returns EFI_INVALID_PARAMETER
error status.

The root cause is that LibSetTime() sets RtcEpochSeconds variable with
inconsistent attributes. One is without EFI_VARIABLE_NON_VOLATILE,
the other one is with EFI_VARIABLE_NON_VOLATILE. That caused that the
variable driver returns EFI_INVALID_PARAMETER. Per UEFI spec, if a
preexisting variable is rewritten with different attributes,
SetVariable() shall not modify the variable and shall return
EFI_INVALID_PARAMETER.

Therefore, the solution is to add EFI_VARIABLE_NON_VOLATILE attribute
to the first EfiSetVariable() call to make two calls consistent.

By the way, this patch also fix a minor issue with a debug message.

Cc: Samer El-Haj-Mahmoud 
Cc: Sami Mujawar 
Cc: Jeremy Linton 
Cc: Ard Biesheuvel 
Cc: Pete Batard 
Cc: Leif Lindholm 

Signed-off-by: Sunny Wang 
---
  .../VirtualRealTimeClockLib/VirtualRealTimeClockLib.c   | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c 
b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
index de6fbb40e6..c10c91bc75 100644
--- a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
+++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
@@ -4,7 +4,7 @@
   *
   *  Coypright (c) 2019, Pete Batard 
   *  Copyright (c) 2018, Andrei Warkentin 
- *  Copyright (c) 2011-2014, ARM Ltd. All rights reserved.
+ *  Copyright (c) 2011-2021, ARM Ltd. All rights reserved.
   *  Copyright (c) 2008-2010, Apple Inc. All rights reserved.
   *  Copyright (c) Microsoft Corporation. All rights reserved.
   *
@@ -96,7 +96,7 @@ LibGetTime (
  EfiSetVariable (
(CHAR16 *)mEpochVariableName,
,
-  EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,
+  EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS,
sizeof (EpochSeconds),

);
@@ -324,7 +324,7 @@ LibSetTime (
  DEBUG ((
DEBUG_ERROR,
"LibSetTime: Failed to save %s variable to non-volatile storage, Status = 
%r\n",
-  mDaylightVariableName,
+  mEpochVariableName,
Status
));
  return Status;



Reviewed-by: Pete Batard 
Tested-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#78139): https://edk2.groups.io/g/devel/message/78139
Mute This Topic: https://groups.io/mt/84397263/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4] BaseTools GenFw: Add support for RISCV GOT/PLT relocations

[Pete Batard]

else {

+*(UINT32 *)Targ = (RV_X(Value, 0, 12) << 20) | (RV_X(*(UINT32*)Targ, 
0, 20));

+  }

*(UINT32 *)mRiscVPass1Targ = (RV_X(Value2, 0, 20)<<12) | (RV_X(*(UINT32 
*)mRiscVPass1Targ, 0, 12));

  }

  mRiscVPass1Sym = NULL;

  mRiscVPass1Targ = NULL;

  mRiscVPass1SymSecIndex = 0;

+mRiscVPass1Offset = 0;

+mRiscVPass1GotFixup = 0;

  break;

  


case R_RISCV_ADD64:

@@ -586,6 +630,7 @@ WriteSectionRiscV64 (
case R_RISCV_GPREL_I:

case R_RISCV_GPREL_S:

case R_RISCV_CALL:

+  case R_RISCV_CALL_PLT:

case R_RISCV_RVC_BRANCH:

case R_RISCV_RVC_JUMP:

case R_RISCV_RELAX:

@@ -1528,6 +1573,7 @@ WriteRelocations64 (
  case R_RISCV_GPREL_I:

  case R_RISCV_GPREL_S:

  case R_RISCV_CALL:

+case R_RISCV_CALL_PLT:

  case R_RISCV_RVC_BRANCH:

  case R_RISCV_RVC_JUMP:

  case R_RISCV_RELAX:

@@ -1537,6 +1583,7 @@ WriteRelocations64 (
  case R_RISCV_SET16:

  case R_RISCV_SET32:

  case R_RISCV_PCREL_HI20:

+case R_RISCV_GOT_HI20:

  case R_RISCV_PCREL_LO12_I:

break;

  



Tested-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77696): https://edk2.groups.io/g/devel/message/77696
Mute This Topic: https://groups.io/mt/83760258/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] BaseTools GenFw: Add support for R_RISCV_PCREL_LO12_S relocation

[Pete Batard]

Hi Sunil,

Thanks a lot for this patch.

I confirm that it fixes the issue I raised in BZ3459.

If anyone is interested, you can find builds of the RISC-V NTFS driver, 
where this patch has been applied, in the artefacts of 
https://github.com/pbatard/ntfs-3g/actions/runs/1022633741.


With this:

On 2021.07.10 07:31, Sunil V L wrote:

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3459

This patch adds support for R_RISCV_PCREL_LO12_S relocation type.
The logic is same as existing R_RISCV_PCREL_LO12_I relocation
except the difference between load vs store instruction formats.

Signed-off-by: Sunil V L 

Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Pete Batard 
Cc: Abner Chang 
Cc: Daniel Schaefer 
---
  BaseTools/Source/C/GenFw/Elf64Convert.c | 55 +
  1 file changed, 55 insertions(+)

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 3d7e20aaff..0bb3ead228 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -557,6 +557,60 @@ WriteSectionRiscV64 (
  Value = (UINT32)(RV_X(*(UINT32 *)mRiscVPass1Targ, 12, 20));

  break;

  


+  case R_RISCV_PCREL_LO12_S:

+if (mRiscVPass1Targ != NULL && mRiscVPass1Sym != NULL && 
mRiscVPass1SymSecIndex != 0) {

+  int i;

+  Value2 = (UINT32)(RV_X(*(UINT32 *)mRiscVPass1Targ, 12, 20));

+

+  Value = ((UINT32)(RV_X(*(UINT32 *)Targ, 25, 7)) << 5);

+  Value = (Value | (UINT32)(RV_X(*(UINT32 *)Targ, 7, 5)));

+

+  if(Value & (RISCV_IMM_REACH/2)) {

+Value |= ~(RISCV_IMM_REACH-1);

+  }

+  Value = Value - (UINT32)mRiscVPass1Sym->sh_addr + 
mCoffSectionsOffset[mRiscVPass1SymSecIndex];

+

+  if(-2048 > (INT32)Value) {

+i = (((INT32)Value * -1) / 4096);

+Value2 -= i;

+Value += 4096 * i;

+if(-2048 > (INT32)Value) {

+  Value2 -= 1;

+  Value += 4096;

+}

+  }

+  else if( 2047 < (INT32)Value) {

+i = (Value / 4096);

+Value2 += i;

+Value -= 4096 * i;

+if(2047 < (INT32)Value) {

+  Value2 += 1;

+  Value -= 4096;

+}

+  }

+

+  // Update the IMM of SD instruction

+  //

+  // |31  25|24  20|19  15|14   12 |11  7|6 0|

+  // |---|---|

+  // |imm[11:5] | rs2  | rs1  | funct3 |imm[4:0] | opcode|

+  //  ---

+

+  // First Zero out current IMM

+  *(UINT32 *)Targ &= ~0xfe000f80;

+

+  // Update with new IMM

+  *(UINT32 *)Targ |= (RV_X(Value, 5, 7) << 25);

+  *(UINT32 *)Targ |= (RV_X(Value, 0, 5) << 7);

+

+  // Update previous instruction

+  *(UINT32 *)mRiscVPass1Targ = (RV_X(Value2, 0, 20)<<12) | (RV_X(*(UINT32 
*)mRiscVPass1Targ, 0, 12));

+}

+mRiscVPass1Sym = NULL;

+mRiscVPass1Targ = NULL;

+mRiscVPass1SymSecIndex = 0;

+break;

+

case R_RISCV_PCREL_LO12_I:

  if (mRiscVPass1Targ != NULL && mRiscVPass1Sym != NULL && 
mRiscVPass1SymSecIndex != 0) {

int i;

@@ -1587,6 +1641,7 @@ WriteRelocations64 (
  case R_RISCV_PCREL_HI20:

  case R_RISCV_GOT_HI20:

  case R_RISCV_PCREL_LO12_I:

+case R_RISCV_PCREL_LO12_S:

break;

  


  default:



Tested-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77694): https://edk2.groups.io/g/devel/message/77694
Mute This Topic: https://groups.io/mt/84108362/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RESEND PATCH v2] BaseTools: Add support for RISCV GOT/PLT relocations

[Pete Batard]

I agree that this is unlikely to be a consequence of the current patch.

I logged new BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3459

Regards,

/Pete

On 2021.06.17 05:44, Sunil V L wrote:

Hi Pete,
Thank you very much!.
On Wed, Jun 16, 2021 at 01:35:27PM +0100, Pete Batard wrote:

Sunil, Daniel, thanks for the patch.

I confirm that this addresses the 0x13 and 0x14 relocation issues that I was
seeing.

However, this patch appears to introduces new R_RISCV_PCREL_LO12_S
relocation errors that I was not seeing previously, so I still can't manage
to get a successful compilation.


It is not introduced by the patch but looks like one more new relocation
type is added by the latest tool chain you are using. Please raise a new
bug and I will add the support for it in next patch.

Thanks!
Sunil


Especially the stream of 0x13 and 0x14 relocation errors I was getting at
https://github.com/pbatard/ntfs-3g/runs/2278190652?check_suite_focus=true
has now switched to (tested on up to date Ubuntu with latest EDK2):

-
"GenFw" -e UEFI_DRIVER -o 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/OUTPUT/ntfs.efi 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll
GenFw: ERROR 3000: Invalid
   WriteSections64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll
unsupported ELF EM_RISCV64 relocation 0x19.
GenFw: ERROR 3000: Invalid
   WriteSections64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll
unsupported ELF EM_RISCV64 relocation 0x19.
GenFw: ERROR 3000: Invalid
   WriteSections64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll
unsupported ELF EM_RISCV64 relocation 0x19.
GenFw: ERROR 3000: Invalid
   WriteRelocations64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll
unsupported ELF EM_RISCV64 relocation 0x19.
GenFw: ERROR 3000: Invalid
   WriteRelocations64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll
unsupported ELF EM_RISCV64 relocation 0x19.
GenFw: ERROR 3000: Invalid
   WriteRelocations64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll
unsupported ELF EM_RISCV64 relocation 0x19.
make: *** [GNUmakefile:553: 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/OUTPUT/ntfs.efi]
Error 2
-

So, in effect, some of the earlier relocation errors appear to have morphed
into 0x19/R_RISCV_PCREL_LO12_S ones...

I can open a new bug for this issue if you prefer.

Regards,

/Pete

On 2021.06.15 03:26, Daniel Schaefer wrote:

Great commit message, thanks Sunil!
Maintainers, please take a look and let us know if there's any other
concern.
This patch lets us build the RISC-V platforms using modern toolchains
that are provided directly by the distributions, rather than building
your own from source.

Thanks,
Daniel

*From:* Sunil V L 
*Sent:* Friday, June 11, 2021 22:08
*To:* devel@edk2.groups.io 
*Cc:* Chang, Abner (HPS SW/FW Technologist) ;
Schaefer, Daniel ; Bob Feng
; Liming Gao ; Yuwei
Chen ; Heinrich Schuchardt 
*Subject:* Re: [RESEND PATCH v2] BaseTools: Add support for RISCV
GOT/PLT relocations
Hi,
      I just edited the commit message to indicate the module and CC the
      maintainers. Could I get the feedback please?
Thanks
Sunil

On Fri, Jun 11, 2021 at 07:35:03PM +0530, Sunil V L wrote:

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3096

<https://bugzilla.tianocore.org/show_bug.cgi?id=3096>


This patch adds support for R_RISCV_CALL_PLT and R_RISCV_GOT_HI20
relocations generated by PIE enabled compiler. This also needed
changes to R_RISCV_32 and R_RISCV_64 relocations as explained in
https://github.com/riscv/riscv-gnu-toolchain/issues/905#issuecomment-846682710

<https://github.com/riscv/riscv-gnu-toolchain/issues/905#issuecomment-846682710>


Changes in v2:
    - Addressed Daniel's comment on formatting

Testing:
1) Debian GCC 8.3.0 and booted sifive_u and QMEU virt models.
2) Debian 10.2.0 and booted QEMU virt model.
3) riscv-gnu-tool chain 9.2 and booted QEMU virt model.

Signed-off-by: Sunil V L 

Acked-by: Abner Chang 
Reviewed-by: Daniel Schaefer 
Tested-by: 

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yuwei Chen 
Cc: Heinrich Schuchardt 
---
   BaseTools/Source/C/GenFw/Elf64Convert.c | 44 +
   1 file changed, 38 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
b/BaseTools/Source/C/GenFw/Elf64Convert.c
index d097db8632..d684318269 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -129,6 +129,8 @@ STATIC UINT32 mDebugOffset;
   STATIC UINT8   *mRiscVPass1

Re: [edk2-devel] [RESEND PATCH v2] BaseTools: Add support for RISCV GOT/PLT relocations

[Pete Batard]

Sunil, Daniel, thanks for the patch.

I confirm that this addresses the 0x13 and 0x14 relocation issues that I 
was seeing.


However, this patch appears to introduces new R_RISCV_PCREL_LO12_S 
relocation errors that I was not seeing previously, so I still can't 
manage to get a successful compilation.


Especially the stream of 0x13 and 0x14 relocation errors I was getting 
at 
https://github.com/pbatard/ntfs-3g/runs/2278190652?check_suite_focus=true has 
now switched to (tested on up to date Ubuntu with latest EDK2):


-
"GenFw" -e UEFI_DRIVER -o 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/OUTPUT/ntfs.efi 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll

GenFw: ERROR 3000: Invalid
  WriteSections64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll 
unsupported ELF EM_RISCV64 relocation 0x19.

GenFw: ERROR 3000: Invalid
  WriteSections64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll 
unsupported ELF EM_RISCV64 relocation 0x19.

GenFw: ERROR 3000: Invalid
  WriteSections64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll 
unsupported ELF EM_RISCV64 relocation 0x19.

GenFw: ERROR 3000: Invalid
  WriteRelocations64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll 
unsupported ELF EM_RISCV64 relocation 0x19.

GenFw: ERROR 3000: Invalid
  WriteRelocations64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll 
unsupported ELF EM_RISCV64 relocation 0x19.

GenFw: ERROR 3000: Invalid
  WriteRelocations64(): 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/DEBUG/ntfs.dll 
unsupported ELF EM_RISCV64 relocation 0x19.
make: *** [GNUmakefile:553: 
/usr/src/ntfs-3g/Build/RELEASE_GCC5/RISCV64/uefi-driver/uefi_driver/OUTPUT/ntfs.efi] 
Error 2

-

So, in effect, some of the earlier relocation errors appear to have 
morphed into 0x19/R_RISCV_PCREL_LO12_S ones...


I can open a new bug for this issue if you prefer.

Regards,

/Pete

On 2021.06.15 03:26, Daniel Schaefer wrote:

Great commit message, thanks Sunil!
Maintainers, please take a look and let us know if there's any other 
concern.
This patch lets us build the RISC-V platforms using modern toolchains 
that are provided directly by the distributions, rather than building 
your own from source.


Thanks,
Daniel

*From:* Sunil V L 
*Sent:* Friday, June 11, 2021 22:08
*To:* devel@edk2.groups.io 
*Cc:* Chang, Abner (HPS SW/FW Technologist) ; 
Schaefer, Daniel ; Bob Feng 
; Liming Gao ; Yuwei 
Chen ; Heinrich Schuchardt 
*Subject:* Re: [RESEND PATCH v2] BaseTools: Add support for RISCV 
GOT/PLT relocations

Hi,
     I just edited the commit message to indicate the module and CC the
     maintainers. Could I get the feedback please?
Thanks
Sunil

On Fri, Jun 11, 2021 at 07:35:03PM +0530, Sunil V L wrote:
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3096 




This patch adds support for R_RISCV_CALL_PLT and R_RISCV_GOT_HI20
relocations generated by PIE enabled compiler. This also needed
changes to R_RISCV_32 and R_RISCV_64 relocations as explained in
https://github.com/riscv/riscv-gnu-toolchain/issues/905#issuecomment-846682710 




Changes in v2:
   - Addressed Daniel's comment on formatting

Testing:
1) Debian GCC 8.3.0 and booted sifive_u and QMEU virt models.
2) Debian 10.2.0 and booted QEMU virt model.
3) riscv-gnu-tool chain 9.2 and booted QEMU virt model.

Signed-off-by: Sunil V L 

Acked-by: Abner Chang 
Reviewed-by: Daniel Schaefer 
Tested-by: 

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yuwei Chen 
Cc: Heinrich Schuchardt 
---
  BaseTools/Source/C/GenFw/Elf64Convert.c | 44 +
  1 file changed, 38 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c 
b/BaseTools/Source/C/GenFw/Elf64Convert.c
index d097db8632..d684318269 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -129,6 +129,8 @@ STATIC UINT32 mDebugOffset;
  STATIC UINT8   *mRiscVPass1Targ = NULL;
  STATIC Elf_Shdr    *mRiscVPass1Sym = NULL;
  STATIC Elf64_Half  mRiscVPass1SymSecIndex = 0;
+STATIC INT32   mRiscVPass1Offset;
+STATIC INT32   mRiscVPass1GotFixup;
 
  //

  // Initialization Function
@@ -479,11 +481,11 @@ WriteSectionRiscV64 (
  break;
 
    case R_RISCV_32:

-    *(UINT32 *)Targ = (UINT32)((UINT64)(*(UINT32 *)Targ) - SymShdr->sh_addr + 
mCoffSectionsOffset[Sym->st_shndx]);
+    *(UINT64 *)Targ = Sym->st_value + Rel->r_addend;
  break;
 
    case R_RISCV_64:

-    

[edk2-devel] [edk2-non-osi][PATCH 1/1] Platform/RaspberryPi: Update TF-A to v2.5

[Pete Batard]

This is a run-of-the-mill update of the TF-A binaries used by the
Raspberry Pi 3 and Raspberry Pi 4 platforms, based on the recently
released TF-A 2.5.

These binaries were built in an open and verifiable manner through
a GitHub Actions build script (https://github.com/pftf/pitf).

It should be noted that we are only updating the binaries due to the
existing ones getting a bit old, in case some of the ARM erratas and
changes, that have been included in the past two TF-A releases, may
benefit us. However, unless there are changes of direct interest for
the Pi platform, we are not planning to update these binaries for
each TF-A release.

Tested for regression on Pi 3 Model B and Pi 4 Model B.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md |  10 +-
 Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin   | Bin 18837 -> 18853 bytes
 Platform/RaspberryPi/RPi3/TrustedFirmware/fip.bin   | Bin 53972 -> 53988 bytes
 Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md |   8 
 Platform/RaspberryPi/RPi4/TrustedFirmware/bl31.bin  | Bin 41067 -> 41067 bytes
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md 
b/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
index aafbbe9728f5..cd88e0345c91 100644
--- a/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
+++ b/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
@@ -2,14 +2,14 @@ ARM Trusted Firmware for Raspberry Pi 3
 ===
 
 The `bl1.bin` and `fip.bin` TF-A binaries found in this directory were built 
from the
-[official TF-A 2.3 
release](https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.3)
-through an [AppVeyor build 
script](https://github.com/pbatard/pitf/blob/master/appveyor.yml)
+[official TF-A 2.5 
release](https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.5)
+through a [GitHub build 
script](https://github.com/pftf/pitf/blob/master/.github/workflows/build.yml)
 that is designed to provide evidence that these binaries match the vanilla 
TF-A source.
 
-As per the [AppVeyor build 
log](https://ci.appveyor.com/project/pbatard/pitf/builds/32330098),
+Per the [GitHub Actions log](https://github.com/pftf/pitf/runs/2822874196),
 the SHA-256 sums for the blobs can be validated to be as follows:
-- `bl1.bin`: `28d70adc6e7041582264874d342bcad992adb8d34c9de5813e661029d0189b3b`
-- `fip.bin`: `02a8c3ea9227fbe60ecfc20999db6bb755d0b32fd757a596353e068e1814e171`
+- `bl1.bin`: `5ba701a7e977d308a19928e19937107387677d52a1a4d628a5c2bb4e795aae8b`
+- `fip.bin`: `0c3f8a3e8192e5dcb3bdc5867976e4277e9d948159a92ee71a54e92cb8dce9a3`
 
 For Raspberry Pi 3 usage, TF-A was built using the command:
 ```
diff --git a/Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin 
b/Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin
index 
cd3038990a7c9e45d18cde6198d087281b4b4490..edfb46702e801a102c9d18e4a52bb4ab9bd72a47
 100644
GIT binary patch
delta 8026
zcmZ`;4OCR;nSSrR0}Mh8%rN}x%m7B67(oR^n}!P*qe(VVoU9~i%kX1k)MG**##Yi9
z(9|@z*2_m?5B7x7)W(_ab`455?51_lB>mB|8!@=2-976dnm^L6fyDqhP8g+VzN?t+x
za3Xc?)wGPP@1f(*pvy$09YE_ui|err@1J@Nfcui4)7l8dfu~g3ShV82U6!1HwNggrYg7FluPgevcw!d%i%CJL<
zH8>1@FDU83Z^ifmTlhwWhGU-H8l24|-KSv@Nd~R+pDir)7I0>y@)#m}L9?56H
z`Mu|MVA4}vspkQ37y6fc*_xf`N?2*jQ+DKie4AW)()D8;i^uoPV6HPZKziC
zSw#9@Kwx6~zXc`~(#FFMpC7)WIXui;jKEh#UVf~em_#e|VCd{r8tKxEIjX_vxpwE(JL)y`%2GU7x
zCsNw?;$TOi{x`$|!(99Rm*G{XBj@7(u8HLw`_oY>bA+cz!BlL*H-5+)fH3Gw%U
z_4)CI-s)9-HP!j!#7C-z{=pqf$vCciRiE8VjfaWcSWk7hqw9P+HniJ-8-@WgM?>JG
zo>cuZxF^|uPDZ~XSJms_=*qbBvq!N?3C`qOR_}jLmm0PHcZ~%HW`9!>~+Xl10;<
zOpP~kNM9L8ZnpXleK{KY9y0;t10QVjj9-9l98%~Q7}o45bfq>DamyeKv0K))w48k%
z`+DVEZ6^+NOwLGcZ@{TPuFe~O5W4ZmsxBH53Pe#-+QK;O`V2=5D`~+uBawaA(O-{a
zUq!3n2z=anGq-$1KDPMxgml-PCstu|d}0$ock-8_>J0|CiNWK|i}POs=CBgy8cX8n
zb;5`UOqrEn#2A_(YRogdR}d`?C!-mfOl3}#~c@c^87
z@1f3nG%mMbjAsDIW$l0L0@|tk@{1Z?a$GEh_(RmJJIH&#

Re: [edk2-devel] [PATCH v4 3/3] Platform/RaspberryPi: Enable Bluetooth and UART in Windows OS

[Pete Batard]

On 2021.06.07 08:53, Sunny Wang wrote:

This change is based on edk2-platforms-raspberrypi-pl011-bth-noflow.diff
in https://github.com/worproject/RPi-Bluetooth-Testing/ with the
modifications and additional changes below for enabling Bluetooth
and serial port (Mini UART) in Windows IOT.
   - Remove RPIQ connection for BT_ON/OFF in Uart.asl because it is
 useless. The firmware already turns on the Bluetooth by default.
   - Move the GPIO pin muxing stuff from Uart.asl to ConfigDxe driver.

Testing Done:
   - Successfully booted Windows Windows 10 IOT (20279.1) on SD (made by
 WOR) with the RPi-Windows-Drivers release ver 0.5 downloaded from
 https://github.com/worproject/RPi-Windows-Drivers/releases
 and checked that both Bluetooth and serial port (Mini UART) can
 work fine.
   - Successfully booted VMware ESXi-Arm Fling v1.3 with only serial
 console connection (PL011 UART).

Cc: Samer El-Haj-Mahmoud 
Cc: Sami Mujawar 
Cc: Jeremy Linton 
Cc: Pete Batard 
Cc: Ard Biesheuvel 
Cc: Mario Bălănică 
Signed-off-by: Sunny Wang 
---
  Platform/RaspberryPi/AcpiTables/Uart.asl  | 16 --
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 22 +++
  2 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Uart.asl 
b/Platform/RaspberryPi/AcpiTables/Uart.asl
index bac9d791eb..167f94e889 100644
--- a/Platform/RaspberryPi/AcpiTables/Uart.asl
+++ b/Platform/RaspberryPi/AcpiTables/Uart.asl
@@ -71,14 +71,6 @@ Device (URTM)
  MEMORY32FIXED (ReadWrite, 0, BCM2836_MINI_UART_LENGTH, RMEM)
  Interrupt(ResourceConsumer, Level, ActiveHigh, Shared) { 
BCM2836_MINI_UART_INTERRUPT }
  
-// NTRAID#MSFT-7141401-2016/04/7-jordanrh - disable UART muxing

-// until a proper solution can be created for the dmap conflict.
-// When muxing is enabled, must consider DBG2 table conflict.
-// The alternate function resource needs to be reserved when
-// the kernel debugger is enabled to prevent another client
-// from muxing the pins away.
-
-// PinFunction (Exclusive, PullDown, BCM_ALT5, "\\_SB.GPI0", 0, 
ResourceConsumer, , ) { 14, 15 }
})
Method (_CRS, 0x0, Serialized)
{
@@ -143,10 +135,6 @@ Device(BTH0)
UAR0,  // DescriptorName: creates name
  //   for offset of resource descriptor
  )// Vendor data
-//
-// RPIQ connection for BT_ON/OFF
-//
-GpioIO (Shared, PullUp, 0, 0, IoRestrictionNone, "\\_SB.GDV0.RPIQ", 0, 
ResourceConsumer, , ) { 128 }
})
  
//

@@ -190,10 +178,6 @@ Device(BTH0)
UARM,  // DescriptorName: creates name
  //   for offset of resource descriptor
  )// Vendor data
-//
-// RPIQ connection for BT_ON/OFF
-//
-GpioIO (Shared, PullUp, 0, 0, IoRestrictionNone, "\\_SB.GDV0.RPIQ", 0, 
ResourceConsumer, , ) { 128 }
})
  
Method (_CRS, 0x0, Serialized)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index d6efb59793..cf9880bd20 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -618,6 +618,28 @@ ApplyVariables (
  DEBUG ((DEBUG_INFO, "Fan enabled on GPIO %d\n", FanOnGpio));
  GpioPinFuncSet (FanOnGpio, GPIO_FSEL_OUTPUT);
}
+
+  //
+  // Fake the CTS signal as we don't support HW flow control yet.
+  // Pin 31 must be held LOW so that we can talk to the BT chip
+  // without flow control
+  //
+  GpioPinFuncSet (31, GPIO_FSEL_OUTPUT);
+  GpioPinConfigure (31, CLEAR_GPIO);
+
+  //
+  // Bluetooth pin muxing
+  //
+  if ((PcdGet32 (PcdUartInUse) == PL011_UART_IN_USE)) {
+DEBUG ((DEBUG_INFO, "Enable Bluetooth over MiniUART\n"));
+GpioPinFuncSet (32, GPIO_FSEL_ALT5);
+GpioPinFuncSet (33, GPIO_FSEL_ALT5);
+  } else {
+DEBUG ((DEBUG_INFO, "Enable Bluetooth over PL011 UART\n"));
+GpioPinFuncSet (32, GPIO_FSEL_ALT3);
+GpioPinFuncSet (33, GPIO_FSEL_ALT3);
+  }
+
  }
  
  



Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76433): https://edk2.groups.io/g/devel/message/76433
Mute This Topic: https://groups.io/mt/83365133/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 2/3] Silicon/Broadcom/Bcm283x: Clean up GpioPinSet function

[Pete Batard]

On 2021.06.07 08:53, Sunny Wang wrote:

Make the changes below for making it clearer.
 - Rename GpioPinSet() to GpioPinConfigure()
 - Rename parameter Val to Config and change its type to BOOLEAN

Cc: Samer El-Haj-Mahmoud 
Cc: Sami Mujawar 
Cc: Jeremy Linton 
Cc: Pete Batard 
Cc: Ard Biesheuvel 
Cc: Mario Bălănică 
Signed-off-by: Sunny Wang 
---
  Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h | 10 +++---
  Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c |  9 +
  2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h 
b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
index 75c2c8be51..1f7d2204e0 100644
--- a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
+++ b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
@@ -3,6 +3,7 @@
   *  GPIO manipulation.
   *
   *  Copyright (c) 2018, Andrei Warkentin 
+ *  Copyright (c) 2021, ARM Limited. All rights reserved.
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
   *
@@ -13,6 +14,9 @@
  
  #include 
  
+#define CLEAR_GPIO0

+#define SET_GPIO  1
+
  VOID
  GpioPinFuncSet (
IN  UINTN Pin,
@@ -25,9 +29,9 @@ GpioPinFuncGet (
);
  
  VOID

-GpioPinSet (
-  IN  UINTN Pin,
-  IN  UINTN Val
+GpioPinConfigure (
+  IN  UINTN   Pin,
+  IN  BOOLEAN Config
);
  
  UINTN

diff --git a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c 
b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
index a4b4af59eb..eaf53e5369 100644
--- a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
+++ b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
@@ -4,6 +4,7 @@
   *
   *  Copyright (c) 2020, Pete Batard 
   *  Copyright (c) 2018, Andrei Warkentin 
+ *  Copyright (c) 2021, ARM Limited. All rights reserved.
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
   *
@@ -85,9 +86,9 @@ GpioPinFuncGet (
  }
  
  VOID

-GpioPinSet (
-  IN  UINTN Pin,
-  IN  UINTN Val
+GpioPinConfigure (
+  IN  UINTN   Pin,
+  IN  BOOLEAN Config
)
  {
EFI_PHYSICAL_ADDRESS Reg;
@@ -102,7 +103,7 @@ GpioPinSet (
//
// Different base addresses are used for clear and set
//
-  Reg = (Val == 0) ? GPIO_GPCLR0 : GPIO_GPSET0;
+  Reg = (Config == CLEAR_GPIO) ? GPIO_GPCLR0 : GPIO_GPSET0;
Reg += RegIndex * sizeof (UINT32);
MmioWrite32 (Reg, 1 << SelIndex);
  }



Reviewed-by: Pete Batard 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#76432): https://edk2.groups.io/g/devel/message/76432
Mute This Topic: https://groups.io/mt/83365132/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 1/3] Platform/RaspberryPi: Dynamically build UARTs info in ACPI

[Pete Batard]

No more comments on this series for me.

I have also tested this patch using Putty (serial) on Windows ARM64, to 
validate that COM1: was set to the serial output defined in config.txt, 
be it miniUART or PL011.


The only thing I saw was that the baudrate for PL011 was double the one 
set in Putty, but this is an issue with the Windows drivers using 
hardcoded clocks 
(https://github.com/raspberrypi/windows-drivers/issues/33) and unrelated 
to these changes.


With this:

On 2021.06.07 08:53, Sunny Wang wrote:

Changes:
   1. Add code to ConfigDxe driver and AcpiTables module to dynamically
  build either Mini UART or PL011 UART info in ACPI. This also fixes
  the issue discussed in https://github.com/pftf/RPi4/issues/118.
   2. Cleanup by moving duplicate Debug Port 2 table related defines and
  structures to a newly created header file (RpiDebugPort2Table.h).

Testing Done:
   - Booted to UEFI shell and use acpiview command to check the result of
 the different UART settings in config.txt (enabling either Mini UART
 or PL011) and SPCR, DBG2 tables and device BTH0 are dynamically
 changed as expected.

Cc: Samer El-Haj-Mahmoud 
Cc: Sami Mujawar 
Cc: Jeremy Linton 
Cc: Pete Batard 
Cc: Ard Biesheuvel 
Cc: Mario Bălănică 
Signed-off-by: Sunny Wang 
---
  .../RaspberryPi/AcpiTables/AcpiTables.inf |   8 +-
  .../RaspberryPi/AcpiTables/Dbg2MiniUart.aslc  |  81 +
  .../AcpiTables/{Dbg2.aslc => Dbg2Pl011.aslc}  |  30 +---
  .../RaspberryPi/AcpiTables/SpcrMiniUart.aslc  |  91 ++
  .../AcpiTables/{Spcr.aslc => SpcrPl011.aslc}  |  10 +-
  Platform/RaspberryPi/AcpiTables/Uart.asl  | 155 +-
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  48 +-
  .../Drivers/ConfigDxe/ConfigDxe.inf   |   1 +
  .../IndustryStandard/RpiDebugPort2Table.h |  33 
  Platform/RaspberryPi/Include/UartSelection.h  |  20 +++
  Platform/RaspberryPi/RPi3/RPi3.dsc|   8 +
  Platform/RaspberryPi/RPi4/RPi4.dsc|   8 +
  Platform/RaspberryPi/RaspberryPi.dec  |   1 +
  13 files changed, 410 insertions(+), 84 deletions(-)
  create mode 100644 Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc
  rename Platform/RaspberryPi/AcpiTables/{Dbg2.aslc => Dbg2Pl011.aslc} (72%)
  create mode 100644 Platform/RaspberryPi/AcpiTables/SpcrMiniUart.aslc
  rename Platform/RaspberryPi/AcpiTables/{Spcr.aslc => SpcrPl011.aslc} (87%)
  create mode 100644 
Platform/RaspberryPi/Include/IndustryStandard/RpiDebugPort2Table.h
  create mode 100644 Platform/RaspberryPi/Include/UartSelection.h

diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
index d3363a76a1..1ddc9ca5fe 100644
--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
@@ -2,7 +2,7 @@
  #
  #  ACPI table data and ASL sources required to boot the platform.
  #
-#  Copyright (c) 2019, ARM Limited. All rights reserved.
+#  Copyright (c) 2019-2021, ARM Limited. All rights reserved.
  #  Copyright (c) 2017, Andrey Warkentin 
  #  Copyright (c) Microsoft Corporation. All rights reserved.
  #
@@ -28,12 +28,14 @@
Emmc.asl
Madt.aslc
Fadt.aslc
-  Dbg2.aslc
+  Dbg2MiniUart.aslc
+  Dbg2Pl011.aslc
Gtdt.aslc
Iort.aslc
Dsdt.asl
Csrt.aslc
-  Spcr.aslc
+  SpcrMiniUart.aslc
+  SpcrPl011.aslc
Pptt.aslc
SsdtThermal.asl
  
diff --git a/Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc b/Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc

new file mode 100644
index 00..be7d96c179
--- /dev/null
+++ b/Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc
@@ -0,0 +1,81 @@
+/** @file
+ *
+ *  Debug Port Table (DBG2)
+ *
+ *  Copyright (c) 2019, Pete Batard 
+ *  Copyright (c) 2012-2021, ARM Limited. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "AcpiTables.h"
+
+#pragma pack(1)
+
+#define RPI_UART_INTERFACE_TYPE 
EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_BCM2835_UART
+#define RPI_UART_BASE_ADDRESS   
BCM2836_MINI_UART_BASE_ADDRESS
+#define RPI_UART_LENGTH 
BCM2836_MINI_UART_LENGTH
+//
+// RPI_UART_STR should match the value used Uart.asl
+//
+#define RPI_UART_STR{ '\\', '_', 'S', 'B', 
'.', 'G', 'D', 'V', '0', '.', 'U', 'R', 'T', 'M', 0x00 }
+
+#define DBG2_DEBUG_PORT_DDI(NumReg, SubType, UartBase, UartAddrLen, 
UartNameStr) {\
+{  
   \
+  EFI_ACPI_DBG2_DEBUG_DEVICE_INFORMATION_STRUCT_REVISION, /* UINT8 
Revision */\
+  sizeof (DBG2_DEBUG_DEVICE_INFORMATION), /* 
UINT16Length */   

Re: [edk2-devel] [edk2-platforms PATCH v2] Platform/RaspberryPi: Enable default Secure Boot variables initialization

[Pete Batard]

This whole patch series looks fine to me.

I have tested it on Raspberry Pi 4, and I have some changes lined up to 
ensure that the next Pi 4 firmware we produce, after this series has 
been integrated, can use the new feature.


For the record, since we are using an automated build system (and the Pi 
4 can't exactly be considered as a secure platform anyway), my plan is 
to discard the PK's private key and include only MS KEK and DBs for the 
time being.


Basically, it should go something like this:

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=Raspberry Pi Platform 
Key/" -keyout /dev/null -outform DER -out keys/pk.cer -days 7300 -nodes 
-sha256

curl -L https://go.microsoft.com/fwlink/?LinkId=321185 -o keys/ms_kek.cer
curl -L https://go.microsoft.com/fwlink/?linkid=321192 -o keys/ms_db1.crt
curl -L https://go.microsoft.com/fwlink/?linkid=321194 -o keys/ms_db2.crt
curl -L 
https://uefi.org/sites/default/files/resources/dbxupdate_arm64.bin -o 
keys/arm64_dbx.bin


and then use the files above for the DEFAULT_FILE vars.

With this, I was able to get the default keys installed using the new 
Secure Boot menu, and validated that something like the Windows 
bootloader would load properly, whereas an unsigned bootloader such as 
the GRUB one wouldn't.


Please find my formal R-b for this patch below:

On 2021.06.01 14:12, Grzegorz Bernacki wrote:

This commit allows to initialize Secure Boot default key
and databases from data embedded in firmware binary.

Signed-off-by: Grzegorz Bernacki 
---
  Platform/RaspberryPi/RPi4/RPi4.dsc | 5 -
  Platform/RaspberryPi/RPi4/RPi4.fdf | 2 ++
  2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index d8c6fdd4bd..1fb4df0b81 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -164,7 +164,7 @@
  !if $(SECURE_BOOT_ENABLE) == TRUE

TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
-
+  
SecureBootVariableLib|SecurityPkg/Library/SecureBootVariableLib/SecureBootVariableLib.inf
# re-use the UserPhysicalPresent() dummy implementation from the ovmf tree
PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
  !else
@@ -217,6 +217,7 @@

MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
  
  [LibraryClasses.common.UEFI_DRIVER]

@@ -612,6 +613,8 @@

NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
}

SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+  SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.inf
+  
SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.inf
  !else
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
  !endif
diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf 
b/Platform/RaspberryPi/RPi4/RPi4.fdf
index 1e13909a57..0e43d24c7a 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.fdf
+++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
@@ -189,7 +189,9 @@ READ_LOCK_STATUS   = TRUE
INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
  !if $(SECURE_BOOT_ENABLE) == TRUE
+!include SecurityPkg/SecureBootDefaultKeys.fdf.inc
INF 
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
+  INF 
SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.inf
  !endif
INF 
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf



Reviewed-by: Pete Batard 
Tested-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75993): https://edk2.groups.io/g/devel/message/75993
Mute This Topic: https://groups.io/mt/83232294/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 6/6] SecurityPkg: Add option to reset secure boot keys.

[Pete Batard]

r\n",
+  Status));
+return Status;
+  }
+
+  if (SetupMode == USER_MODE) {
+DEBUG((DEBUG_INFO, "Skipped - USER_MODE\n"));
+return EFI_SUCCESS;
+  }
+
+  Status = SetSecureBootMode (CUSTOM_SECURE_BOOT_MODE);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Cannot set CUSTOM_SECURE_BOOT_MODE: %r\n",
+  Status));
+return EFI_SUCCESS;
+  }
+
+  // Enroll all the keys from default variables
+  Status = EnrollDbFromDefault ();
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Cannot enroll db: %r\n", Status));
+goto error;
+  }
+
+  Status = EnrollDbxFromDefault ();
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Cannot enroll dbx: %r\n", Status));
+  }
+
+  Status = EnrollDbtFromDefault ();
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Cannot enroll dbt: %r\n", Status));
+  }
+
+  Status = EnrollKEKFromDefault ();
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Cannot enroll KEK: %r\n", Status));
+goto cleardbs;
+  }
+
+  Status = EnrollPKFromDefault ();
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Cannot enroll PK: %r\n", Status));
+goto clearKEK;
+  }
+
+  Status = SetSecureBootMode (STANDARD_SECURE_BOOT_MODE);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Cannot set CustomMode to STANDARD_SECURE_BOOT_MODE\n"
+  "Please do it manually, otherwise system can be easily compromised\n"));
+  }
+
+  return Status;
+
+clearKEK:
+  DeleteKEK ();
+
+cleardbs:
+  DeleteDbt ();
+  DeleteDbx ();
+  DeleteDb ();
+
+error:
+  if (SetSecureBootMode (STANDARD_SECURE_BOOT_MODE) != EFI_SUCCESS) {
+DEBUG ((DEBUG_ERROR, "Cannot set mode to Secure: %r\n", Status));
+  }
+  return Status;
+}
+
  /**
This function is called to provide results data to the driver.
  
@@ -4205,6 +4332,8 @@ SecureBootCallback (

SECUREBOOT_CONFIG_PRIVATE_DATA  *PrivateData;
BOOLEAN GetBrowserDataResult;
ENROLL_KEY_ERROREnrollKeyErrorCode;
+  EFI_HII_POPUP_PROTOCOL  *HiiPopup;
+  EFI_HII_POPUP_SELECTION UserSelection;
  
Status = EFI_SUCCESS;

SecureBootEnable   = NULL;
@@ -4755,6 +4884,31 @@ SecureBootCallback (
  FreePool (SetupMode);
}
break;
+case KEY_SECURE_BOOT_RESET_TO_DEFAULT:
+{
+  Status = gBS->LocateProtocol (, NULL, (VOID **) 
);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+  Status = HiiPopup->CreatePopup (
+   HiiPopup,
+   EfiHiiPopupStyleInfo,
+   EfiHiiPopupTypeYesNo,
+   Private->HiiHandle,
+   STRING_TOKEN (STR_RESET_TO_DEFAULTS_POPUP),
+   
+   );
+  if (UserSelection == EfiHiiPopupSelectionYes) {
+Status = KeyEnrollReset ();
+  }
+  //
+  // Update secure boot strings after key reset
+  //
+  if (Status == EFI_SUCCESS) {
+Status = UpdateSecureBootString (Private);
+SecureBootExtractConfigFromVariable (Private, IfrNvData);
+  }
+}
  default:
break;
  }
diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigStrings.uni
 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigStrings.uni
index ac783453cc..0d01701de7 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigStrings.uni
+++ 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigStrings.uni
@@ -21,6 +21,10 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
  #string STR_SECURE_BOOT_PROMPT #language en-US "Attempt Secure 
Boot"
  #string STR_SECURE_BOOT_HELP   #language en-US "Enable/Disable the 
Secure Boot feature after platform reset"
  
+#string STR_SECURE_RESET_TO_DEFAULTS_HELP  #language en-US "Enroll keys with data from default variables"

+#string STR_SECURE_RESET_TO_DEFAULTS   #language en-US "Reset Secure Boot 
Keys"
+#string STR_RESET_TO_DEFAULTS_POPUP#language en-US "Secure Boot Keys & 
databases will be initialized from defaults.\n Are you sure?"
+
  #string STR_SECURE_BOOT_ENROLL_SIGNATURE   #language en-US "Enroll Signature"
  #string STR_SECURE_BOOT_DELETE_SIGNATURE   #language en-US "Delete Signature"
  #string STR_SECURE_BOOT_DELETE_LIST_FORM   #language en-US "Delete Signature List 
Form"



Reviewed-by: Pete Batard 
Tested-by: Pete Batard  on Raspberry Pi 4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75992): https://edk2.groups.io/g/devel/message/75992
Mute This Topic: https://groups.io/mt/83232302/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 5/6] SecurityPkg: Add new modules to Security package.

[Pete Batard]

One very minor remark:

On 2021.06.01 14:12, Grzegorz Bernacki wrote:

This commits adds modules related to initialization and
usage of default Secure Boot key variables to SecurityPkg.

Signed-off-by: Grzegorz Bernacki 
---
  SecurityPkg/SecurityPkg.dec | 14 ++
  SecurityPkg/SecurityPkg.dsc |  4 
  2 files changed, 18 insertions(+)

diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec
index 4001650fa2..dad3cae0ba 100644
--- a/SecurityPkg/SecurityPkg.dec
+++ b/SecurityPkg/SecurityPkg.dec
@@ -190,6 +190,20 @@
## GUID used to enforce loading order between Tcg2Acpi and Tcg2Smm
gTcg2MmSwSmiRegisteredGuid = { 0x9d4548b9, 0xa48d, 0x4db4, { 0x9a, 
0x68, 0x32, 0xc5, 0x13, 0x9e, 0x20, 0x18 } }
  
+  ## GUID used to specify section with default PK content

+  gDefaultPKFileGuid = { 0x85254ea7, 0x4759, 0x4fc4, { 0x82, 
0xd4, 0x5e, 0xed, 0x5f, 0xb0, 0xa4, 0xa0 } }
+
+  ## GUID used to specify section with default KEK content
+  gDefaultKEKFileGuid= { 0x6f64916e, 0x9f7a, 0x4c35, { 0xb9, 
0x52, 0xcd, 0x04, 0x1e, 0xfb, 0x05, 0xa3 } }
+
+  ## GUID used to specify section with default db content
+  gDefaultdbFileGuid = { 0xc491d352, 0x7623, 0x4843, { 0xac, 
0xcc, 0x27, 0x91, 0xa7, 0x57, 0x44, 0x21 } }
+
+  ## GUID used to specify section with default dbt content
+  gDefaultdbxFileGuid= { 0x5740766a, 0x718e, 0x4dc0, { 0x99, 
0x35, 0xc3, 0x6f, 0x7d, 0x3f, 0x88, 0x4f } }
+
+  ## GUID used to specify section with default dbx content
+  gDefaultdbtFileGuid= { 0x36c513ee, 0xa338, 0x4976, { 0xa0, 
0xfb, 0x6d, 0xdb, 0xa3, 0xda, 0xfe, 0x87 } }
  
  [Ppis]

## The PPI GUID for that TPM physical presence should be locked.
diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc
index 854f250625..e031775ca8 100644
--- a/SecurityPkg/SecurityPkg.dsc
+++ b/SecurityPkg/SecurityPkg.dsc
@@ -259,6 +259,10 @@
  
  [Components.IA32, Components.X64, Components.ARM, Components.AARCH64]

SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
+  SecurityPkg/Library/SecureBootVariableLib/SecureBootVariableLib.inf
+  SecurityPkg/EnrollFromDefaultKeys/EnrollFromDefaultKeys.inf
+  
SecurityPkg/VariableAuthenticated/SecureBootDefaultKeys/SecureBootDefaultKeys.inf
+


I don't think we need the extra line here.

  
  [Components.IA32, Components.X64, Components.AARCH64]

#



Reviewed-by: Pete Batard 
Tested-by: Pete Batard  on Raspberry Pi 4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75991): https://edk2.groups.io/g/devel/message/75991
Mute This Topic: https://groups.io/mt/83232301/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 4/6] SecurityPkg: Add EnrollFromDefaultKeys application.

[Pete Batard]

On 2021.06.01 14:12, Grzegorz Bernacki wrote:

This application allows user to force key enrollment from
Secure Boot default variables.

Signed-off-by: Grzegorz Bernacki 
---
  SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.inf |  47 
+
  SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.c   | 107 

  2 files changed, 154 insertions(+)
  create mode 100644 
SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.inf
  create mode 100644 
SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.c

diff --git a/SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.inf 
b/SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.inf
new file mode 100644
index 00..4d79ca3844
--- /dev/null
+++ b/SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.inf
@@ -0,0 +1,47 @@
+## @file
+#  Enroll PK, KEK, db, dbx from Default variables
+#
+#  Copyright (c) 2021, ARM Ltd. All rights reserved.
+#  Copyright (c) 2021, Semihalf All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  INF_VERSION= 1.28
+  BASE_NAME  = EnrollFromDefaultKeysApp
+  FILE_GUID  = 6F18CB2F-1293-4BC1-ABB8-35F84C71812E
+  MODULE_TYPE= UEFI_APPLICATION
+  VERSION_STRING = 0.1
+  ENTRY_POINT= UefiMain
+
+[Sources]
+  EnrollFromDefaultKeysApp.c
+
+[Packages]
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  SecurityPkg/SecurityPkg.dec
+
+[Guids]
+  gEfiCertPkcs7Guid
+  gEfiCertSha256Guid
+  gEfiCertX509Guid
+  gEfiCustomModeEnableGuid
+  gEfiGlobalVariableGuid
+  gEfiImageSecurityDatabaseGuid
+  gEfiSecureBootEnableDisableGuid
+
+[Protocols]
+  gEfiSmbiosProtocolGuid ## CONSUMES
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  MemoryAllocationLib
+  PrintLib
+  UefiApplicationEntryPoint
+  UefiBootServicesTableLib
+  UefiLib
+  UefiRuntimeServicesTableLib
+  SecureBootVariableLib
diff --git a/SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.c 
b/SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.c
new file mode 100644
index 00..1907ce1d4e
--- /dev/null
+++ b/SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.c
@@ -0,0 +1,107 @@
+/** @file
+  Enroll default PK, KEK, db, dbx.
+
+Copyright (c) 2021, ARM Ltd. All rights reserved.
+Copyright (c) 2021, Semihalf All rights reserved.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include // gEfiCustomModeEnableGuid
+#include  // EFI_SETUP_MODE_NAME
+#include // EFI_IMAGE_SECURITY_DATABASE
+#include  // GUID_STRING_LENGTH
+#include// CopyGuid()
+#include // ASSERT()
+#include  // FreePool()
+#include // AsciiSPrint()
+#include // gBS
+#include  // AsciiPrint()
+#include  // gRT
+#include 
+#include 
+
+#define FAIL(fmt...) AsciiPrint("EnrollFromDefaultKeysApp: " fmt)
+
+/**
+  Entry point function of this shell application.
+**/
+EFI_STATUS
+EFIAPI
+UefiMain (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS Status;
+  UINT8  SetupMode;
+
+  Status = GetSetupMode ();
+  if (EFI_ERROR (Status)) {
+FAIL ("Cannot get SetupMode variable: %r\n", Status);
+return 1;
+  }
+
+  if (SetupMode == USER_MODE) {
+FAIL ("Skipped - USER_MODE\n");
+return 1;
+  }
+
+  Status = SetSecureBootMode (CUSTOM_SECURE_BOOT_MODE);
+  if (EFI_ERROR (Status)) {
+FAIL ("Cannot set CUSTOM_SECURE_BOOT_MODE: %r\n", Status);
+return 1;
+  }
+
+  Status = EnrollDbFromDefault ();
+  if (EFI_ERROR (Status)) {
+FAIL ("Cannot enroll db: %r\n", Status);
+goto error;
+  }
+
+  Status = EnrollDbxFromDefault ();
+  if (EFI_ERROR (Status)) {
+FAIL ("Cannot enroll dbt: %r\n", Status);
+  }
+
+  Status = EnrollDbtFromDefault ();
+  if (EFI_ERROR (Status)) {
+FAIL ("Cannot enroll dbx: %r\n", Status);
+  }
+
+  Status = EnrollKEKFromDefault ();
+  if (EFI_ERROR (Status)) {
+FAIL ("Cannot enroll KEK: %r\n", Status);
+goto cleardbs;
+  }
+
+  Status = EnrollPKFromDefault ();
+  if (EFI_ERROR (Status)) {
+FAIL ("Cannot enroll PK: %r\n", Status);
+goto clearKEK;
+  }
+
+  Status = SetSecureBootMode (STANDARD_SECURE_BOOT_MODE);
+  if (EFI_ERROR (Status)) {
+FAIL ("Cannot set CustomMode to STANDARD_SECURE_BOOT_MODE\n"
+  "Please do it manually, otherwise system can be easily compromised\n");
+  }
+  return 0;
+
+clearKEK:
+  DeleteKEK ();
+
+cleardbs:
+  DeleteDbt ();
+  DeleteDbx ();
+  DeleteDb ();
+
+error:
+  Status = SetSecureBootMode (STANDARD_SECURE_BOOT_MODE);
+  if (EFI_ERROR (Status)) {
+FAIL ("Cannot set CustomMode to STANDARD_SECURE_BOOT_MODE\n"
+  "Plea

Re: [edk2-devel] [PATCH v2 3/6] SecurityPkg: Add SecureBootDefaultKeysDxe driver

[Pete Batard]

 
b/SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.uni
new file mode 100644
index 00..30f03aee5d
--- /dev/null
+++ 
b/SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootDefaultKeysDxe.uni
@@ -0,0 +1,17 @@
+// /** @file
+// Provides the capability to intialize Secure Boot default variables
+//
+// Module which initializes Secure boot default variables.
+//
+// Copyright (c) 2021, ARM Ltd. All rights reserved.
+// Copyright (c) 2021, Semihalf All rights reserved.
+//
+// SPDX-License-Identifier: BSD-2-Clause-Patent
+//
+// **/
+
+
+#string STR_MODULE_ABSTRACT #language en-US "Module which initializes 
Secure boot default variables"
+
+#string STR_MODULE_DESCRIPTION  #language en-US "This module reads embedded 
keys and initializes Secure Boot default variables."
+


This adds an extra trailing blank line.





Reviewed-by: Pete Batard 
Tested-by: Pete Batard  on Raspberry Pi 4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75989): https://edk2.groups.io/g/devel/message/75989
Mute This Topic: https://groups.io/mt/83232299/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 2/6] SecurityPkg: Create include file for default key content.

[Pete Batard]

On 2021.06.01 14:12, Grzegorz Bernacki wrote:

This commits add file which can be included by platform Flash
Description File. It allows to specify certificate files, which
will be embedded into binary file. The content of these files
can be used to initialize Secure Boot default keys and databases.

Signed-off-by: Grzegorz Bernacki 
---
  SecurityPkg/SecureBootDefaultKeys.fdf.inc | 62 
  1 file changed, 62 insertions(+)
  create mode 100644 SecurityPkg/SecureBootDefaultKeys.fdf.inc

diff --git a/SecurityPkg/SecureBootDefaultKeys.fdf.inc 
b/SecurityPkg/SecureBootDefaultKeys.fdf.inc
new file mode 100644
index 00..056586b204
--- /dev/null
+++ b/SecurityPkg/SecureBootDefaultKeys.fdf.inc
@@ -0,0 +1,62 @@
+
+!if $(DEFAULT_KEYS) == TRUE
+  FILE FREEFORM = 85254ea7-4759-4fc4-82d4-5eed5fb0a4a0 {
+  !ifdef $(PK_DEFAULT_FILE)
+SECTION RAW = $(PK_DEFAULT_FILE)
+  !endif
+SECTION UI = "PK Default"
+  }
+
+  FILE FREEFORM = 6f64916e-9f7a-4c35-b952-cd041efb05a3 {
+  !ifdef $(KEK_DEFAULT_FILE1)
+SECTION RAW = $(KEK_DEFAULT_FILE1)
+  !endif
+  !ifdef $(KEK_DEFAULT_FILE2)
+SECTION RAW = $(KEK_DEFAULT_FILE2)
+  !endif
+  !ifdef $(KEK_DEFAULT_FILE3)
+SECTION RAW = $(KEK_DEFAULT_FILE3)
+  !endif
+SECTION UI = "KEK Default"
+  }
+
+  FILE FREEFORM = c491d352-7623-4843-accc-2791a7574421 {
+  !ifdef $(DB_DEFAULT_FILE1)
+SECTION RAW = $(DB_DEFAULT_FILE1)
+  !endif
+  !ifdef $(DB_DEFAULT_FILE2)
+SECTION RAW = $(DB_DEFAULT_FILE2)
+  !endif
+  !ifdef $(DB_DEFAULT_FILE3)
+SECTION RAW = $(DB_DEFAULT_FILE3)
+  !endif
+SECTION UI = "DB Default"
+  }
+
+  FILE FREEFORM = 36c513ee-a338-4976-a0fb-6ddba3dafe87 {
+  !ifdef $(DBT_DEFAULT_FILE1)
+SECTION RAW = $(DBT_DEFAULT_FILE1)
+  !endif
+  !ifdef $(DBT_DEFAULT_FILE2)
+SECTION RAW = $(DBT_DEFAULT_FILE2)
+  !endif
+  !ifdef $(DBT_DEFAULT_FILE3)
+SECTION RAW = $(DBT_DEFAULT_FILE3)
+  !endif
+SECTION UI = "DBT Default"
+  }
+
+  FILE FREEFORM = 5740766a-718e-4dc0-9935-c36f7d3f884f {
+  !ifdef $(DBX_DEFAULT_FILE1)
+SECTION RAW = $(DBX_DEFAULT_FILE1)
+  !endif
+  !ifdef $(DBX_DEFAULT_FILE2)
+SECTION RAW = $(DBX_DEFAULT_FILE2)
+  !endif
+  !ifdef $(DBX_DEFAULT_FILE3)
+SECTION RAW = $(DBX_DEFAULT_FILE3)
+  !endif
+SECTION UI = "DBX Default"
+  }
+
+!endif



Reviewed-by: Pete Batard 
Tested-by: Pete Batard  on Raspberry Pi 4



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75988): https://edk2.groups.io/g/devel/message/75988
Mute This Topic: https://groups.io/mt/83232296/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/6] SecurityPkg: Create library for setting Secure Boot variables.

[Pete Batard]

AR16*VariableName,
-  IN  EFI_GUID  *VendorGuid
-  )
-{
-  EFI_STATUS  Status;
-  VOID*   Variable;
-  UINT8   *Data;
-  UINTN   DataSize;
-  UINT32  Attr;
-
-  GetVariable2 (VariableName, VendorGuid, , NULL);
-  if (Variable == NULL) {
-return EFI_SUCCESS;
-  }
-  FreePool (Variable);
-
-  Data = NULL;
-  DataSize = 0;
-  Attr = EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_RUNTIME_ACCESS | 
EFI_VARIABLE_BOOTSERVICE_ACCESS
- | EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS;
-
-  Status = CreateTimeBasedPayload (, );
-  if (EFI_ERROR (Status)) {
-DEBUG ((EFI_D_ERROR, "Fail to create time-based data payload: %r", 
Status));
-return Status;
-  }
-
-  Status = gRT->SetVariable (
-  VariableName,
-  VendorGuid,
-  Attr,
-  DataSize,
-  Data
-  );
-  if (Data != NULL) {
-FreePool (Data);
-  }
-  return Status;
-}
-
-/**
-
-  Set the platform secure boot mode into "Custom" or "Standard" mode.
-
-  @param[in]   SecureBootModeNew secure boot mode: 
STANDARD_SECURE_BOOT_MODE or
- CUSTOM_SECURE_BOOT_MODE.
-
-  @return EFI_SUCCESSThe platform has switched to the special 
mode successfully.
-  @return other  Fail to operate the secure boot mode.
-
-**/
-EFI_STATUS
-SetSecureBootMode (
-  IN UINT8 SecureBootMode
-  )
-{
-  return gRT->SetVariable (
-EFI_CUSTOM_MODE_NAME,
-,
-EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS,
-sizeof (UINT8),
-
-);
-}
-
  /**
This code checks if the encode type and key strength of X.509
certificate is qualified.
@@ -646,32 +485,6 @@ ON_EXIT:
return Status;
  }
  
-/**

-  Remove the PK variable.
-
-  @retval EFI_SUCCESSDelete PK successfully.
-  @retval Others Could not allow to delete PK.
-
-**/
-EFI_STATUS
-DeletePlatformKey (
-  VOID
-)
-{
-  EFI_STATUS Status;
-
-  Status = SetSecureBootMode(CUSTOM_SECURE_BOOT_MODE);
-  if (EFI_ERROR (Status)) {
-return Status;
-  }
-
-  Status = DeleteVariable (
- EFI_PLATFORM_KEY_NAME,
- 
- );
-  return Status;
-}
-
  /**
Enroll a new KEK item from public key storing file (*.pbk).
  
diff --git a/SecurityPkg/Library/SecureBootVariableLib/SecureBootVariableLib.uni b/SecurityPkg/Library/SecureBootVariableLib/SecureBootVariableLib.uni

new file mode 100644
index 000000..2c51e4db53
--- /dev/null
+++ b/SecurityPkg/Library/SecureBootVariableLib/SecureBootVariableLib.uni
@@ -0,0 +1,16 @@
+// /** @file
+//
+// Provides initialization of Secure Boot keys and databases.
+//
+// Copyright (c) 2021, ARM Ltd. All rights reserved.
+// Copyright (c) 2021, Semihalf All rights reserved.
+//
+// SPDX-License-Identifier: BSD-2-Clause-Patent
+//
+// **/
+
+
+#string STR_MODULE_ABSTRACT #language en-US "Provides function to 
initialize PK, KEK and databases based on default variables."
+
+#string STR_MODULE_DESCRIPTION  #language en-US "Provides function to 
initialize PK, KEK and databases based on default variables."
+



Reviewed-by: Pete Batard 
Tested-by: Pete Batard  on Raspberry Pi 4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75987): https://edk2.groups.io/g/devel/message/75987
Mute This Topic: https://groups.io/mt/83232297/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/2] Platform/Raspberrypi: Update DMA constants based on SOC revision

[Pete Batard]

Two minor notes below:

On 2021.05.11 23:41, Jeremy Linton wrote:

The newer BCM2711 SoC's don't have a DMA constraint on the emmc2
controller. So we don't need to do the 1G translation. Lets
allow the AML to detect the SoC revision and return a different
_DMA resource.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/AcpiTables/Emmc.asl   | 39 +-
  .../Bcm27xx/Include/IndustryStandard/Bcm2711.h |  2 ++
  2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Emmc.asl 
b/Platform/RaspberryPi/AcpiTables/Emmc.asl
index 23febe37b4..c6691e81dc 100644
--- a/Platform/RaspberryPi/AcpiTables/Emmc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Emmc.asl
@@ -8,6 +8,7 @@
  
  #include 

  #include 
+#include 
  
  #include "AcpiTables.h"
  
@@ -31,7 +32,8 @@ DefinitionBlock (__FILE__, "SSDT", 2, "RPIFDN", "RPI4EMMC", 2)

  Return (^RBUF)
}
  
-  Name (_DMA, ResourceTemplate() {

+  // Translated DMA region for < C0


Even if the code makes it clear that we're testing the chip revision to 
decide what region to return, I would prefer if we had "for pre C0 
revisions of the SoC" instead of "for < C0", as I suspect people who 
read this too quickly, and have no idea what C0, refers to may think 
we're talking about a DMA address boundary or something.



+  Name (DMTR, ResourceTemplate() {
  QWordMemory (ResourceProducer,
,
MinFixed,
@@ -48,6 +50,41 @@ DefinitionBlock (__FILE__, "SSDT", 2, "RPIFDN", "RPI4EMMC", 
2)
  )
})
  
+  // Non translated DMA region for >= C0


Same as above: "for post C0 revisions of the SoC"


+  Name (DMNT, ResourceTemplate() {
+QWordMemory (ResourceProducer,
+  ,
+  MinFixed,
+  MaxFixed,
+  NonCacheable,
+  ReadWrite,
+  0x0,
+  0x, // MIN
+  0x00FF, // MAX
+  0x, // TRA
+  0x0100, // LEN
+  ,
+  ,
+)
+  })
+
+  Method (_DMA, 0x0, Serialized)
+  {
+OperationRegion (CHPR, SystemMemory, ID_CHIPREV, 0x4)
+  Field (CHPR, DWordAcc, NoLock, Preserve) {
+SOCI, 32
+}
+
+if ((SOCI & 0xFF) >= 0x20)
+{
+  return (^DMNT);
+}
+else
+{
+  return (^DMTR);
+}
+  }
+
// emmc2 Host Controller. (brcm,bcm2711-emmc2)
Device (SDC3)
{
diff --git a/Silicon/Broadcom/Bcm27xx/Include/IndustryStandard/Bcm2711.h 
b/Silicon/Broadcom/Bcm27xx/Include/IndustryStandard/Bcm2711.h
index 86906b2438..8a69128d11 100644
--- a/Silicon/Broadcom/Bcm27xx/Include/IndustryStandard/Bcm2711.h
+++ b/Silicon/Broadcom/Bcm27xx/Include/IndustryStandard/Bcm2711.h
@@ -88,4 +88,6 @@
  
  #define THERM_SENSOR   0xfd5d2200
  
+#define ID_CHIPREV 0xfc404000

+
  #endif /* BCM2711_H__ */



With the comment changes, if agreed, applicable during integration:
Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75069): https://edk2.groups.io/g/devel/message/75069
Mute This Topic: https://groups.io/mt/82759461/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/2] Platform/RaspberryPi: Invert emmc PIO/DMA selection

[Pete Batard]

On 2021.05.11 23:41, Jeremy Linton wrote:

Now that we are doing SoC detection and adjusting the DMA
window it should be safe to turn DMA on by default.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 4 ++--
  Platform/RaspberryPi/RPi4/RPi4.dsc  | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index aa124e4e31..759db6212f 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -300,8 +300,8 @@ formset
  prompt  = STRING_TOKEN(STR_MMC_EMMC_PROMPT),
  help= STRING_TOKEN(STR_MMC_EMMC_HELP),
  flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
-option text = STRING_TOKEN(STR_MMC_EMMC_PIO), value = 0, flags = 
DEFAULT;
-option text = STRING_TOKEN(STR_MMC_EMMC_DMA), value = 1, flags = 0;
+option text = STRING_TOKEN(STR_MMC_EMMC_PIO), value = 0, flags = 0;
+option text = STRING_TOKEN(STR_MMC_EMMC_DMA), value = 1, flags = 
DEFAULT;
  endoneof;
  endif;
  #endif
diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index cf796acf6a..b3acc04e07 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -486,7 +486,7 @@

gRaspberryPiTokenSpaceGuid.PcdMmcSdDefaultSpeedMHz|L"MmcSdDefaultSpeedMHz"|gConfigDxeFormSetGuid|0x0|25

gRaspberryPiTokenSpaceGuid.PcdMmcSdHighSpeedMHz|L"MmcSdHighSpeedMHz"|gConfigDxeFormSetGuid|0x0|50

gRaspberryPiTokenSpaceGuid.PcdMmcDisableMulti|L"MmcDisableMulti"|gConfigDxeFormSetGuid|0x0|0
-  
gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma|L"MmcEnableDma"|gConfigDxeFormSetGuid|0x0|0
+  
gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma|L"MmcEnableDma"|gConfigDxeFormSetGuid|0x0|1
  
#

# Debug-related.



Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75070): https://edk2.groups.io/g/devel/message/75070
Mute This Topic: https://groups.io/mt/82759463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] Platform/RaspberryPi: Update ACPI table revision

[Pete Batard]

On 2021.05.10 10:08, Sunny Wang wrote:

As per ACPI 6.3 specification, the DSDT/SSDT table should use revision 2
, so update the revision numbers to 2.
This also fixes https://github.com/pftf/RPi4/issues/94 (FWTS failures).

Testing Done:
   - Booted to UEFI Shell and used apciview command to check all ACPI
 tables' revision.
   - Ran FWTS test and no longer see the ACPI DSDT and SSDT revision
 failures. Note that the XSDT revision failure is caused by the FWTS
 tool's issue that got fixed in
 commit c522bfedc9839a474b8d590ba36bec77436d2e90

Cc: Samer El-Haj-Mahmoud 
Cc: Jeremy Linton 
Cc: Sami Mujawar 
Cc: Pete Batard 
Cc: Ard Biesheuvel 
Signed-off-by: Sunny Wang 
---
  Platform/RaspberryPi/AcpiTables/Dsdt.asl| 3 ++-
  Platform/RaspberryPi/AcpiTables/Emmc.asl| 4 ++--
  Platform/RaspberryPi/AcpiTables/SsdtThermal.asl | 4 ++--
  3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index d116f965e1..54fa3eca7b 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -5,6 +5,7 @@
   *  Copyright (c) 2020, Pete Batard 
   *  Copyright (c) 2018-2020, Andrey Warkentin 
   *  Copyright (c) Microsoft Corporation. All rights reserved.
+ *  Copyright (c) 2021, ARM Limited. All rights reserved.
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
   *
@@ -58,7 +59,7 @@
Store (Length, LE ## Index)   \
Add (MI ## Index, LE ## Index - 1, MA ## Index)
  
-DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)

+DefinitionBlock ("Dsdt.aml", "DSDT", 2, "RPIFDN", "RPI", 2)
  {
Scope (\_SB_)
{
diff --git a/Platform/RaspberryPi/AcpiTables/Emmc.asl 
b/Platform/RaspberryPi/AcpiTables/Emmc.asl
index 179dd3ecdb..88811eb354 100644
--- a/Platform/RaspberryPi/AcpiTables/Emmc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Emmc.asl
@@ -1,6 +1,6 @@
  /** @file
   *
- *  Copyright (c) 2021 Arm. All rights reserved.
+ *  Copyright (c) 2021, ARM Limited. All rights reserved.
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
   *
@@ -11,7 +11,7 @@
  
  #include "AcpiTables.h"
  
-DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4EMMC", 2)

+DefinitionBlock (__FILE__, "SSDT", 2, "RPIFDN", "RPI4EMMC", 2)
  {
Scope (\_SB_)
{
diff --git a/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl 
b/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
index acfa4699bb..e82f55bebd 100644
--- a/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
+++ b/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
@@ -2,7 +2,7 @@
   *
   *  Secondary System Description Table (SSDT) for active (fan) cooling
   *
- *  Copyright (c) 2020, Arm Ltd. All rights reserved.
+ *  Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
   *
@@ -14,7 +14,7 @@
  
  #include 
  
-DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPITHFAN", 2)

+DefinitionBlock (__FILE__, "SSDT", 2, "RPIFDN", "RPITHFAN", 2)
  {
External (\_SB_.EC00, DeviceObj)
External (\_SB_.EC00.TZ00, DeviceObj)



Reviewed-by: Pete Batard 
Tested-by: Pete Batard  (Windows 10 boot)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74874): https://edk2.groups.io/g/devel/message/74874
Mute This Topic: https://groups.io/mt/82715296/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] Platform/RaspberryPi: Setup option for disabling Fast Boot

[Pete Batard]

On 2021.04.13 16:22, Ard Biesheuvel wrote:

On Tue, 13 Apr 2021 at 14:13, Pete Batard  wrote:


Thanks for the v2. Everything looks good now.

On 2021.04.13 08:14, Sunny Wang wrote:

This is a fix for https://github.com/pftf/RPi4/issues/114.

Changes:
1. Add a setup option called Boot Policy and consume the setting
   during boot to whether perform or skip ConnectAll.
2. The Default setting is set to Full discovery because it is not
   worth enabling Fast boot by default on RaspberryPi systems.
   Enabling it just saves boot time about 1 second, but caused a
   lot of issues.

Testing Done:
- Booted to Standalone UEFI shell on SD card and use drivers
  command to check the result with Fast Boot and Full discovery
  settings. Then, child/device handles are created as expected.

Note and to-do items:
- The root cause looks like that boot loaders and some tools like
  grub and iPXE haven't supported selective connect/Fast boot.
  However, system firmware should still provide a setup option for
  user to enable Fast boot with old version boot loaders and tools
  , which is why we proposed this change. We will also report this
  issue to boot loader and tool vendors/open source GitHubs.
- We Will add more options for connecting specific type devices so
  that we can still have the shortest boot time for all use cases.

Cc: Samer El-Haj-Mahmoud 
Cc: Jeremy Linton 
Cc: Sami Mujawar 
Cc: Pete Batard 
Cc: Ard Biesheuvel 
Signed-off-by: Sunny Wang 
---
   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 11 ++-
   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf  |  3 ++-
   .../Drivers/ConfigDxe/ConfigDxeHii.uni   | 10 +-
   .../Drivers/ConfigDxe/ConfigDxeHii.vfr   | 16 +++-
   Platform/RaspberryPi/Include/ConfigVars.h| 12 +++-
   .../Library/PlatformBootManagerLib/PlatformBm.c  | 15 +--
   .../PlatformBootManagerLib.inf   |  1 +
   Platform/RaspberryPi/RPi3/RPi3.dsc   |  9 -
   Platform/RaspberryPi/RPi4/RPi4.dsc   |  9 -
   Platform/RaspberryPi/RaspberryPi.dec |  2 ++
   10 files changed, 79 insertions(+), 9 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 22f86d4d44..d3c5869949 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -1,6 +1,6 @@
   /** @file
*
- *  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
+ *  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
*  Copyright (c) 2018 - 2020, Andrei Warkentin 
*
*  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -281,6 +281,15 @@ SetupVariables (
   );
 }

+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"BootPolicy",
+  ,
+  NULL, , );
+  if (EFI_ERROR (Status)) {
+Status = PcdSet32S (PcdBootPolicy, PcdGet32 (PcdBootPolicy));
+ASSERT_EFI_ERROR (Status);
+  }
+
 Size = sizeof (UINT32);
 Status = gRT->GetVariable (L"SdIsArasan",
 ,
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index d51e54e010..032e40b0c3 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -2,7 +2,7 @@
   #
   #  Component description file for the RasbperryPi DXE platform config driver.
   #
-#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
+#  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
   #  Copyright (c) 2018 - 2020, Andrei Warkentin 
   #
   #  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -93,6 +93,7 @@
 gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
 gRaspberryPiTokenSpaceGuid.PcdFanOnGpio
 gRaspberryPiTokenSpaceGuid.PcdFanTemp
+  gRaspberryPiTokenSpaceGuid.PcdBootPolicy

   [Depex]
 gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 466fa852cb..81761d64bb 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -1,7 +1,7 @@
   /** @file
*
*  Copyright (c) 2018, Andrei Warkentin 
- *  Copyright (c) 2020, ARM Limited. All rights reserved.
+ *  Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.
*
*  SPDX-License-Identifier: BSD-2-Clause-Patent
*
@@ -60,6 +60,14 @@
   #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
   #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"

+#string STR_BOOT_POLICY_PROMPT#language en-US "Boot Policy"
+#string STR_B

Re: [edk2-devel] [PATCH v2 1/1] Platform/RaspberryPi: Setup option for disabling Fast Boot

[Pete Batard]

Thanks for the v2. Everything looks good now.

On 2021.04.13 08:14, Sunny Wang wrote:

This is a fix for https://github.com/pftf/RPi4/issues/114.

Changes:
   1. Add a setup option called Boot Policy and consume the setting
  during boot to whether perform or skip ConnectAll.
   2. The Default setting is set to Full discovery because it is not
  worth enabling Fast boot by default on RaspberryPi systems.
  Enabling it just saves boot time about 1 second, but caused a
  lot of issues.

Testing Done:
   - Booted to Standalone UEFI shell on SD card and use drivers
 command to check the result with Fast Boot and Full discovery
 settings. Then, child/device handles are created as expected.

Note and to-do items:
   - The root cause looks like that boot loaders and some tools like
 grub and iPXE haven't supported selective connect/Fast boot.
 However, system firmware should still provide a setup option for
 user to enable Fast boot with old version boot loaders and tools
 , which is why we proposed this change. We will also report this
 issue to boot loader and tool vendors/open source GitHubs.
   - We Will add more options for connecting specific type devices so
 that we can still have the shortest boot time for all use cases.

Cc: Samer El-Haj-Mahmoud 
Cc: Jeremy Linton 
Cc: Sami Mujawar 
Cc: Pete Batard 
Cc: Ard Biesheuvel 
Signed-off-by: Sunny Wang 
---
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 11 ++-
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf  |  3 ++-
  .../Drivers/ConfigDxe/ConfigDxeHii.uni   | 10 +-
  .../Drivers/ConfigDxe/ConfigDxeHii.vfr   | 16 +++-
  Platform/RaspberryPi/Include/ConfigVars.h| 12 +++-
  .../Library/PlatformBootManagerLib/PlatformBm.c  | 15 +--
  .../PlatformBootManagerLib.inf   |  1 +
  Platform/RaspberryPi/RPi3/RPi3.dsc   |  9 -
  Platform/RaspberryPi/RPi4/RPi4.dsc   |  9 -
  Platform/RaspberryPi/RaspberryPi.dec |  2 ++
  10 files changed, 79 insertions(+), 9 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 22f86d4d44..d3c5869949 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -1,6 +1,6 @@
  /** @file
   *
- *  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
+ *  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
   *  Copyright (c) 2018 - 2020, Andrei Warkentin 
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -281,6 +281,15 @@ SetupVariables (
  );
}
  
+  Size = sizeof (UINT32);

+  Status = gRT->GetVariable (L"BootPolicy",
+  ,
+  NULL, , );
+  if (EFI_ERROR (Status)) {
+Status = PcdSet32S (PcdBootPolicy, PcdGet32 (PcdBootPolicy));
+ASSERT_EFI_ERROR (Status);
+  }
+
Size = sizeof (UINT32);
Status = gRT->GetVariable (L"SdIsArasan",
,
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index d51e54e010..032e40b0c3 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -2,7 +2,7 @@
  #
  #  Component description file for the RasbperryPi DXE platform config driver.
  #
-#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.
+#  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
  #  Copyright (c) 2018 - 2020, Andrei Warkentin 
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -93,6 +93,7 @@
gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
gRaspberryPiTokenSpaceGuid.PcdFanOnGpio
gRaspberryPiTokenSpaceGuid.PcdFanTemp
+  gRaspberryPiTokenSpaceGuid.PcdBootPolicy
  
  [Depex]

gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 466fa852cb..81761d64bb 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -1,7 +1,7 @@
  /** @file
   *
   *  Copyright (c) 2018, Andrei Warkentin 
- *  Copyright (c) 2020, ARM Limited. All rights reserved.
+ *  Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
   *
@@ -60,6 +60,14 @@
  #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
  #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
  
+#string STR_BOOT_POLICY_PROMPT#language en-US "Boot Policy"

+#string STR_BOOT_POLICY_HELP  #language en-US "When Fast Boot is selected, 
only required devices will be discovered for reducing "
+  

Re: [edk2-devel] [PATCH 1/1] Platform/RaspberryPi: Setup option for disabling Fast Boot

[Pete Batard]

Hi Sunny,

Functionaly, I see no issues with this patch, and it's indeed a good 
solution to the problem of trying to satisfy everyone while fixing the 
issues we are seeing.


There are however a few minor typos and whitespace issues, that I'm 
detailing below. So could you please send a v2 to address these?


On 2021.04.12 10:05, Sunny Wang wrote:

This is a fix for https://github.com/pftf/RPi4/issues/114.

Changes:
   1. Add a setup option called Boot Policy and consume the setting
  during boot to whether perform or skip ConnectAll.
   2. The Default setting is set to Full discovery because it is not
  worth enabling Fast boot by default on RaspberryPi systems.
  Enabling it just saves boot time about 1 second, but caused a
  lot of issues.

Testing Done:
   - Booted to Standalone UEFI shell on SD card and use drivers
 command to check the result with Fast Boot and Full discovery
 settings. Then, child/device handles are created as expected.

Note and to-do items:
   - The root cause looks like that boot loaders and some tools like
 grub and iPXE haven't supported selective connect/Fast boot.
 However, system firmware should still provide a setup option for
 user to enable Fast boot with old version boot loaders and tools
 , which is why we proposed this change. We will also report this
 issue to boot loader and tool vendors/open source GitHubs.
   - We Will add more options for connecting specific type devices so
 that we can still have the shortest boot time for all use cases.

Cc: Samer El-Haj-Mahmoud 
Cc: Jeremy Linton 
Cc: Pete Batard 
Cc: Ard Biesheuvel 
Signed-off-by: Sunny Wang 
---
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 11 ++-
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf  |  3 ++-
  .../Drivers/ConfigDxe/ConfigDxeHii.uni   | 10 +-
  .../Drivers/ConfigDxe/ConfigDxeHii.vfr   | 15 ++-
  Platform/RaspberryPi/Include/ConfigVars.h| 12 +++-
  .../Library/PlatformBootManagerLib/PlatformBm.c  | 16 ++--
  .../PlatformBootManagerLib.inf   |  1 +
  Platform/RaspberryPi/RPi3/RPi3.dsc   | 10 +-
  Platform/RaspberryPi/RPi4/RPi4.dsc   |  9 -
  Platform/RaspberryPi/RaspberryPi.dec |  2 ++
  10 files changed, 80 insertions(+), 9 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 22f86d4d44..d3c5869949 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -1,6 +1,6 @@
  /** @file

   *

- *  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.

+ *  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.

   *  Copyright (c) 2018 - 2020, Andrei Warkentin 

   *

   *  SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -281,6 +281,15 @@ SetupVariables (
  );

}

  


+  Size = sizeof (UINT32);

+  Status = gRT->GetVariable (L"BootPolicy",

+  ,

+  NULL, , );

+  if (EFI_ERROR (Status)) {

+Status = PcdSet32S (PcdBootPolicy, PcdGet32 (PcdBootPolicy));

+ASSERT_EFI_ERROR (Status);

+  }

+

Size = sizeof (UINT32);

Status = gRT->GetVariable (L"SdIsArasan",

,

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index d51e54e010..032e40b0c3 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -2,7 +2,7 @@
  #

  #  Component description file for the RasbperryPi DXE platform config driver.

  #

-#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.

+#  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.

  #  Copyright (c) 2018 - 2020, Andrei Warkentin 

  #

  #  SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -93,6 +93,7 @@
gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB

gRaspberryPiTokenSpaceGuid.PcdFanOnGpio

gRaspberryPiTokenSpaceGuid.PcdFanTemp

+  gRaspberryPiTokenSpaceGuid.PcdBootPolicy

  


  [Depex]

gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 466fa852cb..7b14fdf39f 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -1,7 +1,7 @@
  /** @file

   *

   *  Copyright (c) 2018, Andrei Warkentin 

- *  Copyright (c) 2020, ARM Limited. All rights reserved.

+ *  Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.

   *

   *  SPDX-License-Identifier: BSD-2-Clause-Patent

   *

@@ -60,6 +60,14 @@
  #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"

  #string STR_ADVANCED_ASSET_TAG_HELP   #

Re: [edk2-devel] [edk2-platforms][PATCH v2 1/1] Platform/RaspberryPi: Fix mini UART clock divisor calculation

[Pete Batard]

On 2021.04.08 13:26, Ard Biesheuvel wrote:

On Thu, 8 Apr 2021 at 13:43, Pete Batard  wrote:


On 2021.04.08 12:06, Ard Biesheuvel wrote:

On Thu, 8 Apr 2021 at 11:47, Pete Batard  wrote:


On 2021.04.06 15:04, Mario Bălănică wrote:

The VPU clock divisor has changed in this commit:
https://github.com/raspberrypi/firmware/commit/1e5456a,
thus breaking the mini UART clock divisor calculation on the Pi 4.

Fix this by reading the core clock from the mailbox instead.

Signed-off-by: Mario Bălănică 
---
Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c   | 15 
+++
Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S |  4 

Platform/RaspberryPi/RPi4/RPi4.dsc   |  6 
--
3 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c 
b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
index 5e83bbf022eb..d2f983bf0a9f 100644
--- a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
+++ b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
@@ -34,25 +34,16 @@ SerialPortGetDivisor (
  UINT32  SerialBaudRate

)

{

-  UINT64  BaseClockRate;

+  UINT32  BaseClockRate;

  UINT32  Divisor;



-  //

-  // On the Raspberry Pi, the clock to use for the 16650-compatible UART

-  // is the base clock divided by the 12.12 fixed point VPU clock divisor.

-  //

-  BaseClockRate = (UINT64)PcdGet32 (PcdSerialClockRate);

-#if (RPI_MODEL == 4)

-  Divisor = MmioRead32(BCM2836_CM_BASE + BCM2836_CM_VPU_CLOCK_DIVISOR) & 
0xFF;

-  if (Divisor != 0)

-BaseClockRate = (BaseClockRate << 12) / Divisor;

-#endif

+  BaseClockRate = PcdGet32 (PcdSerialClockRate);



  //

  // As per the BCM2xxx datasheets:

  // baudrate = system_clock_freq / (8 * (divisor + 1)).

  //

-  Divisor = (UINT32)BaseClockRate / (SerialBaudRate * 8);

+  Divisor = BaseClockRate / (SerialBaudRate * 8);

  if (Divisor != 0) {

Divisor--;

  }

diff --git 
a/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S 
b/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
index 58351e4fb8cc..7008aaf8aa4c 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
+++ b/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
@@ -85,13 +85,11 @@ ASM_FUNC (ArmPlatformPeiBootAction)
adr x2, mBoardRevision

str w0, [x2]



-#if (RPI_MODEL == 3)

run .Lclkinfo_buffer



ldr w0, .Lfrequency

adr x2, _gPcd_BinaryPatch_PcdSerialClockRate

str w0, [x2]

-#endif



ret



@@ -135,7 +133,6 @@ ASM_FUNC (ArmPlatformPeiBootAction)
.long   0   // end tag

.set.Lrevinfo_size, . - .Lrevinfo_buffer



-#if (RPI_MODEL == 3)

.align  4

.Lclkinfo_buffer:

.long   .Lclkinfo_size

@@ -148,7 +145,6 @@ ASM_FUNC (ArmPlatformPeiBootAction)
.long   0   // frequency

.long   0   // end tag

.set.Lclkinfo_size, . - .Lclkinfo_buffer

-#endif



//UINTN

//ArmPlatformGetPrimaryCoreMpId (

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 2c05c31118d2..ff802d8347ea 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -429,7 +429,6 @@ [PcdsFixedAtBuild.common]
  gArmPlatformTokenSpaceGuid.PL011UartClkInHz|4800

  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio|TRUE

  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|4

-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate|10

  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialFifoControl|0x27

  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialExtendedTxFifoSize|8

  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200

@@ -465,6 +464,9 @@ [PcdsFixedAtBuild.common]
  gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVendor|L"EDK2"

  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE



+[PcdsPatchableInModule]

+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate|5

+

[PcdsDynamicHii.common.DEFAULT]



  #

@@ -621,7 +623,7 @@ [Components.common]
  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf

  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {



-  
SerialPortLib|Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.inf

+  
SerialPortLib|Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortDxeLib.inf

  }

  Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.inf

  EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.inf



Reviewed-by: Pete Batard 
Tested-by: Pete Batard 


Thanks Pete.

Could anyone get me a version of this patch that is no

Re: [edk2-devel] [edk2-platforms][PATCH v2 1/1] Platform/RaspberryPi: Fix mini UART clock divisor calculation

[Pete Batard]

On 2021.04.08 12:06, Ard Biesheuvel wrote:

On Thu, 8 Apr 2021 at 11:47, Pete Batard  wrote:


On 2021.04.06 15:04, Mario Bălănică wrote:

The VPU clock divisor has changed in this commit:
https://github.com/raspberrypi/firmware/commit/1e5456a,
thus breaking the mini UART clock divisor calculation on the Pi 4.

Fix this by reading the core clock from the mailbox instead.

Signed-off-by: Mario Bălănică 
---
   Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c   | 15 
+++
   Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S |  4 

   Platform/RaspberryPi/RPi4/RPi4.dsc   |  6 
--
   3 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c 
b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
index 5e83bbf022eb..d2f983bf0a9f 100644
--- a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
+++ b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
@@ -34,25 +34,16 @@ SerialPortGetDivisor (
 UINT32  SerialBaudRate

   )

   {

-  UINT64  BaseClockRate;

+  UINT32  BaseClockRate;

 UINT32  Divisor;



-  //

-  // On the Raspberry Pi, the clock to use for the 16650-compatible UART

-  // is the base clock divided by the 12.12 fixed point VPU clock divisor.

-  //

-  BaseClockRate = (UINT64)PcdGet32 (PcdSerialClockRate);

-#if (RPI_MODEL == 4)

-  Divisor = MmioRead32(BCM2836_CM_BASE + BCM2836_CM_VPU_CLOCK_DIVISOR) & 
0xFF;

-  if (Divisor != 0)

-BaseClockRate = (BaseClockRate << 12) / Divisor;

-#endif

+  BaseClockRate = PcdGet32 (PcdSerialClockRate);



 //

 // As per the BCM2xxx datasheets:

 // baudrate = system_clock_freq / (8 * (divisor + 1)).

 //

-  Divisor = (UINT32)BaseClockRate / (SerialBaudRate * 8);

+  Divisor = BaseClockRate / (SerialBaudRate * 8);

 if (Divisor != 0) {

   Divisor--;

 }

diff --git 
a/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S 
b/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
index 58351e4fb8cc..7008aaf8aa4c 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
+++ b/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
@@ -85,13 +85,11 @@ ASM_FUNC (ArmPlatformPeiBootAction)
   adr x2, mBoardRevision

   str w0, [x2]



-#if (RPI_MODEL == 3)

   run .Lclkinfo_buffer



   ldr w0, .Lfrequency

   adr x2, _gPcd_BinaryPatch_PcdSerialClockRate

   str w0, [x2]

-#endif



   ret



@@ -135,7 +133,6 @@ ASM_FUNC (ArmPlatformPeiBootAction)
   .long   0   // end tag

   .set.Lrevinfo_size, . - .Lrevinfo_buffer



-#if (RPI_MODEL == 3)

   .align  4

   .Lclkinfo_buffer:

   .long   .Lclkinfo_size

@@ -148,7 +145,6 @@ ASM_FUNC (ArmPlatformPeiBootAction)
   .long   0   // frequency

   .long   0   // end tag

   .set.Lclkinfo_size, . - .Lclkinfo_buffer

-#endif



   //UINTN

   //ArmPlatformGetPrimaryCoreMpId (

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 2c05c31118d2..ff802d8347ea 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -429,7 +429,6 @@ [PcdsFixedAtBuild.common]
 gArmPlatformTokenSpaceGuid.PL011UartClkInHz|4800

 gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio|TRUE

 gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|4

-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate|10

 gEfiMdeModulePkgTokenSpaceGuid.PcdSerialFifoControl|0x27

 gEfiMdeModulePkgTokenSpaceGuid.PcdSerialExtendedTxFifoSize|8

 gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200

@@ -465,6 +464,9 @@ [PcdsFixedAtBuild.common]
 gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVendor|L"EDK2"

 gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE



+[PcdsPatchableInModule]

+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate|5

+

   [PcdsDynamicHii.common.DEFAULT]



 #

@@ -621,7 +623,7 @@ [Components.common]
 MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf

 MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {

   

-  
SerialPortLib|Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.inf

+  
SerialPortLib|Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortDxeLib.inf

 }

 Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.inf

 EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.inf



Reviewed-by: Pete Batard 
Tested-by: Pete Batard 


Thanks Pete.

Could anyone get me a version of this patch that is not whitespace
mangled? This one does not apply with 'git am'



Done.

The version I sent is the one I applied & tested after I ran it throu

[edk2-devel] [edk2-platforms][PATCH v2 1/1] Platform/RaspberryPi: Fix mini UART clock divisor calculation

[Pete Batard]

From: Mario Bălănică 

The VPU clock divisor has changed in this commit: 
https://github.com/raspberrypi/firmware/commit/1e5456a,
thus breaking the mini UART clock divisor calculation on the Pi 4.

Fix this by reading the core clock from the mailbox instead.

Signed-off-by: Mario Bălănică 
---
 Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c   | 15 
+++
 Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S |  4 
 Platform/RaspberryPi/RPi4/RPi4.dsc   |  6 
--
 3 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c 
b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
index 5e83bbf022eb..d2f983bf0a9f 100644
--- a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
+++ b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
@@ -34,25 +34,16 @@ SerialPortGetDivisor (
   UINT32  SerialBaudRate
 )
 {
-  UINT64  BaseClockRate;
+  UINT32  BaseClockRate;
   UINT32  Divisor;
 
-  //
-  // On the Raspberry Pi, the clock to use for the 16650-compatible UART
-  // is the base clock divided by the 12.12 fixed point VPU clock divisor.
-  //
-  BaseClockRate = (UINT64)PcdGet32 (PcdSerialClockRate);
-#if (RPI_MODEL == 4)
-  Divisor = MmioRead32(BCM2836_CM_BASE + BCM2836_CM_VPU_CLOCK_DIVISOR) & 
0xFF;
-  if (Divisor != 0)
-BaseClockRate = (BaseClockRate << 12) / Divisor;
-#endif
+  BaseClockRate = PcdGet32 (PcdSerialClockRate);
 
   //
   // As per the BCM2xxx datasheets:
   // baudrate = system_clock_freq / (8 * (divisor + 1)).
   //
-  Divisor = (UINT32)BaseClockRate / (SerialBaudRate * 8);
+  Divisor = BaseClockRate / (SerialBaudRate * 8);
   if (Divisor != 0) {
 Divisor--;
   }
diff --git 
a/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S 
b/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
index 58351e4fb8cc..7008aaf8aa4c 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
+++ b/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
@@ -85,13 +85,11 @@ ASM_FUNC (ArmPlatformPeiBootAction)
 adr x2, mBoardRevision
 str w0, [x2]
 
-#if (RPI_MODEL == 3)
 run .Lclkinfo_buffer
 
 ldr w0, .Lfrequency
 adr x2, _gPcd_BinaryPatch_PcdSerialClockRate
 str w0, [x2]
-#endif
 
 ret
 
@@ -135,7 +133,6 @@ ASM_FUNC (ArmPlatformPeiBootAction)
 .long   0   // end tag
 .set.Lrevinfo_size, . - .Lrevinfo_buffer
 
-#if (RPI_MODEL == 3)
 .align  4
 .Lclkinfo_buffer:
 .long   .Lclkinfo_size
@@ -148,7 +145,6 @@ ASM_FUNC (ArmPlatformPeiBootAction)
 .long   0   // frequency
 .long   0   // end tag
 .set.Lclkinfo_size, . - .Lclkinfo_buffer
-#endif
 
 //UINTN
 //ArmPlatformGetPrimaryCoreMpId (
diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 2c05c31118d2..ff802d8347ea 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -429,7 +429,6 @@ [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PL011UartClkInHz|4800
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio|TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|4
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate|10
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialFifoControl|0x27
   gEfiMdeModulePkgTokenSpaceGuid.PcdSerialExtendedTxFifoSize|8
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
@@ -465,6 +464,9 @@ [PcdsFixedAtBuild.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVendor|L"EDK2"
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
 
+[PcdsPatchableInModule]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate|5
+
 [PcdsDynamicHii.common.DEFAULT]
 
   #
@@ -621,7 +623,7 @@ [Components.common]
   MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
   MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
 
-  
SerialPortLib|Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.inf
+  
SerialPortLib|Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortDxeLib.inf
   }
   Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.inf
   EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.inf
-- 2.29.2.windows.2


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73844): https://edk2.groups.io/g/devel/message/73844
Mute This Topic: https://groups.io/mt/81890065/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

[Pete Batard]

On 2021.04.08 06:58, Jeremy Linton wrote:

Bridge devices should be marked as producers so that their
children can consume the resources. In linux if this isn't
true then the translation gets ignored and the DMA values
are incorrect. This fixes DMA on all the devices that
need a translation.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/AcpiTables/Dsdt.asl | 2 +-
  Platform/RaspberryPi/AcpiTables/Emmc.asl | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index d116f965e1..32cd5fc9f9 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -205,7 +205,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
  // Only the first GB is available.

  // Bus 0xC000 -> CPU 0x.

  //

-QWordMemory (ResourceConsumer,

+QWordMemory (ResourceProducer,

,

MinFixed,

MaxFixed,

diff --git a/Platform/RaspberryPi/AcpiTables/Emmc.asl 
b/Platform/RaspberryPi/AcpiTables/Emmc.asl
index 179dd3ecdb..0fbc2a79ea 100644
--- a/Platform/RaspberryPi/AcpiTables/Emmc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Emmc.asl
@@ -32,7 +32,7 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4EMMC", 2)
}

  


Name (_DMA, ResourceTemplate() {

-QWordMemory (ResourceConsumer,

+QWordMemory (ResourceProducer,

    ,

MinFixed,

MaxFixed,



Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73836): https://edk2.groups.io/g/devel/message/73836
Mute This Topic: https://groups.io/mt/81935645/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/3] Platform/RaspberryPi/AcpiTables: Add further named components

[Pete Batard]

On 2021.04.08 06:58, Jeremy Linton wrote:

Add some additional IORT nodes for the USB & EMMC devices, realistically
we probably only need to have a single node with the lowest AddressSizeLimit
but this is conceptually "cleaner" should anyone actually try and use these
values rather than the _DMA provided ones.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/AcpiTables/Iort.aslc | 44 ++-
  1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Iort.aslc 
b/Platform/RaspberryPi/AcpiTables/Iort.aslc
index 00720194bb..810307ae37 100644
--- a/Platform/RaspberryPi/AcpiTables/Iort.aslc
+++ b/Platform/RaspberryPi/AcpiTables/Iort.aslc
@@ -20,6 +20,8 @@ typedef struct {
  typedef struct {

EFI_ACPI_6_0_IO_REMAPPING_TABLE  Iort;

RPI4_NC_NODE NamedCompNode;

+  RPI4_NC_NODE NamedCompNode2;

+  RPI4_NC_NODE NamedCompNode3;

  } RPI4_IO_REMAPPING_STRUCTURE;

  


  STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {

@@ -27,7 +29,7 @@ STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
  ACPI_HEADER (EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE,

   RPI4_IO_REMAPPING_STRUCTURE,

   EFI_ACPI_IO_REMAPPING_TABLE_REVISION),

-1,  // NumNodes

+3,  // NumNodes

  sizeof (EFI_ACPI_6_0_IO_REMAPPING_TABLE),   // NodeOffset

  0   // Reserved

}, {

@@ -50,6 +52,46 @@ STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
  }, {

"\\_SB_.SCB0.XHC0"// ObjectName

  }

+  }, {

+// gpu/dwc usb named component node

+{

+  {

+EFI_ACPI_IORT_TYPE_NAMED_COMP,  // Type

+sizeof (RPI4_NC_NODE),  // Length

+0x0,// Revision

+0x0,// Reserved

+0x0,// NumIdMappings

+0x0,// IdReference

+  },

+  0x0,  // Flags

+  0x0,  // CacheCoherent

+  0x0,  // AllocationHints

+  0x0,  // Reserved

+  0x0,  // MemoryAccessFlags

+  30,   // AddressSizeLimit

+}, {

+  "\\_SB_.GDV0.USB0"// ObjectName

+}

+  }, {

+// emmc2 named component node

+{

+  {

+EFI_ACPI_IORT_TYPE_NAMED_COMP,  // Type

+sizeof (RPI4_NC_NODE),  // Length

+0x0,// Revision

+0x0,// Reserved

+0x0,// NumIdMappings

+0x0,// IdReference

+  },

+  0x0,  // Flags

+  0x0,  // CacheCoherent

+  0x0,  // AllocationHints

+  0x0,  // Reserved

+  0x0,  // MemoryAccessFlags

+  30,   // AddressSizeLimit

+}, {

+  "\\_SB_.GDV1.SDC3"// ObjectName

+}

}

  };

  



Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73835): https://edk2.groups.io/g/devel/message/73835
Mute This Topic: https://groups.io/mt/81935644/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/3] Platform/RaspberryPi/Acpitables: Enable Arasan hispeed mode

[Pete Batard]

On 2021.04.08 06:58, Jeremy Linton wrote:

The arasan caps registers are no longer being overridden by
the brcm iproc driver, so we should be assuring that the
"High Speed Support" bit 21 is set in the capability
register. This significantly improves the wifi perf
using linux.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/AcpiTables/Sdhc.asl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Sdhc.asl 
b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
index 0430ab7d2d..42776e33bb 100644
--- a/Platform/RaspberryPi/AcpiTables/Sdhc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
@@ -52,7 +52,7 @@ Device (SDC1)
Name (_DSD, Package () {

  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),

  Package () {

-  Package () { "sdhci-caps", 0x0100fa81 },

+  Package () { "sdhci-caps", 0x0120fa81 },

  }

})

  



Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73834): https://edk2.groups.io/g/devel/message/73834
Mute This Topic: https://groups.io/mt/81935643/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH v2 1/1] Platform/RaspberryPi: Fix mini UART clock divisor calculation

[Pete Batard]

On 2021.04.06 15:04, Mario Bălănică wrote:

The VPU clock divisor has changed in this commit:
https://github.com/raspberrypi/firmware/commit/1e5456a,
thus breaking the mini UART clock divisor calculation on the Pi 4.

Fix this by reading the core clock from the mailbox instead.

Signed-off-by: Mario Bălănică 
---
  Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c   | 15 
+++
  Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S |  4 
  Platform/RaspberryPi/RPi4/RPi4.dsc   |  6 
--
  3 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c 
b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
index 5e83bbf022eb..d2f983bf0a9f 100644
--- a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
+++ b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
@@ -34,25 +34,16 @@ SerialPortGetDivisor (
UINT32  SerialBaudRate

  )

  {

-  UINT64  BaseClockRate;

+  UINT32  BaseClockRate;

UINT32  Divisor;

  


-  //

-  // On the Raspberry Pi, the clock to use for the 16650-compatible UART

-  // is the base clock divided by the 12.12 fixed point VPU clock divisor.

-  //

-  BaseClockRate = (UINT64)PcdGet32 (PcdSerialClockRate);

-#if (RPI_MODEL == 4)

-  Divisor = MmioRead32(BCM2836_CM_BASE + BCM2836_CM_VPU_CLOCK_DIVISOR) & 
0xFF;

-  if (Divisor != 0)

-BaseClockRate = (BaseClockRate << 12) / Divisor;

-#endif

+  BaseClockRate = PcdGet32 (PcdSerialClockRate);

  


//

// As per the BCM2xxx datasheets:

// baudrate = system_clock_freq / (8 * (divisor + 1)).

//

-  Divisor = (UINT32)BaseClockRate / (SerialBaudRate * 8);

+  Divisor = BaseClockRate / (SerialBaudRate * 8);

if (Divisor != 0) {

  Divisor--;

}

diff --git 
a/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S 
b/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
index 58351e4fb8cc..7008aaf8aa4c 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
+++ b/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
@@ -85,13 +85,11 @@ ASM_FUNC (ArmPlatformPeiBootAction)
  adr x2, mBoardRevision

  str w0, [x2]

  


-#if (RPI_MODEL == 3)

  run .Lclkinfo_buffer

  


  ldr w0, .Lfrequency

  adr x2, _gPcd_BinaryPatch_PcdSerialClockRate

  str w0, [x2]

-#endif

  


  ret

  


@@ -135,7 +133,6 @@ ASM_FUNC (ArmPlatformPeiBootAction)
  .long   0   // end tag

  .set.Lrevinfo_size, . - .Lrevinfo_buffer

  


-#if (RPI_MODEL == 3)

  .align  4

  .Lclkinfo_buffer:

  .long   .Lclkinfo_size

@@ -148,7 +145,6 @@ ASM_FUNC (ArmPlatformPeiBootAction)
  .long   0   // frequency

  .long   0   // end tag

  .set.Lclkinfo_size, . - .Lclkinfo_buffer

-#endif

  


  //UINTN

  //ArmPlatformGetPrimaryCoreMpId (

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 2c05c31118d2..ff802d8347ea 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -429,7 +429,6 @@ [PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PL011UartClkInHz|4800

gEfiMdeModulePkgTokenSpaceGuid.PcdSerialUseMmio|TRUE

gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|4

-  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate|10

gEfiMdeModulePkgTokenSpaceGuid.PcdSerialFifoControl|0x27

gEfiMdeModulePkgTokenSpaceGuid.PcdSerialExtendedTxFifoSize|8

gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200

@@ -465,6 +464,9 @@ [PcdsFixedAtBuild.common]
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVendor|L"EDK2"

gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE

  


+[PcdsPatchableInModule]

+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate|5

+

  [PcdsDynamicHii.common.DEFAULT]

  


#

@@ -621,7 +623,7 @@ [Components.common]
MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf

MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {

  

-  
SerialPortLib|Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.inf

+  
SerialPortLib|Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortDxeLib.inf

}

Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.inf

EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.inf



Reviewed-by: Pete Batard 
Tested-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73833): https://edk2.groups.io/g/devel/message/73833
Mute This Topic: https://groups.io/mt/81890065/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi: Fix mini UART baud divisor calculation

[Pete Batard]

Hi Mario,

Please re-send a v2 with a commit message that explains the issue that 
is being fixed. Thanks.


For the record, I ran some tests that show that the divisor was changed 
from 1 to 2 with the latest Pi Foundation firmware (which is confirmed 
by the fact that if you switch your baudrate from 115200 to 57600, 
you'll get the expected output).


I'm not sure what game the Pi Foundation are playing at this stage, coz 
they sure don't seem to be following any official logic with how they 
actually set the serial clock, and our attempts at second guessing that 
logic are no longer working. So I guess the best we can do is go with 
whatever gets us output for the latest firmware, and hope they're not 
going to break that anytime soon (which is still better than the TF-A 
approach, where they got so fed up with this cat and mouse game that 
they dropped UART initialization altogether [1])


Regards,

/Pete

[1] 
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/plat/rpi?h=v2.3=0eda713b9bd65222155900aacf3a67805351f88f


On 2021.04.03 23:45, Mario Bălănică wrote:
Okay, I've tested the patch with the firmware from the commit mentioned 
above and it doesn't work. The VPU clock divisor bit needs 
PcdSerialClockRate to be set to 1 GHz (so that the quotient becomes 
equal to the core clock).


The mailbox on the other hand always returns 200 MHz for the core clock. 
This is definitely a bug, which got fixed it in a later commit.


There isn't any reliable way to support the firmwares with a broken 
mailbox interface as well in this case, and I really doubt anyone would 
want to use them with the UEFI in the first place. Your build scripts 
always include the latest version.


I can resend the patch with a more detailed commit message if you wish.




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73719): https://edk2.groups.io/g/devel/message/73719
Mute This Topic: https://groups.io/mt/81808942/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi: Fix mini UART baud divisor calculation

[Pete Batard]

On 2021.04.03 17:55, Mario Bălănică wrote:
Can you tell me which commit in the firmware repo breaks the mini UART 
divisor calculation, so that I can test the final changes against it too?


That would be one of the start4.elf/fixup4.dat combination around the 
time when the commit that added the divisor was introduced. You should 
be able to find that commit through git blame and then work your way down.


If you need more information than that, I can try to dig it up, but it 
won't happen until at least Tuesday.


Regards,

/Pete


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73674): https://edk2.groups.io/g/devel/message/73674
Mute This Topic: https://groups.io/mt/81808942/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi: Fix mini UART baud divisor calculation

[Pete Batard]

On 2021.04.03 17:15, Mario Bălănică wrote:

 > -#if (RPI_MODEL == 4)
 > -  Divisor = MmioRead32(BCM2836_CM_BASE +
BCM2836_CM_VPU_CLOCK_DIVISOR) & 0xFF;
 > -  if (Divisor != 0)
 > -    BaseClockRate = (BaseClockRate << 12) / Divisor;
 > -#endif

Keeping this doesn't interfere with the rest of the patch. I've removed 
it only because it's useless on the latest firmware.


Okay, then can you please send a v2 of your patch that leaves this in? I 
believe this divisor arithmetic is still needed with older versions of 
start4.elf, and we may have people using choosing to use an older 
start4.elf for whatever reason.


In general, if it doesn't interfere with your proposal, it's better to 
leave existing code in, as overzealous code removal may have unintended 
consequences, unless you are confident that the code is superfluous.


Also make sure you update the commit message to mention what issue you 
are fixing.


Thanks,

/Pete


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73671): https://edk2.groups.io/g/devel/message/73671
Mute This Topic: https://groups.io/mt/81808942/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi: Fix mini UART baud divisor calculation

[Pete Batard]

On 2021.04.03 16:17, Mario Bălănică wrote:
I've submitted this patch because the mini UART serial console produces 
garbage since UEFI v1.25 (due to the wrong baud rate).


OK.

When you fix something like this, please mention that there was a 
regression that requires fixing, in the commit message.


It has been tested on the firmware shipped with UEFI v1.24 and it works 
fine. I don't see any reason to test it on older versions than this.


Well, my worry is that you are removing this part:

> -#if (RPI_MODEL == 4)
> -  Divisor = MmioRead32(BCM2836_CM_BASE + 
BCM2836_CM_VPU_CLOCK_DIVISOR) & 0xFF;

> -  if (Divisor != 0)
> -BaseClockRate = (BaseClockRate << 12) / Divisor;
> -#endif

which was added due to serial issues with older versions of the firmware 
(much older than the one included in 1.24), to make it compatible with 
versions of start4.elf where the Pi Foundation had suffled the serial 
clock rates yet again.


I guess if we can't make both newer versions and these older versions 
work with the same code, we have to stick with what works for newer 
ones. But I'm still wondering what changed in the Pi firmware to make 
applying this divisor computation fail, especially as this was supposed 
to alleviate the precise serial baudrate issue you are trying to fix.



The core clock is not fixed. I've made PcdSerialClockRate patchable here:

@@ -465,6 +464,9 @@ [PcdsFixedAtBuild.common]
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVendor|L"EDK2"
gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE

+[PcdsPatchableInModule]
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate|5
+

500 MHz is the default clock rate (assuming it hasn't been changed in 
config.txt).
The PCD gets patched in both the PEI and DXE phases to the value read 
from mailbox.


Yeah, I had missed that.

I suppose we can go with what you suggest. But I'm still worried that 
the Pi Foundation are going to shuffle their clocks again in a future 
firmware, and that we'll be modifying this code yet again, as your patch 
is pretty much reverting the code to what we used to have... until we 
found it got broken by a newly introduced Pi Foundation firmware.


Regards,

/Pete


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73669): https://edk2.groups.io/g/devel/message/73669
Mute This Topic: https://groups.io/mt/81808942/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi: Fix mini UART baud divisor calculation

[Pete Batard]

Hi Mario,

On 2021.04.03 13:47, Mario Bălănică wrote:

It works with the old firmware as well.


Are you sure of this? You may have to go quite far back to find 
start4.elf versions where this might not work...


The whole reason behind reading the base clock and divisor from MMIO, 
rather than use a fixed base clock, is actually because we got stung 
with the Raspberry Pi Foundation changing start4.elf on a whim, and 
thereby breaking the serial divisor computation.


So we moved away from using the approach proposed in this patch (i.e. 
assuming a fixed PcdSerialClockRate) as we found that it didn't work for 
all cases.


I'm also wondering why there are no mentions of clock rates in the 
firmware commit message you linked to. Do you have other information, 
from the Raspberry Pi Foundation developers, where they indicate that 
they plan to keep the base clock for miniUART fixed to 500 MHz from now on?


But more importantly, I'd like to understand the issue we are trying to 
solve with this patch. Does the current serial computation create 
issues? Because, if that is not the case, I think I'd rather keep the 
dynamic approach of reading the base clock and VPU divisor, since it 
might be more future-proof than relying on a fixed value provided in the 
.dsc.


Especially, we don't know if the Raspberry Pi Foundation may not 
introduce a new Rapsberry Pi 4 revision tomorrow (like they did with the 
Pi400), where the fixed 500 MHz base clock rate would not apply...


So I'd like to understand better how this patch came about, and what it 
is we are trying to achieve with it.


Regards,

/Pete



sâm., 3 apr. 2021, 10:36 Ard Biesheuvel > a scris:


On Fri, 2 Apr 2021 at 19:52, Mario Bălănică
mailto:mariobalanic...@gmail.com>> wrote:
 >
 > The baud rate divisor calculation for mini UART on BCM2711 is the
same
 > as on older models since this commit:
 > https://github.com/raspberrypi/firmware/commit/1e5456a

 >
 > Signed-off-by: Mario Bălănică mailto:mariobalanic...@gmail.com>>

Doesn't this make the new build incompatible with the old firmware? Is
there a way to support both?


 > ---
 > 
Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c 
  | 15 +++
 > 
Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S

|  4 
 >  Platform/RaspberryPi/RPi4/RPi4.dsc 
      |  6 --

 >  3 files changed, 7 insertions(+), 18 deletions(-)
 >
 > diff --git
a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
 > index 5e83bbf022eb..d2f983bf0a9f 100644
 > ---
a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
 > +++
b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
 > @@ -34,25 +34,16 @@ SerialPortGetDivisor (
 >    UINT32  SerialBaudRate
 >  )
 >  {
 > -  UINT64              BaseClockRate;
 > +  UINT32              BaseClockRate;
 >    UINT32              Divisor;
 >
 > -  //
 > -  // On the Raspberry Pi, the clock to use for the
16650-compatible UART
 > -  // is the base clock divided by the 12.12 fixed point VPU
clock divisor.
 > -  //
 > -  BaseClockRate = (UINT64)PcdGet32 (PcdSerialClockRate);
 > -#if (RPI_MODEL == 4)
 > -  Divisor = MmioRead32(BCM2836_CM_BASE +
BCM2836_CM_VPU_CLOCK_DIVISOR) & 0xFF;
 > -  if (Divisor != 0)
 > -    BaseClockRate = (BaseClockRate << 12) / Divisor;
 > -#endif
 > +  BaseClockRate = PcdGet32 (PcdSerialClockRate);
 >
 >    //
 >    // As per the BCM2xxx datasheets:
 >    // baudrate = system_clock_freq / (8 * (divisor + 1)).
 >    //
 > -  Divisor = (UINT32)BaseClockRate / (SerialBaudRate * 8);
 > +  Divisor = BaseClockRate / (SerialBaudRate * 8);
 >    if (Divisor != 0) {
 >      Divisor--;
 >    }
 > diff --git
a/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
b/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
 > index 58351e4fb8cc..7008aaf8aa4c 100644
 > ---
a/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
 > +++
b/Platform/RaspberryPi/Library/PlatformLib/AArch64/RaspberryPiHelper.S
 > @@ -85,13 +85,11 @@ ASM_FUNC (ArmPlatformPeiBootAction)
 >      adr     x2, mBoardRevision
 >      str     w0, [x2]
 >
 > -#if (RPI_MODEL == 3)
 >      run     .Lclkinfo_buffer
 >
 >      ldr     w0, .Lfrequency
 >      adr     x2, _gPcd_BinaryPatch_PcdSerialClockRate
 >      str     w0, [x2]
 > -#endif
 >
 >      ret
 >
 > @@ -135,7 +133,6 @@ ASM_FUNC (ArmPlatformPeiBootAction)
 >      .long   0                           // 

Re: [edk2-devel] [PATCH v2 1/2] Platform/RaspberryPi: Dynamically build UARTs info in ACPI

[Pete Batard]

Hi Sunny,

I understand that you are going to re-send these patches due to e-mail 
mangling, but let me add a few of notes that might help you as you are 
doing that.


First of all, your patch series was missing a cover letter (there should 
have been a [PATCH v2 0/2]), that doesn't get applied, but that 
describes the series or the changes applied between 2 revisions.


This isn't a big deal for a series that has only 2 patches, but it seems 
to indicate that you missed some steps from Laszlo's helpful guide on 
how to configure your environment to send patches to EDK2, which you can 
find at:


https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers

Especially, you should have run the command:

git config format.coverletter true

Now, with regards to patch mangling, as you may be able to see, what I 
got is not as bad as what you seem to have been getting. In fact, 
barring a few issues (which I am pointing out below) your patch is 
almost usable, even with the double line feeds I am seeing from my 
e-mail client (because that's actually how I currently receive about 
half the patches that are posted on this list anyway, so much so that I 
have had to craft a quick script to remove them).


There are however some issues, that actually prevent your patch from 
applying properly, and, while I'm at it, I also added a few comments 
about some extra lines you added, that you should be able to fix for 
your next submission:


On 2021.03.24 09:45, Sunny Wang wrote:

Changes:

   1. Add code to ConfigDxe driver and AcpiTables module to dynamically

  build either Mini UART or PL011 UART info in ACPI. This fixes the

  issue discussed in https://github.com/pftf/RPi4/issues/118.

   2. Cleanup by moving duplicate Debug Port 2 table related defines and

  structures to a newly created header file (RpiDebugPort2Table.h).



Testing Done:

   - Booted to UEFI shell and use acpiview command to check the result of

 the different UART settings in config.txt (enabling either Mini UART

 or PL011) and SPCR, DBG2 tables and device BTH0 are dynamically

 changed as expected.



Cc: Samer El-Haj-Mahmoud 

Cc: Sami Mujawar 

Cc: Jeremy Linton 

Cc: Pete Batard 

Cc: Ard Biesheuvel 

Signed-off-by: Sunny Wang 

---

  .../RaspberryPi/AcpiTables/AcpiTables.inf |   9 +-

  .../RaspberryPi/AcpiTables/Dbg2MiniUart.aslc  |  82 

  .../AcpiTables/{Dbg2.aslc => Dbg2Pl011.aslc}  | 187 -

  .../RaspberryPi/AcpiTables/SpcrMiniUart.aslc  |  92 +

  .../AcpiTables/{Spcr.aslc => SpcrPl011.aslc}  | 188 +-

  Platform/RaspberryPi/AcpiTables/Uart.asl  |  10 +-

  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 107 +-

  .../IndustryStandard/RpiDebugPort2Table.h |  34 

  8 files changed, 497 insertions(+), 212 deletions(-)

  create mode 100644 Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc

  rename Platform/RaspberryPi/AcpiTables/{Dbg2.aslc => Dbg2Pl011.aslc} (72%)

  create mode 100644 Platform/RaspberryPi/AcpiTables/SpcrMiniUart.aslc

  rename Platform/RaspberryPi/AcpiTables/{Spcr.aslc => SpcrPl011.aslc} (87%)

  create mode 100644 
Platform/RaspberryPi/Include/IndustryStandard/RpiDebugPort2Table.h



diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf

index d3363a76a1..fc8e927138 100644

--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf

+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf

@@ -2,7 +2,7 @@

  #

  #  ACPI table data and ASL sources required to boot the platform.

  #

-#  Copyright (c) 2019, ARM Limited. All rights reserved.

+#  Copyright (c) 2019-2021, ARM Limited. All rights reserved.

  #  Copyright (c) 2017, Andrey Warkentin 

  #  Copyright (c) Microsoft Corporation. All rights reserved.

  #

@@ -28,12 +28,14 @@

Emmc.asl

Madt.aslc

Fadt.aslc

-  Dbg2.aslc

+  Dbg2MiniUart.aslc

+  Dbg2Pl011.aslc

Gtdt.aslc

Iort.aslc

Dsdt.asl

Csrt.aslc

-  Spcr.aslc

+  SpcrMiniUart.aslc

+  SpcrPl011.aslc

Pptt.aslc

SsdtThermal.asl




For the patch to be applicable, there should have been an additional 
space on the line above.

In other words, is should be ">  " and not just "> ".



@@ -71,3 +73,4 @@




Same here, and for about 4-5 more instances further down, that I'm not 
going to document.


If using 'git format-patch' and 'git send-email' as documented in 
Laszlo's guide, I would expect these to go away.




  [BuildOptions]

GCC:*_*_*_ASL_FLAGS   = -vw3133 -vw3150

+


This doesn't have to do with patch mangling, but you are adding an 
unwarranted extra line here. Can you please remove it from your next 
submission?




diff --git a/Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc 
b/Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc

new file mode 100644

index 00..c83b978731

--- /dev/null

Re: [edk2-devel] [edk2-platforms] [patch V2 19/35] Platform/RaspberryPi: Consume MdeLibs.dsc.inc for RegisterFilterLib

[Pete Batard]

On 2021.03.22 08:53, Dandan Bi wrote:

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246

MdeLibs.dsc.inc was added for some basic/default library
instances provided by MdePkg and RegisterFilterLibNull Library
was also added into it as the first version of MdeLibs.dsc.inc.

So update platform dsc to consume MdeLibs.dsc.inc for
RegisterFilterLibNull which will be consumed by IoLib and BaseLib.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pete Batard 
Signed-off-by: Dandan Bi 
---
  Platform/RaspberryPi/RPi3/RPi3.dsc | 4 +++-
  Platform/RaspberryPi/RPi4/RPi4.dsc | 4 +++-
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc 
b/Platform/RaspberryPi/RPi3/RPi3.dsc
index 107cbda297..969d723af1 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -1,10 +1,10 @@
  # @file
  #
  #  Copyright (c) 2011 - 2020, ARM Limited. All rights reserved.
  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
-#  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  #  Copyright (c) 2017 - 2018, Andrei Warkentin 
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
  ##
@@ -53,10 +53,12 @@ [Defines]
  #
  # Library Class section - list of all Library Classes needed by this Platform.
  #
  

  [LibraryClasses.common]
+  !include MdePkg/MdeLibs.dsc.inc
+
  !if $(TARGET) == RELEASE
DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
  !else
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
  !endif
diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index e0fad6f744..ef1224b1f7 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -1,10 +1,10 @@
  # @file
  #
  #  Copyright (c) 2011 - 2020, ARM Limited. All rights reserved.
  #  Copyright (c) 2017 - 2018, Andrei Warkentin 
-#  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
  ##
@@ -51,10 +51,12 @@ [Defines]
  #
  # Library Class section - list of all Library Classes needed by this Platform.
  #
  

  [LibraryClasses.common]
+  !include MdePkg/MdeLibs.dsc.inc
+
  !if $(TARGET) == RELEASE
DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
  !else
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
  !endif



Reviewed-by: Pete Batard 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#73140): https://edk2.groups.io/g/devel/message/73140
Mute This Topic: https://groups.io/mt/81519803/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Platform/RaspberryPi: Dynamically build UARTs info in ACPI

[Pete Batard]

Hi Sunny,

Thanks a lot for submitting this patch!

This is something that has been on the Raspberry Pi platform TODO list 
for some time, so your contribution is much appreciated.


Please find 4 comments inline:

On 2021.03.06 09:24, Sunny Hsuan-Wen Wang wrote:

Changes:

   1. Add code to ConfigDxe driver and AcpiTables module to dynamically

  build either Mini UART or PL011 UART info in ACPI. This fixes the

  issue discussed in https://github.com/pftf/RPi4/issues/118.

   2. Merge changes in edk2-platforms-raspberrypi-pl011-bth-noflow.diff

  in https://github.com/worproject/RPi-Bluetooth-Testing/

  for enabling Bluetooth and serial port (Mini UART) in Windows OS.

   3. Cleanup by moving duplicate Debug Port 2 table related defines and

  structures to a newly created header file (RpiDebugPort2Table.h).


Ideally, I would prefer if 1-3 and 2 were submitted as separate patches 
in a series, as one can consider that the ACPI assigning of the 
Spcr/Dbg2 tables is independent of the Bluetooth related changes.


For instance, regardless of Bluetooth usage, one of course wants the 
serial ports used by Windows to match the ones defined in config.txt. So 
I would say that we have at least two separate functional changes in 
this patch, that should probably be made more explicit by splitting them 
into separare commits.



Testing Done:

   - Booted to UEFI shell and use acpiview command to check the result of

 the different UART settings in config.txt (enabling either Mini UART

 or PL011) and SPCR, DBG2 tables and device BTH0 are dynamically

 changed as expected.

   - Successfully booted Windows 10 (20279.1) on SD (made by WOR) with

 the RPi-Windows-Drivers release ver 0.5 downloaded from

 https://github.com/worproject/RPi-Windows-Drivers/releases

 and checked that both Bluetooth and serial port (Mini UART) can

 work fine.



Cc: Samer El-Haj-Mahmoud 

Cc: Pete Batard 

Cc: Ard Biesheuvel 

Cc: Leif Lindholm 

Signed-off-by: Sunny Hsuan-Wen Wang 

---

  .../RaspberryPi/AcpiTables/AcpiTables.inf |   7 +-

  .../RaspberryPi/AcpiTables/Dbg2MiniUart.aslc  |  82 

  .../AcpiTables/{Dbg2.aslc => Dbg2Pl011.aslc}  | 187 -

  .../RaspberryPi/AcpiTables/SpcrMiniUart.aslc  |  92 +

  .../AcpiTables/{Spcr.aslc => SpcrPl011.aslc}  | 189 +-

  Platform/RaspberryPi/AcpiTables/Uart.asl  |  18 +-

  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 123 +++-

  .../IndustryStandard/RpiDebugPort2Table.h |  33 +++

  8 files changed, 516 insertions(+), 215 deletions(-)

  create mode 100644 Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc

  rename Platform/RaspberryPi/AcpiTables/{Dbg2.aslc => Dbg2Pl011.aslc} (73%)

  create mode 100644 Platform/RaspberryPi/AcpiTables/SpcrMiniUart.aslc

  rename Platform/RaspberryPi/AcpiTables/{Spcr.aslc => SpcrPl011.aslc} (88%)

  create mode 100644 
Platform/RaspberryPi/Include/IndustryStandard/RpiDebugPort2Table.h



diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf

index d2cce074e5..6c08cacbb3 100644

--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf

+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf

@@ -2,6 +2,7 @@

  #

  #  ACPI table data and ASL sources required to boot the platform.

  #

+#  Copyright (c) 2021, Sunny Hsuan-Wen Wang 

  #  Copyright (c) 2019, ARM Limited. All rights reserved.

  #  Copyright (c) 2017, Andrey Warkentin 

  #  Copyright (c) Microsoft Corporation. All rights reserved.

@@ -27,12 +28,14 @@

AcpiTables.h

Madt.aslc

Fadt.aslc

-  Dbg2.aslc

+  Dbg2MiniUart.aslc

+  Dbg2Pl011.aslc

Gtdt.aslc

Iort.aslc

Dsdt.asl

Csrt.aslc

-  Spcr.aslc

+  SpcrMiniUart.aslc

+  SpcrPl011.aslc

Pptt.aslc

SsdtThermal.asl



diff --git a/Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc 
b/Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc

new file mode 100644

index 00..eec4ba1562

--- /dev/null

+++ b/Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc

@@ -0,0 +1,82 @@

+/** @file

+ *

+ *  Debug Port Table (DBG2)

+ *

+ *  Copyright (c) 2021, Sunny Hsuan-Wen Wang 

+ *  Copyright (c) 2019, Pete Batard 

+ *  Copyright (c) 2012-2020, ARM Limited. All rights reserved.

+ *

+ *  SPDX-License-Identifier: BSD-2-Clause-Patent

+ *

+ **/

+

+#include 

+#include 

+#include 

+#include 

+#include 

+

+#include "AcpiTables.h"

+

+#pragma pack(1)

+

+#define RPI_UART_INTERFACE_TYPE 
EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_BCM2835_UART

+#define RPI_UART_BASE_ADDRESS   
BCM2836_MINI_UART_BASE_ADDRESS

+#define RPI_UART_LENGTH 
BCM2836_MINI_UART_LENGTH

+//

+// RPI_UART_STR should match the value used Uart.asl

+//

+#define RPI_UART_STR{ '\\', '_', 'S', 'B', 
'.', 'G', 'D', 'V', '0', '.', 'U', 'R', 'T', 'M

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

 
application can be implemented without platform specific stuff, so it can be 
commonly used by all platforms that need to load a boot image discovered by 
using short-form File Path Media Device Path.




Regards,
Sunny Wang

-Original Message-
From: Laszlo Ersek 
Sent: Wednesday, February 17, 2021 10:26 PM
To: Pete Batard ; Leif Lindholm ; 
devel@edk2.groups.io
Cc: Samer El-Haj-Mahmoud ; Andrei Warkentin (awarken...@vmware.com) 
; Wang, Sunny (HPS SW) ; zhichao@intel.com; ray...@intel.com; Ard 
Biesheuvel ; Andrew Fish ; Michael D Kinney 
; Jian J Wang ; Hao A Wu 
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1] 
MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

On 02/17/21 13:18, Pete Batard wrote:

Hi Leif,

Thanks for trying to resurrect this issue.

At this stage, and despite some initial pushback in the bugzilla
ticket, I believe we can all agree with the consensus that
UefiBootManagerLib is not in fact specs-compliant and therefore needs
to be fixed, one way or another, to make it specs-compliant.

My take on this is that, rather than propose a new patch, I'd much
rather have the current maintainers agree on the course of action to
fix the library (which, as Leif suggests, might very well be to split
the library into a specs-compliant and non-specs-compliant version),
as it would of course be better if the fix came from people who have
better understanding of the ramifications we might face with trying to
correct the current behaviour, and especially, who have knowledge of
the platforms that might be impacted from making the lib specs-compliant.

Especially, I don't think that the patch that I originally submitted
for this, or the additional proposals we made, are still receivable,
as they seem to fall short of fixing the issue in a manner that all
platforms can be happy with. And that is why I'd like to hear from the
maintainers on what their preferred approach would be.


A new Feature PCD could satisfy both sets of platforms, could it not?

(Sorry if the original patch already had such a PCD; I don't remember.)

Of course then we'd have a debate around the DEC default for the new PCD
-- I'd say the default value of the PCD should match the spec-mandated behavior.

I don't recall any specifics, but a bug-compat pattern that's sometimes used is 
this:

   if (BugCompatEnabled) {
 //
 // do the right thing in the wrong place, for legacy platforms' sake
 //
Foo ();
   }

   //
   // Do some stuff.
   //
   Bar ();

   if (!BugCompatEnabled) {
 //
 // do the right thing in the right place, for conformant platforms
 //
Foo ();
   }

Not sure if it applies here.

Thanks
Laszlo



On 2021.02.17 11:42, Leif Lindholm wrote:

Hi Pete, +various

Resurrecting this old thread since Ard pointed out an issue I ran
into myself had already been encountered by Pete.
And the bugzilla ticket (directly below this reply) has had no
relevant progress since August.

Executive summary:
The current UefiBootManagerLib implementation of the PlatformRecovery
path does not notify the EFI_EVENT_GROUP_READY_TO_BOOT event.

The argument has been made that since changing this would affect an
unnamed number of non-public platforms, the behaviour cannot be
changed even though it violates the UEFI specification.

I disagree with that statement. If we want to fork UefiBootManagerLib
into a BrokenLegacyUefiBootManagerLib and an actually correct one,
and have those platforms move to the BrokenLegacy variant, I'm OK
with that.

But using the default version should give specification-compliant
behaviour.

/
      Leif

On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:

Please note that I have created a bug report
(https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address the
non-compliance issue was raised during the course of the discussion
below.

Regards,

/Pete


On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:

I worked with Pete offline on this..

This code seems to be violating the UEFI Spec:

https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de
7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1763


     //
     // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
about to load and execute
     //    the boot option.
     //
     if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
   DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
   BmStopHotkeyService (NULL, NULL);
     } else {
   EfiSignalEventReadyToBoot();
   //
   // Report Status Code to indicate ReadyToBoot was signalled
   //
   REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
(EFI_SOFTWARE_DXE_BS_DRIVER |
EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
   //
   // 4. Repair system through DriverHealth protocol
   //
   BmRepairAllControllers (0);
     }

The UEFI Spec section 3.1.7 clearly states that Boot Options (and
their FilePathList) *shall not* be evaluated prior to the
completion of

Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

Hi Leif,

Thanks for trying to resurrect this issue.

At this stage, and despite some initial pushback in the bugzilla ticket, 
I believe we can all agree with the consensus that UefiBootManagerLib is 
not in fact specs-compliant and therefore needs to be fixed, one way or 
another, to make it specs-compliant.


My take on this is that, rather than propose a new patch, I'd much 
rather have the current maintainers agree on the course of action to fix 
the library (which, as Leif suggests, might very well be to split the 
library into a specs-compliant and non-specs-compliant version), as it 
would of course be better if the fix came from people who have better 
understanding of the ramifications we might face with trying to correct 
the current behaviour, and especially, who have knowledge of the 
platforms that might be impacted from making the lib specs-compliant.


Especially, I don't think that the patch that I originally submitted for 
this, or the additional proposals we made, are still receivable, as they 
seem to fall short of fixing the issue in a manner that all platforms 
can be happy with. And that is why I'd like to hear from the maintainers 
on what their preferred approach would be.


Regards,

/Pete

On 2021.02.17 11:42, Leif Lindholm wrote:

Hi Pete, +various

Resurrecting this old thread since Ard pointed out an issue I ran into
myself had already been encountered by Pete.
And the bugzilla ticket (directly below this reply) has had no
relevant progress since August.

Executive summary:
The current UefiBootManagerLib implementation of the PlatformRecovery
path does not notify the EFI_EVENT_GROUP_READY_TO_BOOT event.

The argument has been made that since changing this would affect an
unnamed number of non-public platforms, the behaviour cannot be
changed even though it violates the UEFI specification.

I disagree with that statement. If we want to fork UefiBootManagerLib
into a BrokenLegacyUefiBootManagerLib and an actually correct one, and
have those platforms move to the BrokenLegacy variant, I'm OK with
that.

But using the default version should give specification-compliant
behaviour.

/
 Leif

On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:

Please note that I have created a bug report
(https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address the
non-compliance issue was raised during the course of the discussion below.

Regards,

/Pete


On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:

I worked with Pete offline on this..

This code seems to be violating the UEFI Spec:

https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1763

//
// 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load 
and execute
//the boot option.
//
if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
  DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
  BmStopHotkeyService (NULL, NULL);
} else {
  EfiSignalEventReadyToBoot();
  //
  // Report Status Code to indicate ReadyToBoot was signalled
  //
  REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
  //
  // 4. Repair system through DriverHealth protocol
  //
  BmRepairAllControllers (0);
}

The UEFI Spec section 3.1.7 clearly states that Boot Options (and their 
FilePathList) *shall not* be evaluated prior to the completion of 
EFI_EVENT_GROUP_READY_TO_BOOT event group processing:

"After all SysPrep variables have been launched and exited, the platform shall 
notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot variables 
with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by 
BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be 
evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group 
processing."

This is a prescriptive language that is stronger than the language in section 
7.1 which defines the ReadyToBoot event group in a general way:

"EFI_EVENT_GROUP_RESET_SYSTEM
This event group is notified by the system when ResetSystem() is invoked and the 
system is about to be reset. The event group is only notified prior to 
ExitBootServices() invocation."

The EDK2 code in the else block above (to call EfiSignalEventReadyToBoot() ) need 
to move before the code that is processing BootOption->FilePath. In fact, why 
is this signaling even a BootManager task? It should be a higher level BDS task 
(after processing SysPrp and before processing Boot options, per the spec). This 
would be somewhere around 
https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea0214498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007
 where SysPrep is processed.

This should also take care of the issue Pete reported in this thread, without 
the need for e

Re: [edk2-devel] [PATCH v2 4/4] Platform/RaspberryPi: Invert default Arasan, Emmc2 routing

[Pete Batard]

On 2021.02.01 22:53, Jeremy Linton wrote:

In order for the wifi to work, and the SD to run at full
speed we need to bind the sd slot to the eMMC2 controller.


For consistency, you might want to capitalize SD here, since it's 
capitalized before and after.



Since we now have a driver for the eMMC2 controller
there isn't any reason to leave the SD card bound
to the older Arasan controller.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/RPi4/RPi4.dsc  | 2 +-
  Platform/RaspberryPi/RPi4/Readme.md | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 9962df0076..e0fad6f744 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -475,7 +475,7 @@
# SD-related.

#

  


-  
gRaspberryPiTokenSpaceGuid.PcdSdIsArasan|L"SdIsArasan"|gConfigDxeFormSetGuid|0x0|1

+  
gRaspberryPiTokenSpaceGuid.PcdSdIsArasan|L"SdIsArasan"|gConfigDxeFormSetGuid|0x0|0


gRaspberryPiTokenSpaceGuid.PcdMmcForce1Bit|L"MmcForce1Bit"|gConfigDxeFormSetGuid|0x0|0


gRaspberryPiTokenSpaceGuid.PcdMmcForceDefaultSpeed|L"MmcForceDefaultSpeed"|gConfigDxeFormSetGuid|0x0|0


gRaspberryPiTokenSpaceGuid.PcdMmcSdDefaultSpeedMHz|L"MmcSdDefaultSpeedMHz"|gConfigDxeFormSetGuid|0x0|25

diff --git a/Platform/RaspberryPi/RPi4/Readme.md 
b/Platform/RaspberryPi/RPi4/Readme.md
index 3b2ed44e3c..80899f4ca4 100644
--- a/Platform/RaspberryPi/RPi4/Readme.md
+++ b/Platform/RaspberryPi/RPi4/Readme.md
@@ -181,7 +181,7 @@ Limit RAM to 3 GB| `RamLimitTo3GB` | Disable = 
`0x`  Ena
  System Table Selection   | `SystemTableMode`| ACPI = `0x` (default) 
ACPI + Devicetree = `0x0001`  Devicetree = `0x0002`

  Asset Tag| `AssetTag` | String, 32 characters or less (e.g. 
`L"ABCD123"`) (default `L""`)

  **SD/MMC Configuration** |

-uSD/eMMC Routing | `SdIsArasan` | Arasan SDHC = `0x0001` (default) 
 eMMC2 SDHCI = `0x`

+uSD/eMMC Routing | `SdIsArasan` | Arasan SDHC = `0x0001`  
eMMC2 SDHCI = `0x` (default)

  Multi-Block Support  | `MmcDisableMulti` | Multi-block transfers = 
`0x` (default) Single block transfers = `0x0001`

  uSD Max Bus Width| `MmcForce1Bit` | 4-bit Mode = `0x`  
(default) 1-bit Mode = `0x0001`

  uSD Force Default Speed  | `MmcForceDefaultSpeed` | Allow High Speed = 
`0x0000` (default) Force Default Speed = `0x0001`



Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#71475): https://edk2.groups.io/g/devel/message/71475
Mute This Topic: https://groups.io/mt/80300535/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 3/4] Platform/RaspberryPi: User control of eMMC2 DMA

[Pete Batard]

   default = 50,

  endnumeric;

+#if (RPI_MODEL == 4)

+grayoutif ideqval SdIsArasan.Routing == 1;

+oneof varid = MmcEnableDma.EnableDma,

+prompt  = STRING_TOKEN(STR_MMC_EMMC_PROMPT),

+help= STRING_TOKEN(STR_MMC_EMMC_HELP),

+flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,

+option text = STRING_TOKEN(STR_MMC_EMMC_PIO), value = 0, flags = 
DEFAULT;

+option text = STRING_TOKEN(STR_MMC_EMMC_DMA), value = 1, flags = 0;

+endoneof;

+endif;

+#endif

+

  endform;

  


  form formid = 0x1004,

diff --git a/Platform/RaspberryPi/Include/ConfigVars.h 
b/Platform/RaspberryPi/Include/ConfigVars.h
index c185bfe28b..142317985a 100644
--- a/Platform/RaspberryPi/Include/ConfigVars.h
+++ b/Platform/RaspberryPi/Include/ConfigVars.h
@@ -135,4 +135,12 @@ typedef struct {
UINT32 MHz;

  } MMC_SD_HS_MHZ_VARSTORE_DATA;

  


+typedef struct {

+  /*

+   * 0 - eMMC PIO mode

+   * 1 - eMMC DMA mode

+   */

+  UINT32 EnableDma;

+} MMC_EMMC_DMA_VARSTORE_DATA;

+

  #endif /* CONFIG_VARS_H */

diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc 
b/Platform/RaspberryPi/RPi3/RPi3.dsc
index 530b42796a..107cbda297 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -470,6 +470,7 @@

gRaspberryPiTokenSpaceGuid.PcdMmcSdDefaultSpeedMHz|L"MmcSdDefaultSpeedMHz"|gConfigDxeFormSetGuid|0x0|25


gRaspberryPiTokenSpaceGuid.PcdMmcSdHighSpeedMHz|L"MmcSdHighSpeedMHz"|gConfigDxeFormSetGuid|0x0|50


gRaspberryPiTokenSpaceGuid.PcdMmcDisableMulti|L"MmcDisableMulti"|gConfigDxeFormSetGuid|0x0|0

+  
gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma|L"MmcEnableDma"|gConfigDxeFormSetGuid|0x0|0

  


#

# Debug-related.

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 5f8452aa0b..9962df0076 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -481,6 +481,7 @@

gRaspberryPiTokenSpaceGuid.PcdMmcSdDefaultSpeedMHz|L"MmcSdDefaultSpeedMHz"|gConfigDxeFormSetGuid|0x0|25


gRaspberryPiTokenSpaceGuid.PcdMmcSdHighSpeedMHz|L"MmcSdHighSpeedMHz"|gConfigDxeFormSetGuid|0x0|50


gRaspberryPiTokenSpaceGuid.PcdMmcDisableMulti|L"MmcDisableMulti"|gConfigDxeFormSetGuid|0x0|0

+  
gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma|L"MmcEnableDma"|gConfigDxeFormSetGuid|0x0|0

  


#

# Debug-related.

diff --git a/Platform/RaspberryPi/RaspberryPi.dec 
b/Platform/RaspberryPi/RaspberryPi.dec
index 10723036aa..08135717ed 100644
--- a/Platform/RaspberryPi/RaspberryPi.dec
+++ b/Platform/RaspberryPi/RaspberryPi.dec
@@ -69,3 +69,4 @@
gRaspberryPiTokenSpaceGuid.PcdFanOnGpio|0|UINT32|0x001C

gRaspberryPiTokenSpaceGuid.PcdFanTemp|0|UINT32|0x001D

gRaspberryPiTokenSpaceGuid.PcdPlatformResetDelay|0|UINT32|0x001E

+  gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma|0|UINT32|0x001F



Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#71474): https://edk2.groups.io/g/devel/message/71474
Mute This Topic: https://groups.io/mt/80300534/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Platform/RaspberryPi/Acpitables: Add eMMC2 device and tweak Arasan

[Pete Batard]

; above seems to imply that DSD1 applies on top of DSD2, 
whereas, per the code further down, we only apply one of DSD1 or DSD2 
according to SDMA. Maybe, for clarity, this should be mentioned more 
explicitly in the comments above?



+Name (DSD2, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+   Package () { "sdhci-caps-mask", 0x00050448 },
+   }


^
Another tabbed line


+})
+   Method (_DSD, 0x0, Serialized)


^
Another tabbed line


+{
+  if (SDMA == 0)
+  {
+return (^DSD2)
+  }
+  else
+  {
+return (^DSD1)
+  }
+}
+
+//
+// A child device that represents the
+// sd card, which is marked as non-removable.
+//
+Device (SDMM)
+{
+  Method (_ADR)
+  {
+Return (0)
+  }
+  Method (_RMV) // Is removable
+  {
+Return (0) // 0 - fixed
+  }
+}
+  } //SDC3
+} //GDV1
+#endif
+  } //\SB
+}
diff --git a/Platform/RaspberryPi/AcpiTables/Sdhc.asl 
b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
index 0ab1ba27f2..0430ab7d2d 100644
--- a/Platform/RaspberryPi/AcpiTables/Sdhc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
@@ -19,7 +19,7 @@
  // Note: UEFI can use either SDHost or Arasan. We expose both to the OS.

  //

  


-// ArasanSD 3.0 SD Host Controller.

+// ArasanSD 3.0 SD Host Controller. (brcm,bcm2835-sdhci)

  Device (SDC1)

  {

Name (_HID, "BCM2847")

@@ -37,7 +37,7 @@ Device (SDC1)
Name (RBUF, ResourceTemplate ()

{

  MEMORY32FIXED (ReadWrite, 0, MMCHS1_LENGTH, RMEM)

-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 
BCM2836_MMCHS1_INTERRUPT }

+Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { 
BCM2836_MMCHS1_INTERRUPT }

})

Method (_CRS, 0x0, Serialized)

{

@@ -45,6 +45,17 @@ Device (SDC1)
  Return (^RBUF)

}

  


+  // The standard CAPs registers on this controller

+  // appear to be 0, lets set some minimal defaults

+  // Since this cap doesn't indicate DMA capability

+  // we don't need a _DMA()

+  Name (_DSD, Package () {

+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),

+Package () {

+  Package () { "sdhci-caps", 0x0100fa81 },

+}

+  })

+

//

// A child device that represents the

// sd card, which is marked as non-removable.

@@ -62,7 +73,7 @@ Device (SDC1)
}

  }

  


-

+#if (RPI_MODEL < 4)

  // Broadcom SDHost 2.0 SD Host Controller

  Device (SDC2)

  {

@@ -105,3 +116,4 @@ Device (SDC2)
  }

}

  }

+#endif // !RPI4

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index ca7533cbee..7f26f7b4be 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -738,6 +738,12 @@ STATIC CONST NAMESPACE_TABLES SdtTables[] = {
  SsdtNameOpReplace

},

{

+SIGNATURE_64 ('R', 'P', 'I', '4', 'E', 'M', 'M', 'C'),

+0,

+PcdToken(PcdSdIsArasan),

+NULL

+  },

+  {

      SIGNATURE_64 ('R', 'P', 'I', 0, 0, 0, 0, 0),

  0,

  0,



With all of the above being formatting/comment/typos issues:
Reviewed-by: Pete Batard 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#71473): https://edk2.groups.io/g/devel/message/71473
Mute This Topic: https://groups.io/mt/80300533/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/4] Platform/RaspberryPi: Add Negative table check

[Pete Batard]

Looks good to me.

On 2021.02.01 22:53, Jeremy Linton wrote:

Turns out its helpful to have a !PcdToken flag
that enables a DSDT/SSDT. That simplifies
both the emmc2 SSDT (it only installs when
!SdIsArasan) and later for the XHCI/PCIe switch
where we want to install one of two tables
depending on whether a single Pcd is set.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 9581bc41e1..ca7533cbee 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -616,6 +616,7 @@ typedef struct {
  typedef struct {

UINT64  OemTableId;

UINTN   PcdToken;

+  UINTN   PcdTokenNot;

CONST AML_NAME_OP_REPLACE   *SdtNameOpReplace;

  } NAMESPACE_TABLES;

  


@@ -713,6 +714,9 @@ VerifyUpdateTable (
if (SdtTable->PcdToken && !LibPcdGet32 (SdtTable->PcdToken)) {

  Result = FALSE;

}

+  if (SdtTable->PcdTokenNot && LibPcdGet32 (SdtTable->PcdTokenNot)) {

+Result = FALSE;

+  }

if (Result && SdtTable->SdtNameOpReplace) {

  UpdateSdtNameOps (AcpiHeader, SdtTable->SdtNameOpReplace);

}

@@ -730,11 +734,13 @@ STATIC CONST NAMESPACE_TABLES SdtTables[] = {
{

  SIGNATURE_64 ('R', 'P', 'I', 'T', 'H', 'F', 'A', 'N'),

  PcdToken(PcdFanOnGpio),

+0,

  SsdtNameOpReplace

},

{

  SIGNATURE_64 ('R', 'P', 'I', 0, 0, 0, 0, 0),

  0,

+0,

  NULL

    },

{ }



Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#71472): https://edk2.groups.io/g/devel/message/71472
Mute This Topic: https://groups.io/mt/80300531/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] Platform/RaspberryPi/ConfigDxe: Fix JTAG Pinout for Pi3/4

[Pete Batard]

With Andrei's reply, that's an RB for me:

On 2020.09.29 15:01, Samer El-Haj-Mahmoud wrote:

Thanks Pete and Andrei. Should we count these as RB or AB for the patch?

Reviewed-by: Samer El-Haj-Mahmoud 

*From:* devel@edk2.groups.io  *On Behalf Of 
*Andrei Warkentin via groups.io

*Sent:* Monday, September 21, 2020 4:01 PM
*To:* Pete Batard ; Jeff Booher-Kaeding 
; devel@edk2.groups.io
*Cc:* Ard Biesheuvel ; Leif Lindholm 

*Subject:* Re: [edk2-devel] [PATCH v1 1/1] 
Platform/RaspberryPi/ConfigDxe: Fix JTAG Pinout for Pi3/4


Hi folks,

No objection at all. IIRC the original pin selection was driven by an 
article I read about using OpenOCD with Pi 3.


A



*From:*Pete Batard mailto:p...@akeo.ie>>
*Sent:* Tuesday, September 15, 2020 7:26 AM
*To:* Jeff Booher-Kaeding <mailto:jeff.booher-kaed...@arm.com>>; devel@edk2.groups.io 
<mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io>>
*Cc:* Ard Biesheuvel <mailto:ard.biesheu...@arm.com>>; Leif Lindholm <mailto:l...@nuviainc.com>>; Andrei Warkentin <mailto:awarken...@vmware.com>>
*Subject:* Re: [PATCH v1 1/1] Platform/RaspberryPi/ConfigDxe: Fix JTAG 
Pinout for Pi3/4


Copying Andrei on this, as the existing JTAG pinout is not technically
incorrect, since GPIO pin 4 can be used for TDI in ALT5 mode, and we are
using the relevant ALT mode in the existing code. See
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsysprogs.com%2FVisualKernel%2Ftutorials%2Fraspberry%2Fjtagsetup%2Fdata=02%7C01%7Cawarkentin%40vmware.com%7C1c1badf5e6f1433b44b508d859728a32%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637357695767996220sdata=rGIzM4Io36gFJrAK%2F4xZs0fm0DpXVvamhOYYXfc09ek%3Dreserved=0

As far as I'm concerned, I think it makes sense to use the same ALT mode
and have all the JTAG pins grouped, but I'd like to confirm whether we
deliberately chose not to use GPIO 26 in order to leave it available for
some other purpose, before I approve this patch.

If Andrei says he's okay with it, then I see no objection to this change.

Regards,

/Pete

On 2020.09.14 22:32, Jeff Booher-Kaeding wrote:
 > Updated the pinout to match the Pi4 datasheet, tested with the RPi4, 
Pi3 Datasheet has same pinout.

 >
 > Signed-off-by: Jeff Booher-Kaeding <mailto:jeff.booher-kaed...@arm.com>>

 >
 > Cc: Ard Biesheuvel <mailto:ard.biesheu...@arm.com>>

 > Cc: Leif Lindholm mailto:l...@nuviainc.com>>
 > Cc: Pete Batard mailto:p...@akeo.ie>>
 > ---
 >   Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 6 +++---
 >   1 file changed, 3 insertions(+), 3 deletions(-)
 >
 > diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c

 > index ac1004fe1836..6e793efb8227 100644
 > --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
 > +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
 > @@ -502,7 +502,7 @@ ApplyVariables (
 >  * 1   VREF    N/A   1
 >
 >  * 3   nTRST   GPIO22    ALT4    15
 >
 >  * 4   GND N/A   9
 >
 > -   * 5   TDI GPIO4 ALT5    7
 >
 > +   * 5   TDI GPIO26    ALT4    37
 >
 >  * 7   TMS GPIO27    ALT4    13
 >
 >  * 9   TCK GPIO25    ALT4    22
 >
 >  * 11  RTCK    GPIO23    ALT4    16
 >
 > @@ -510,14 +510,14 @@ ApplyVariables (
 >  */
 >
 > if (PcdGet32 (PcdDebugEnableJTAG)) {
 >
 >   GpioPinFuncSet (22, GPIO_FSEL_ALT4);
 >
 > -    GpioPinFuncSet (4, GPIO_FSEL_ALT5);
 >
 > +    GpioPinFuncSet (26, GPIO_FSEL_ALT4);
 >
 >   GpioPinFuncSet (27, GPIO_FSEL_ALT4);
 >
 >   GpioPinFuncSet (25, GPIO_FSEL_ALT4);
 >
 >   GpioPinFuncSet (23, GPIO_FSEL_ALT4);
 >
 >   GpioPinFuncSet (24, GPIO_FSEL_ALT4);
 >
 > } else {
 >
 >   GpioPinFuncSet (22, GPIO_FSEL_INPUT);
 >
 > -    GpioPinFuncSet (4, GPIO_FSEL_INPUT);
 >
 > +    GpioPinFuncSet (26, GPIO_FSEL_INPUT);
 >
 >   GpioPinFuncSet (27, GPIO_FSEL_INPUT);
 >
 >   GpioPinFuncSet (25, GPIO_FSEL_INPUT);
 >
 >   GpioPinFuncSet (23, GPIO_FSEL_INPUT);
 >


Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#65887): https://edk2.groups.io/g/devel/message/65887
Mute This Topic: https://groups.io/mt/76854132/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] Platform/RaspberryPi/ConfigDxe: Fix JTAG Pinout for Pi3/4

[Pete Batard]

Copying Andrei on this, as the existing JTAG pinout is not technically 
incorrect, since GPIO pin 4 can be used for TDI in ALT5 mode, and we are 
using the relevant ALT mode in the existing code. See 
https://sysprogs.com/VisualKernel/tutorials/raspberry/jtagsetup/


As far as I'm concerned, I think it makes sense to use the same ALT mode 
and have all the JTAG pins grouped, but I'd like to confirm whether we 
deliberately chose not to use GPIO 26 in order to leave it available for 
some other purpose, before I approve this patch.


If Andrei says he's okay with it, then I see no objection to this change.

Regards,

/Pete

On 2020.09.14 22:32, Jeff Booher-Kaeding wrote:

Updated the pinout to match the Pi4 datasheet, tested with the RPi4, Pi3 
Datasheet has same pinout.

Signed-off-by: Jeff Booher-Kaeding 

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pete Batard 
---
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index ac1004fe1836..6e793efb8227 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -502,7 +502,7 @@ ApplyVariables (
 * 1   VREFN/A   1

 * 3   nTRST   GPIO22ALT415

 * 4   GND N/A   9

-   * 5   TDI GPIO4 ALT57

+   * 5   TDI GPIO26ALT437

 * 7   TMS GPIO27ALT413

 * 9   TCK GPIO25ALT422

 * 11  RTCKGPIO23ALT416

@@ -510,14 +510,14 @@ ApplyVariables (
 */

if (PcdGet32 (PcdDebugEnableJTAG)) {

  GpioPinFuncSet (22, GPIO_FSEL_ALT4);

-GpioPinFuncSet (4, GPIO_FSEL_ALT5);

+GpioPinFuncSet (26, GPIO_FSEL_ALT4);

  GpioPinFuncSet (27, GPIO_FSEL_ALT4);

  GpioPinFuncSet (25, GPIO_FSEL_ALT4);

  GpioPinFuncSet (23, GPIO_FSEL_ALT4);

  GpioPinFuncSet (24, GPIO_FSEL_ALT4);

} else {

  GpioPinFuncSet (22, GPIO_FSEL_INPUT);

-GpioPinFuncSet (4, GPIO_FSEL_INPUT);

+GpioPinFuncSet (26, GPIO_FSEL_INPUT);

  GpioPinFuncSet (27, GPIO_FSEL_INPUT);

  GpioPinFuncSet (25, GPIO_FSEL_INPUT);

  GpioPinFuncSet (23, GPIO_FSEL_INPUT);




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65270): https://edk2.groups.io/g/devel/message/65270
Mute This Topic: https://groups.io/mt/76854132/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Platform/RaspberryPi4: Correct thermal offset

[Pete Batard]

It might be worth sourcing public documentation, if you have any, 
indicating where these numeric values ultimately come from (the offset 
for absolute zero is easy to figure out, but the rest, not so much).


Apart from that:

On 2020.09.10 00:11, Jeremy Linton wrote:

The current mainline DT indicates that the thermal offset
on the rpi is 410040 rather than the 419949 being used.
This means our temp calculation is offset nearly 10C higher
when running in ACPI mode vs DT.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/AcpiTables/Dsdt.asl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index 2b9e8211cf..d116f965e1 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -269,7 +269,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
Field (TEMS, DWordAcc, NoLock, Preserve) {

  TMPS, 32

}

-  return (((419949 - ((TMPS & 0x3ff) * 487)) / 100) + 2732);

+  return (((410040 - ((TMPS & 0x3ff) * 487)) / 100) + 2732);

  }

  Method (_SCP, 3) { }   // receive cooling policy from OS

  



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65195): https://edk2.groups.io/g/devel/message/65195
Mute This Topic: https://groups.io/mt/76744696/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 6/6] Platform/RaspberryPi: Trivial whitespace cleanup

[Pete Batard]

Hi Ard,

On 2020.09.01 12:39, Ard Biesheuvel wrote:

On 8/31/20 7:25 PM, Jeremy Linton wrote:

Pete's review pointed out some whitespace issues in the
context of a previous patch. Since there are a number of
similar errors in the file lets fix them separately.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
Reviewed-by: Pete Batard <@pbatard>
---
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 24 
+++---

  1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c

index e8f964a329..4ed294cdfe 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -209,9 +209,9 @@ SetupVariables (
    }
    Size = sizeof (UINT32);
-  Status = gRT->GetVariable(L"CustomCpuClock",
-    ,
-    NULL, , );
+  Status = gRT->GetVariable (L"CustomCpuClock",
+ ,
+ NULL, , );
    if (EFI_ERROR (Status)) {
  Status = PcdSet32S (PcdCustomCpuClock, PcdGet32 
(PcdCustomCpuClock));

  ASSERT_EFI_ERROR (Status);
@@ -266,7 +266,7 @@ SetupVariables (
    Size = sizeof (AssetTagVar);
-  Status = gRT->GetVariable(L"AssetTag",
+  Status = gRT->GetVariable (L"AssetTag",
    ,
    NULL, , AssetTagVar);
@@ -275,7 +275,7 @@ SetupVariables (
  L"AssetTag",
  ,
  EFI_VARIABLE_NON_VOLATILE | 
EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,

-    sizeof(AssetTagVar),
+    sizeof (AssetTagVar),
  AssetTagVar
  );
    }
@@ -441,9 +441,9 @@ ApplyVariables (
   * spaces. SystemMemorySizeBelow4GB tracks the maximum memory 
below 4GB

   * line, factoring in the limit imposed by the SoC register range.
   */
-    SystemMemorySizeBelow4GB = MIN(SystemMemorySize, 4UL * SIZE_1GB);
-    SystemMemorySizeBelow4GB = MIN(SystemMemorySizeBelow4GB, 
BCM2836_SOC_REGISTERS);
-    SystemMemorySizeBelow4GB = MIN(SystemMemorySizeBelow4GB, 
BCM2711_SOC_REGISTERS);

+    SystemMemorySizeBelow4GB = MIN (SystemMemorySize, 4UL * SIZE_1GB);
+    SystemMemorySizeBelow4GB = MIN (SystemMemorySizeBelow4GB, 
BCM2836_SOC_REGISTERS);
+    SystemMemorySizeBelow4GB = MIN (SystemMemorySizeBelow4GB, 
BCM2711_SOC_REGISTERS);

  ASSERT (SystemMemorySizeBelow4GB > 3UL * SIZE_1GB);
@@ -536,14 +536,14 @@ ApplyVariables (
    /*
 * SD card pins go to Arasan.
 */
-  MmioWrite32((GPIO_BASE_ADDRESS + 0xD0),
-  MmioRead32(GPIO_BASE_ADDRESS + 0xD0) | 0x2);
+  MmioWrite32 ((GPIO_BASE_ADDRESS + 0xD0),
+  MmioRead32 (GPIO_BASE_ADDRESS + 0xD0) | 0x2);
  } else {
    /*
 * SD card pins back to eMMC2.
 */
-  MmioWrite32((GPIO_BASE_ADDRESS + 0xD0),
-  MmioRead32(GPIO_BASE_ADDRESS + 0xD0) & ~0x2);
+  MmioWrite32 ((GPIO_BASE_ADDRESS + 0xD0),
+  MmioRead32 (GPIO_BASE_ADDRESS + 0xD0) & ~0x2);


Anyone mind if I replace these with MmioOr32 / MmioAnd32 ?


No objection from me. This should indeed make the code cleaner.

Thanks,

/Pete





    /*
 * WiFi back to Arasan.
 */






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64892): https://edk2.groups.io/g/devel/message/64892
Mute This Topic: https://groups.io/mt/76538751/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 5/6] Platform/RaspberryPi4: Allow the user to set Temp

[Pete Batard]

One remark about using PcdSet32S ()  as opposed to PcdSet32 (), since we 
just went through an exercise making sure that we switched to the secure 
version of these calls.


On 2020.08.31 18:25, Jeremy Linton wrote:

Now that we have the ability to enable an AML fan object,
allow the user to select the temperature at which the
fan cycles on.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/AcpiTables/SsdtThermal.asl |  9 +
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 11 ++-
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 -
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 16 
  Platform/RaspberryPi/Include/ConfigVars.h   |  4 
  Platform/RaspberryPi/RPi3/RPi3.dsc  |  1 +
  Platform/RaspberryPi/RPi4/RPi4.dsc  |  1 +
  Platform/RaspberryPi/RaspberryPi.dec|  1 +
  9 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl 
b/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
index ee028173e1..acfa4699bb 100644
--- a/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
+++ b/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
@@ -23,6 +23,7 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPITHFAN", 2)
{
  // Define a NameOp we will modify during InstallTable
  Name (GIOP, 0x2) //08 47 49 4f 50 0a 02 (value must be >1)
+Name (FTMP, 0x2)
  // Describe a fan
  PowerResource (PFAN, 0, 0) {
OperationRegion (GPIO, SystemMemory, GPIO_BASE_ADDRESS, 0x1000)
@@ -68,9 +69,9 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPITHFAN", 2)
// merge in an active cooling point.
Scope (\_SB_.EC00.TZ00)
{
-Method (_AC0) { Return (3332) }// (60C) active cooling trip point,
-   // if this is lower than PSV then we
-   // prefer active cooling
-Name (_AL0, Package () { \_SB_.EC00.FAN0 }) // the fan used for AC0 above
+Method (_AC0) { Return ( (FTMP * 10) + 2732) } // (60C) active cooling 
trip point,
+   // if this is lower than 
PSV then we
+   // prefer active cooling
+Name (_AL0, Package () { \_SB_.EC00.FAN0 })// the fan used for AC0 
above
}
  }
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index d58cbbdfe7..e8f964a329 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -256,8 +256,16 @@ SetupVariables (
  PcdSet32 (PcdFanOnGpio, PcdGet32 (PcdFanOnGpio));

}

  


-  Size = sizeof(AssetTagVar);

+  Size = sizeof (UINT32);

+  Status = gRT->GetVariable (L"FanTemp",

+  ,

+  NULL, , );

+  if (EFI_ERROR (Status)) {

+PcdSet32 (PcdFanTemp, PcdGet32 (PcdFanTemp));



This should be replaced with:

+Status = PcdSet32S (PcdFanTemp, PcdGet32 (PcdFanTemp));
+ASSERT_EFI_ERROR (Status);

Rather than re-spin this patch set yet again, and since the rest of the 
series looks good, I'm hoping this change can be applied during integration.




+  }

+

  


+  Size = sizeof (AssetTagVar);

Status = gRT->GetVariable(L"AssetTag",

,

NULL, , AssetTagVar);

@@ -697,6 +705,7 @@ VerifyUpdateTable(
  


  STATIC AML_NAME_OP_REPLACE SsdtNameOpReplace[] = {

{"GIOP", PcdToken(PcdFanOnGpio)},

+  {"FTMP", PcdToken(PcdFanTemp)},

{}

  };

  


diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index 321e402e65..544e3b3e10 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -91,6 +91,7 @@
gRaspberryPiTokenSpaceGuid.PcdRamMoreThan3GB

gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB

gRaspberryPiTokenSpaceGuid.PcdFanOnGpio

+  gRaspberryPiTokenSpaceGuid.PcdFanTemp

  


  [Depex]

gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index e2d1bb4b39..2afe8f32ae 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -49,11 +49,14 @@
  #string STR_ADVANCED_SYSTAB_DT   #language en-US "Devicetree"

  


  #string STR_ADVANCED_FANONGPIO_PROMPT #language en-US "ACPI fan control"

-#strin

Re: [edk2-devel] [PATCH v3 4/5] Platform/RaspberryPi4: Create ACPI fan object

[Pete Batard]

3 non-blocking whitespace in comments remarks, for consistency.

And of course, same non blocking general remark as 1/5 of whether we may 
ultimately prefer to go with 4-char names for EC0/TZ0...


On 2020.08.28 23:02, Jeremy Linton wrote:

Now that we have a thermal zone we can add active cooling
by specifying active cooling points (_ACx) which can
be tied to fan objects that turn fans on/off using GPIO
pins.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
Reviewed-by: Pete Batard <@pbatard>
---
  Platform/RaspberryPi/AcpiTables/AcpiTables.inf  |  1 +
  Platform/RaspberryPi/AcpiTables/SsdtThermal.asl | 76 +
  2 files changed, 77 insertions(+)
  create mode 100644 Platform/RaspberryPi/AcpiTables/SsdtThermal.asl

diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
index 28d2afe197..c40c32e16f 100644
--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
@@ -33,6 +33,7 @@
Csrt.aslc

Spcr.aslc

Pptt.aslc

+  SsdtThermal.asl

  


  [Packages]

ArmPkg/ArmPkg.dec

diff --git a/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl 
b/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
new file mode 100644
index 00..28c88cd640
--- /dev/null
+++ b/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
@@ -0,0 +1,76 @@
+/** @file
+ *
+ *  Secondary System Description Table (SSDT) for active (fan) cooling
+ *
+ *  Copyright (c) 2020, Arm Ltd. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include 
+#include 
+#include 
+
+#include 
+
+DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPITHFAN", 2)
+{
+  External (\_SB_.EC0, DeviceObj)
+  External (\_SB_.EC0.TZ0, DeviceObj)
+
+  Scope (\_SB_.EC0)
+  {
+// Define a NameOp we will modify during InstallTable
+Name (GIOP, 0x2) //08 47 49 4f 50 0a 02 (value must be >1)


To be consistent with the other comments I'd put a space after //


+// Describe a fan
+PowerResource (PFAN, 0, 0) {
+  OperationRegion (GPIO, SystemMemory, GPIO_BASE_ADDRESS, 0x1000)
+  Field (GPIO, DWordAcc, NoLock, Preserve) {
+Offset (0x1C),
+GPS0, 32,
+GPS1, 32,
+RES1, 32,
+GPC0, 32,
+GPC1, 32,
+RES2, 32,
+GPL1, 32,
+GPL2, 32
+  }
+  // We are hitting a GPIO pin to on/off a fan.
+  // This assumes that UEFI has programmed the
+  // direction as OUT. Given the current limitations
+  // on the GPIO pins, its recommended to use
+  // the GPIO to switch a larger voltage/current
+  // for the fan rather than driving it directly.
+  Method (_STA) {
+if (GPL1 & (1 << GIOP)) {
+  Return (1) // present and enabled
+}
+Return (0)
+  }
+  Method (_ON)  {//turn fan on


Space after //


+Store (1 << GIOP, GPS0)
+  }
+  Method (_OFF) {//turn fan off


Space after //


+Store (1 << GIOP, GPC0)
+  }
+}
+Device (FAN) {
+  // Note, not currently an ACPIv4 fan
+  // the latter adds speed control/detection
+  // but in the case of linux needs FIF, FPS, FSL, and FST
+  Name (_HID, EISAID ("PNP0C0B"))
+  Name (_PR0, Package () { PFAN })
+}
+  }
+
+  // merge in an active cooling point.
+  Scope (\_SB_.EC0.TZ0)
+  {
+Method (_AC0) { Return (3332) }// (60C) active cooling trip point,
+   // if this is lower than PSV then we
+   // prefer active cooling
+Name (_AL0, Package () { \_SB_.EC0.FAN }) // the fan used for AC0 above
+  }
+}



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64832): https://edk2.groups.io/g/devel/message/64832
Mute This Topic: https://groups.io/mt/76484335/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 5/5] Platform/RaspberryPi: Trivial whitespace cleanup

[Pete Batard]

Thanks for this.

On 2020.08.28 23:02, Jeremy Linton wrote:

Pete's review pointed out some whitespace issues in the
context of a previous patch. Since there are a number of
similar errors in the file lets fix them separately.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 26 +++---
  1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index d58cbbdfe7..2712194d2b 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -209,9 +209,9 @@ SetupVariables (
}

  


Size = sizeof (UINT32);

-  Status = gRT->GetVariable(L"CustomCpuClock",

-,

-NULL, , );

+  Status = gRT->GetVariable (L"CustomCpuClock",

+ ,

+ NULL, , );

if (EFI_ERROR (Status)) {

  Status = PcdSet32S (PcdCustomCpuClock, PcdGet32 (PcdCustomCpuClock));

  ASSERT_EFI_ERROR (Status);

@@ -256,9 +256,9 @@ SetupVariables (
  PcdSet32 (PcdFanOnGpio, PcdGet32 (PcdFanOnGpio));

}

  


-  Size = sizeof(AssetTagVar);

+  Size = sizeof (AssetTagVar);

  


-  Status = gRT->GetVariable(L"AssetTag",

+  Status = gRT->GetVariable (L"AssetTag",

,

NULL, , AssetTagVar);

  


@@ -267,7 +267,7 @@ SetupVariables (
  L"AssetTag",

  ,

  EFI_VARIABLE_NON_VOLATILE | 
EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,

-sizeof(AssetTagVar),

+sizeof (AssetTagVar),

  AssetTagVar

  );

}

@@ -433,9 +433,9 @@ ApplyVariables (
   * spaces. SystemMemorySizeBelow4GB tracks the maximum memory below 4GB

   * line, factoring in the limit imposed by the SoC register range.

   */

-SystemMemorySizeBelow4GB = MIN(SystemMemorySize, 4UL * SIZE_1GB);

-SystemMemorySizeBelow4GB = MIN(SystemMemorySizeBelow4GB, 
BCM2836_SOC_REGISTERS);

-SystemMemorySizeBelow4GB = MIN(SystemMemorySizeBelow4GB, 
BCM2711_SOC_REGISTERS);

+SystemMemorySizeBelow4GB = MIN (SystemMemorySize, 4UL * SIZE_1GB);

+SystemMemorySizeBelow4GB = MIN (SystemMemorySizeBelow4GB, 
BCM2836_SOC_REGISTERS);

+SystemMemorySizeBelow4GB = MIN (SystemMemorySizeBelow4GB, 
BCM2711_SOC_REGISTERS);

  


  ASSERT (SystemMemorySizeBelow4GB > 3UL * SIZE_1GB);

  


@@ -528,14 +528,14 @@ ApplyVariables (
/*

 * SD card pins go to Arasan.

 */

-  MmioWrite32((GPIO_BASE_ADDRESS + 0xD0),

-  MmioRead32(GPIO_BASE_ADDRESS + 0xD0) | 0x2);

+  MmioWrite32 ((GPIO_BASE_ADDRESS + 0xD0),

+  MmioRead32 (GPIO_BASE_ADDRESS + 0xD0) | 0x2);

  } else {

/*

 * SD card pins back to eMMC2.

 */

-  MmioWrite32((GPIO_BASE_ADDRESS + 0xD0),

-  MmioRead32(GPIO_BASE_ADDRESS + 0xD0) & ~0x2);

+  MmioWrite32 ((GPIO_BASE_ADDRESS + 0xD0),

+  MmioRead32 (GPIO_BASE_ADDRESS + 0xD0) & ~0x2);

    /*

 * WiFi back to Arasan.

 */



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64833): https://edk2.groups.io/g/devel/message/64833
Mute This Topic: https://groups.io/mt/76484336/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 2/5] Platform/RaspberryPi: Monitor ACPI Table installs

[Pete Batard]

On 2020.08.28 23:02, Jeremy Linton wrote:

Hook the ACPI table install sequence and add some
basic conditional and AML NameOp update logic. If
a table has a non-zero PCD declared that pcd is
checked for a non-zero value before allowing the table
to be installed. We also add a table of NameOp to
PCD's which will be written into a DSDT/SSDT table
as part of its install process.

With this change we can declare something in
ASL like:

Name (VARN, 0x1234)

and then add a table entry like:

{"VARN", PcdToken(PcdVarn)}

and the value of PcdVarn will replace the
0x1234 declared in the ASL above.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 153 -
  1 file changed, 152 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index af54136ade..9e5d9734ca 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -568,6 +568,156 @@ ApplyVariables (
  }

  

  


+typedef struct {

+  CHAR8 Name[4];

+  UINTN PcdToken;

+} AML_NAME_OP_REPLACE;

+

+typedef struct {

+  UINT64  OemTableId;

+  UINTN   PcdToken;

+  AML_NAME_OP_REPLACE *SdtNameOpReplace;

+} NAMESPACE_TABLES;

+

+#define SSDT_PATTERN_LEN 5

+#define AML_NAMEOP_8   0x0A

+#define AML_NAMEOP_16  0x0B

+#define AML_NAMEOP_32  0x0C

+#define AML_NAMEOP_STR 0x0D

+/*

+ * Scan the given namespace table (DSDT/SSDT) for AML NameOps

+ * listed in the NameOpReplace structure. If one is found then

+ * update the value in the table from the specified Pcd

+ *

+ * This allows us to have conditionals in AML controlled

+ * by options in the BDS or detected during firmware bootstrap.

+ * We could extend this concept for strings/etc but due to len

+ * variations its probably easier to encode the strings

+ * in the ASL and pick the correct one based off a variable.

+ */

+STATIC VOID

+UpdateSdtNameOps(

+  EFI_ACPI_DESCRIPTION_HEADER  *AcpiTable,

+  AML_NAME_OP_REPLACE  *NameOpReplace

+  )

+{

+  UINTN  Idx;

+  UINTN  Index;

+  CHAR8  Pattern[SSDT_PATTERN_LEN];

+  UINTN  PcdVal;

+  UINT8  *SdtPtr;

+  UINT32 SdtSize;

+

+  SdtSize = AcpiTable->Length;

+

+  if (SdtSize > 0) {

+SdtPtr = (UINT8*)AcpiTable;

+

+for (Idx = 0; NameOpReplace && NameOpReplace[Idx].PcdToken; Idx++) {

+  /*

+   * Do a single NameOp variable replacement these are of the

+   * form 08  SIZE VAL, where SIZE is 0A=byte, 0B=word, 0C=dword

+   * and  is the name and VAL is the value

+  */

+  Pattern[0] = 0x08;

+  Pattern[1] = NameOpReplace[Idx].Name[0];

+  Pattern[2] = NameOpReplace[Idx].Name[1];

+  Pattern[3] = NameOpReplace[Idx].Name[2];

+  Pattern[4] = NameOpReplace[Idx].Name[3];

+

+  for (Index = 0; Index < (SdtSize - SSDT_PATTERN_LEN); Index++) {

+if (CompareMem (SdtPtr + Index, Pattern, SSDT_PATTERN_LEN) == 0) {

+  PcdVal = LibPcdGet32 (NameOpReplace[Idx].PcdToken);

+  switch (SdtPtr[Index + SSDT_PATTERN_LEN]) {

+  case AML_NAMEOP_32:

+SdtPtr[Index + SSDT_PATTERN_LEN + 4] = (PcdVal >> 24) & 0xFF;

+SdtPtr[Index + SSDT_PATTERN_LEN + 3] = (PcdVal >> 16) & 0xFF;

+// Fallthrough

+  case AML_NAMEOP_16:

+SdtPtr[Index + SSDT_PATTERN_LEN + 2] = (PcdVal >> 8) & 0xFF;

+// Fallthrough

+  case AML_NAMEOP_8:

+SdtPtr[Index + SSDT_PATTERN_LEN + 1] = PcdVal & 0xFF;

+break;

+  case 0:

+  case 1:

+SdtPtr[Index + SSDT_PATTERN_LEN + 1] = !!PcdVal;

+break;

+  case AML_NAMEOP_STR:

+/*

+ * If the string val is added to the NameOpReplace, we can

+ * dynamically update things like _HID too as long as the

+ * string length matches.

+ */

+break;

+  }

+  break;

+}

+  }

+}

+  }

+}

+

+

+STATIC BOOLEAN

+VerifyUpdateTable(

+  IN  EFI_ACPI_DESCRIPTION_HEADER *AcpiHeader,

+  IN  NAMESPACE_TABLES *SdtTable

+  )

+{

+  BOOLEAN ret;

+

+  ret = TRUE;

+  if (SdtTable->PcdToken && !LibPcdGet32 (SdtTable->PcdToken)) {

+ret = FALSE;

+  }

+  if (ret && SdtTable->SdtNameOpReplace) {

+UpdateSdtNameOps (AcpiHeader, SdtTable->SdtNameOpReplace);

+  }

+

+  return ret;

+}

+

+

+STATIC NAMESPACE_TABLES SdtTables[] = {

+  {

+SIGNATURE_64 ('R', 'P', 'I', 0, 0, 0, 0, 0),

+0,

+NULL

+  },

+  { }

+};

+

+/*

+ * Monitor the ACPI tables being installed and when

+ * a DSDT/SSDT is detected validate that we want to

+ * install it, and if so update any &quo

Re: [edk2-devel] [PATCH v3 3/5] Platform/RaspberryPi: Add entry for user fan control

[Pete Batard]

On 2020.08.28 23:02, Jeremy Linton wrote:

Add a menu item that allows the user to enable GPIO based
fan control via SSDT and the previous NameObj replacement
commit. This should only be seen/enabled on RPI4
because that is what its been tested with.

Given GPIO pin current limitations its likely that a bit of
additional circuitry is required to drive a fan, and the GPIO
high/low signal can only be used as a enable/disable signal. A
search for "rpi npn gpio fan" or similar should turn up some
hits for how to do this. Alternatively there are some commercial
boards (FAN SHIM) which operate via simple GPIO control.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
Reviewed-by: Pete Batard <@pbatard>
---
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 26 ++
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  2 ++
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  6 +
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 18 +++
  Platform/RaspberryPi/Include/ConfigVars.h  |  4 
  Platform/RaspberryPi/RPi3/RPi3.dsc |  5 +
  Platform/RaspberryPi/RPi4/RPi4.dsc |  8 +++
  Platform/RaspberryPi/RaspberryPi.dec   |  1 +
  8 files changed, 70 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 9e5d9734ca..d58cbbdfe7 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -15,6 +15,7 @@
  #include 

  #include 

  #include 

+#include 

  #include 

  #include 

  #include 

@@ -22,6 +23,7 @@
  #include 

  #include 

  #include 

+#include 

  #include 

  #include 

  #include 

@@ -246,6 +248,14 @@ SetupVariables (
  ASSERT_EFI_ERROR (Status);

}

  


+  Size = sizeof (UINT32);

+  Status = gRT->GetVariable (L"FanOnGpio",

+  ,

+  NULL, , );

+  if (EFI_ERROR (Status)) {

+PcdSet32 (PcdFanOnGpio, PcdGet32 (PcdFanOnGpio));

+  }

+

Size = sizeof(AssetTagVar);

  


Status = gRT->GetVariable(L"AssetTag",

@@ -368,6 +378,7 @@ ApplyVariables (
UINT32 CpuClock = PcdGet32 (PcdCpuClock);

UINT32 CustomCpuClock = PcdGet32 (PcdCustomCpuClock);

UINT32 Rate = 0;

+  UINT32 FanOnGpio = PcdGet32 (PcdFanOnGpio);

  


switch (CpuClock) {

case CHIPSET_CPU_CLOCK_LOW:

@@ -565,6 +576,11 @@ ApplyVariables (
  GpioPinFuncSet (23, GPIO_FSEL_INPUT);

  GpioPinFuncSet (24, GPIO_FSEL_INPUT);

}

+

+  if (FanOnGpio) {

+DEBUG ((DEBUG_INFO, "Fan enabled on GPIO %d\n", FanOnGpio));

+GpioPinFuncSet (FanOnGpio, GPIO_FSEL_OUTPUT);

+  }

  }

  

  


@@ -679,8 +695,18 @@ VerifyUpdateTable(
  }

  

  


+STATIC AML_NAME_OP_REPLACE SsdtNameOpReplace[] = {

+  {"GIOP", PcdToken(PcdFanOnGpio)},

+  {}

+};

+

  STATIC NAMESPACE_TABLES SdtTables[] = {

{

+SIGNATURE_64 ('R', 'P', 'I', 'T', 'H', 'F', 'A', 'N'),

+PcdToken(PcdFanOnGpio),

+SsdtNameOpReplace

+  },

+  {

  SIGNATURE_64 ('R', 'P', 'I', 0, 0, 0, 0, 0),

  0,

  NULL

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index cdce35bc74..321e402e65 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -46,6 +46,7 @@
AcpiLib

BaseLib

DebugLib

+  DxeServicesLib

DxeServicesTableLib

GpioLib

HiiLib

@@ -89,6 +90,7 @@
gRaspberryPiTokenSpaceGuid.PcdSystemTableMode

gRaspberryPiTokenSpaceGuid.PcdRamMoreThan3GB

gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB

+  gRaspberryPiTokenSpaceGuid.PcdFanOnGpio

  


  [Depex]

gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 03763710a1..e2d1bb4b39 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -48,6 +48,12 @@
  #string STR_ADVANCED_SYSTAB_BOTH #language en-US "ACPI + Devicetree"

  #string STR_ADVANCED_SYSTAB_DT   #language en-US "Devicetree"

  


+#string STR_ADVANCED_FANONGPIO_PROMPT #language en-US "ACPI fan control"

+#string STR_ADVANCED_FANONGPIO_HELP   #language en-US "Cycle a fan via GPIO if temp 
exceeds 60C"

+#string STR_ADVANCED_FANONGPIO_OFF#language en-US "Disabled"

+#string STR_ADVANCED_FANONGPIO_18 #language en-US "Fan Shim/GPIO-18"

+#string STR_ADVANCED_FANONGPIO_19 #language en-US "GPIO-19"

+

  #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"

  #string STR_ADVANCED_ASSET

Re: [edk2-devel] [PATCH v3 1/5] Platform/RaspberryPi4: Add a basic thermal zone

[Pete Batard]

One general, non-blocking comment below:

On 2020.08.28 23:02, Jeremy Linton wrote:

Rather than exporting the temp sensor or mailbox
in ACPI land we can wrap them in AML and use the default
ACPI drivers provided by the OS. This enables the use of
"sensors" in linux to report the SOC temp.

As a first pass add a basic passive cooling ACPI thermalzone
with trip points for passive cooling (throttling) handled
by the vc firmware, hibernate and critical shutdown. The
vc apparently kicks in at ~80C, so the hibernate and critical
set points are set at +5 and +10 of that. In the future
CPPC should be able to monitor the thermal throttling.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
Reviewed-by: Pete Batard <@pbatard>
---
  Platform/RaspberryPi/AcpiTables/Dsdt.asl   | 31 ++
  .../Bcm27xx/Include/IndustryStandard/Bcm2711.h |  2 ++
  2 files changed, 33 insertions(+)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index 353af2d876..73067aefd2 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -252,6 +252,37 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
  }

})

  }

+

+// Define a simple thermal zone. The idea here is we compute the SOC temp

+// via a register we can read, and give it to the OS. This enables basic

+// reports from the "sensors" utility, and the OS can then poll and take

+// actions if that temp exceeds any of the given thresholds.

+Device (EC0)


Just going to point out that all the other ACPI devices we seem to 
define have 4 characters, so I'm not sure if we're breaking a convention 
by introducing a 3 character one here...




+{

+  Name (_HID, EISAID ("PNP0C06"))

+  Name (_CCA, 0x0)

+

+  // all temps in are tenths of K (aka 2732 is the min temps in Linux (aka 
0C))

+  ThermalZone (TZ0) {


Likewise, what I'm seeing by googling around for ThermalZone () names 
would be 4 character ones such as "TZ00", "TZ01" or "TZS0" (For 'Thermal 
Zone Sensor 0') or "TMZN" for single entries.




+Method (_TMP, 0, Serialized) {

+  OperationRegion (TEMS, SystemMemory, THERM_SENSOR, 0x8)

+  Field (TEMS, DWordAcc, NoLock, Preserve) {

+TMPS, 32

+  }

+  return (((419949 - ((TMPS & 0x3ff) * 487)) / 100) + 2732);

+}

+Method (_SCP, 3) { }   // receive cooling policy from OS

+

+Method (_CRT) { Return (3632) }// (90C) Critical temp point 
(immediate power-off)

+Method (_HOT) { Return (3582) }// (85C) HOT state where OS should 
hibernate

+Method (_PSV) { Return (3532) }// (80C) Passive cooling (CPU 
throttling) trip point

+

+// SSDT inserts _AC0/_AL0 @60C here, if a FAN is configured

+

+Name (_TZP, 10)   //The OSPM must poll this device 
every 1 seconds

+Name (_PSL, Package () { \_SB_.CPU0, \_SB_.CPU1, \_SB_.CPU2, 
\_SB_.CPU3 })

+  }

+}

  #endif

  


}

diff --git a/Silicon/Broadcom/Bcm27xx/Include/IndustryStandard/Bcm2711.h 
b/Silicon/Broadcom/Bcm27xx/Include/IndustryStandard/Bcm2711.h
index e9c81cafa1..86906b2438 100644
--- a/Silicon/Broadcom/Bcm27xx/Include/IndustryStandard/Bcm2711.h
+++ b/Silicon/Broadcom/Bcm27xx/Include/IndustryStandard/Bcm2711.h
@@ -86,4 +86,6 @@
  #define GENET_BASE_ADDRESS FixedPcdGet64 (PcdBcmGenetRegistersAddress)

  #define GENET_LENGTH   0x0001

  


+#define THERM_SENSOR   0xfd5d2200

+

  #endif /* BCM2711_H__ */



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64829): https://edk2.groups.io/g/devel/message/64829
Mute This Topic: https://groups.io/mt/76484330/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Fix build error in DisplayDxe

[Pete Batard]

On 2020.08.27 00:20, Samer El-Haj-Mahmoud wrote:

Commit 0c2af04985f0bf152ac3edc70d9c6d9fe884cdcb added mDriverBinding
extern module global, but did not remove the STATIC declaration, which
caused the build to break. Fix the build error by removing STATIC for
that module global variable.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.c 
b/Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.c
index ae4b2735820c..3eba98e5aa87 100644
--- a/Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.c
+++ b/Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.c
@@ -87,7 +87,7 @@ DisplayBlt (
IN  UINTN   Delta OPTIONAL
);
  
-STATIC EFI_DRIVER_BINDING_PROTOCOL mDriverBinding = {

+EFI_DRIVER_BINDING_PROTOCOL mDriverBinding = {
DriverSupported,
DriverStart,
DriverStop,



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64664): https://edk2.groups.io/g/devel/message/64664
Mute This Topic: https://groups.io/mt/76440544/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform][PATCH v1 2/3] Platforms/RaspberryPi: Fix DwUsbHostDxe ComponentName2 error checking

[Pete Batard]

Same typo as previous patch:

On 2020.08.15 21:26, Samer El-Haj-Mahmoud wrote:

Fix input param error checking for the DwUsbHostDxe ComponentName2
protocol.

This fixes https://github.com/pftf/RPi4/issues/86

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Platform/RaspberryPi/Drivers/DwUsbHostDxe/DwUsbHostDxe.h  |  4 +++-
  Platform/RaspberryPi/Drivers/DwUsbHostDxe/ComponentName.c | 18 
++
  Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c |  2 +-
  3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DwUsbHostDxe.h 
b/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DwUsbHostDxe.h
index 106e5425355e..cf6c81b64ab5 100644
--- a/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DwUsbHostDxe.h
+++ b/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DwUsbHostDxe.h
@@ -1,5 +1,6 @@
  /** @file
   *
+ *  Copyright (c) 2020, ARM Limited. All rights reserved.
   *  Copyright (c) 2017-2018, Andrey Warkentin 
   *  Copyright (c) 2015-2016, Linaro Limited. All rights reserved.
   *
@@ -121,8 +122,9 @@ typedef struct _DWUSB_OTGHC_DEV {
UINT16  LastMicroFrame;
  } DWUSB_OTGHC_DEV;
  
-extern EFI_COMPONENT_NAME_PROTOCOL gComponentName;

+extern EFI_COMPONENT_NAME_PROTOCOL  gComponentName;
  extern EFI_COMPONENT_NAME2_PROTOCOL gComponentName2;
+extern EFI_DRIVER_BINDING_PROTOCOL  mDriverBinding;
  
  EFI_STATUS

  CreateDwUsbHc (
diff --git a/Platform/RaspberryPi/Drivers/DwUsbHostDxe/ComponentName.c 
b/Platform/RaspberryPi/Drivers/DwUsbHostDxe/ComponentName.c
index 2f3c53323bf1..8639ab7d39c5 100644
--- a/Platform/RaspberryPi/Drivers/DwUsbHostDxe/ComponentName.c
+++ b/Platform/RaspberryPi/Drivers/DwUsbHostDxe/ComponentName.c
@@ -1,5 +1,6 @@
  /** @file
   *
+ *  Copyright (c) 2020, ARM Limited. All rights reserved.
   *  Copyright (c) 2018, Andrey Warkentin 
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -205,10 +206,27 @@ ComponentNameGetControllerName (
OUT CHAR16  **ControllerName
)
  {
+  EFI_STATUS  Status;
+
+  //
+  // This is a device driver, so ChildHandle must be NULL.
+  //
if (ChildHandle != NULL) {
  return EFI_UNSUPPORTED;
}
  
+  //

+  // Make sure this driver is currently managing ControllHandle


Shouldn't it be 'ControllerHandle' rather than 'ControllHandle'?


+  //
+  Status = EfiTestManagedDevice (
+ ControllerHandle,
+ mDriverBinding.DriverBindingHandle,
+ 
+ );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
return LookupUnicodeString2 (
 Language,
 This->SupportedLanguages,
diff --git a/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c 
b/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
index 7f78179d4c06..bada13a6cd7c 100644
--- a/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
+++ b/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
@@ -36,7 +36,7 @@ DriverStop (
IN  EFI_HANDLE  *ChildHandleBuffer
);
  
-STATIC EFI_DRIVER_BINDING_PROTOCOL mDriverBinding = {

+EFI_DRIVER_BINDING_PROTOCOL mDriverBinding = {
DriverSupported,
DriverStart,
DriverStop,



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64316): https://edk2.groups.io/g/devel/message/64316
Mute This Topic: https://groups.io/mt/76213600/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform][PATCH v1 3/3] Platforms/RaspberryPi: Fix BcmGenetDxe ComponentName2 error checking

[Pete Batard]

Same typo as previous patch:

On 2020.08.15 21:26, Samer El-Haj-Mahmoud wrote:

Fix input param error checking for the BcmGenetDxe ComponentName2
protocol.

This fixes https://github.com/pftf/RPi4/issues/85

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h   |  1 +
  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/ComponentName.c | 22 

  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/DriverBinding.c |  2 +-
  3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
index b39a1326335a..26016330fb3b 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
@@ -235,6 +235,7 @@ typedef struct {
  
  extern EFI_COMPONENT_NAME_PROTOCOLgGenetComponentName;

  extern EFI_COMPONENT_NAME2_PROTOCOL   gGenetComponentName2;
+extern EFI_DRIVER_BINDING_PROTOCOLmGenetDriverBinding;
  
  extern CONST EFI_SIMPLE_NETWORK_PROTOCOL  gGenetSimpleNetworkTemplate;

  extern CONST EFI_ADAPTER_INFORMATION_PROTOCOL gGenetAdapterInfoTemplate;
diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/ComponentName.c 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/ComponentName.c
index 860e30b4da6b..abc5b7db16c2 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/ComponentName.c
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/ComponentName.c
@@ -2,6 +2,7 @@
UEFI Component Name(2) protocol implementation for GENET UEFI driver.
  
Copyright (c) 2020 Jared McNeill. All rights reserved.

+  Copyright (c) 2020, ARM Limited. All rights reserved.
  
SPDX-License-Identifier: BSD-2-Clause-Patent

  **/
@@ -169,6 +170,27 @@ GenetComponentNameGetControllerName (
OUT CHAR16  **ControllerName
)
  {
+  EFI_STATUS  Status;
+
+  //
+  // This is a device driver, so ChildHandle must be NULL.
+  //
+  if (ChildHandle != NULL) {
+return EFI_UNSUPPORTED;
+  }
+
+  //
+  // Make sure this driver is currently managing ControllHandle


Shouldn't it be 'ControllerHandle' rather than 'ControllHandle'?


+  //
+  Status = EfiTestManagedDevice (
+ ControllerHandle,
+ mGenetDriverBinding.DriverBindingHandle,
+ 
+ );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
if (ChildHandle != NULL) {
  return EFI_UNSUPPORTED;
}
diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/DriverBinding.c 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/DriverBinding.c
index f9aa006dc799..435ef493564c 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/DriverBinding.c
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/DriverBinding.c
@@ -302,7 +302,7 @@ GenetDriverBindingStop (
return EFI_SUCCESS;
  }
  
-STATIC EFI_DRIVER_BINDING_PROTOCOL mGenetDriverBinding = {

+EFI_DRIVER_BINDING_PROTOCOL mGenetDriverBinding = {
GenetDriverBindingSupported,
GenetDriverBindingStart,
GenetDriverBindingStop,



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64317): https://edk2.groups.io/g/devel/message/64317
Mute This Topic: https://groups.io/mt/76213603/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform][PATCH v1 1/3] Platforms/RaspberryPi: Fix DisplayDxe ComponentName2 error checking

[Pete Batard]

One typo:

On 2020.08.15 21:26, Samer El-Haj-Mahmoud wrote:

Fix input param error checking for the DisplayDxe ComponentName2
protocol.

This fixes https://github.com/pftf/RPi4/issues/84

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.h|  2 ++
  Platform/RaspberryPi/Drivers/DisplayDxe/ComponentName.c | 22 

  2 files changed, 24 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.h 
b/Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.h
index bfbe9e868843..073f65111645 100644
--- a/Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.h
+++ b/Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.h
@@ -1,5 +1,6 @@
  /** @file
   *
+ *  Copyright (c) 2020, ARM Limited. All rights reserved.
   *  Copyright (c) 2017-2018, Andrei Warkentin 
   *  Copyright (c) Microsoft Corporation. All rights reserved.
   *
@@ -27,6 +28,7 @@
  extern EFI_GRAPHICS_OUTPUT_PROTOCOL gDisplayProto;
  extern EFI_COMPONENT_NAME_PROTOCOL  gComponentName;
  extern EFI_COMPONENT_NAME2_PROTOCOL gComponentName2;
+extern EFI_DRIVER_BINDING_PROTOCOL  mDriverBinding;
  
  VOID

  RegisterScreenshotHandlers (
diff --git a/Platform/RaspberryPi/Drivers/DisplayDxe/ComponentName.c 
b/Platform/RaspberryPi/Drivers/DisplayDxe/ComponentName.c
index 092230cd7c9b..4c065b5d51bf 100644
--- a/Platform/RaspberryPi/Drivers/DisplayDxe/ComponentName.c
+++ b/Platform/RaspberryPi/Drivers/DisplayDxe/ComponentName.c
@@ -1,5 +1,6 @@
  /** @file
   *
+ *  Copyright (c) 2020, ARM Limited. All rights reserved.
   *  Copyright (c) 2018, Andrei Warkentin 
   *  Copyright (c) 2006-2016, Intel Corporation. All rights reserved.
   *
@@ -206,6 +207,27 @@ ComponentNameGetControllerName (
OUT CHAR16  **ControllerName
)
  {
+  EFI_STATUS  Status;
+
+  //
+  // This is a device driver, so ChildHandle must be NULL.
+  //
+  if (ChildHandle != NULL) {
+return EFI_UNSUPPORTED;
+  }
+
+  //
+  // Make sure this driver is currently managing ControllHandle


Shouldn't it be 'ControllerHandle' rather than 'ControllHandle'?


+  //
+  Status = EfiTestManagedDevice (
+ ControllerHandle,
+ mDriverBinding.DriverBindingHandle,
+ 
+ );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
return LookupUnicodeString2 (
 Language,
 This->SupportedLanguages,



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64315): https://edk2.groups.io/g/devel/message/64315
Mute This Topic: https://groups.io/mt/76213602/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi: Add entry for user fan control

[Pete Batard]

More minor style issues:

On 2020.08.14 00:00, Jeremy Linton wrote:

Add a menu item that allows the user to enable GPIO based
fan control via SSDT. This should only be seen/enabled on RPI4
because that is what its been tested with. As of this commit
its currently limited to only operating on a single GPIO pin (19).

Given GPIO pin current limitations its likely that a bit of
additional circuitry is required to drive a fan, and the GPIO
high/low signal can only be used as a enable/disable signal. A
search for "rpi npn gpio fan" or similar should turn up some
hits for how to do this simply.

It appears there are a couple boards (fan SHIM) which operate this
way, and probably should have custom menu items/SSDT edits as
people acquire the boards and test them.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 55 ++
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  3 ++
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 ++
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 17 +++
  Platform/RaspberryPi/Include/ConfigVars.h  |  4 ++
  Platform/RaspberryPi/RPi3/RPi3.dsc |  5 ++
  Platform/RaspberryPi/RPi4/RPi4.dsc |  8 
  Platform/RaspberryPi/RaspberryPi.dec   |  1 +
  .../Bcm27xx/Include/IndustryStandard/Bcm2711.h |  2 +
  9 files changed, 100 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index af54136ade..f10347be64 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -15,6 +15,7 @@
  #include 

  #include 

  #include 

+#include 

  #include 

  #include 

  #include 

@@ -22,6 +23,7 @@
  #include 

  #include 

  #include 

+#include 

  #include 

  #include 

  #include 

@@ -246,6 +248,14 @@ SetupVariables (
  ASSERT_EFI_ERROR (Status);

}

  


+  Size = sizeof (UINT32);

+  Status = gRT->GetVariable (L"FanOnGpio",

+  ,

+  NULL, , );

+  if (EFI_ERROR (Status)) {

+PcdSet32 (PcdFanOnGpio, PcdGet32 (PcdFanOnGpio));

+  }

+

Size = sizeof(AssetTagVar);


Space before '('



  


Status = gRT->GetVariable(L"AssetTag",


Space before '('



@@ -368,6 +378,7 @@ ApplyVariables (
UINT32 CpuClock = PcdGet32 (PcdCpuClock);

UINT32 CustomCpuClock = PcdGet32 (PcdCustomCpuClock);

UINT32 Rate = 0;

+  UINT32 FanOnGpio = PcdGet32 (PcdFanOnGpio);

  


switch (CpuClock) {

case CHIPSET_CPU_CLOCK_LOW:

@@ -565,8 +576,49 @@ ApplyVariables (
  GpioPinFuncSet (23, GPIO_FSEL_INPUT);

  GpioPinFuncSet (24, GPIO_FSEL_INPUT);

}

+

+  if (FanOnGpio) {

+DEBUG ((DEBUG_INFO, "Fan enabled on GPIO %d\n", FanOnGpio));

+GpioPinFuncSet(FanOnGpio, GPIO_FSEL_OUTPUT);


Space before '('


+  }

  }

  


+EFI_STATUS

+FindInstallSsdt(UINT64 OemTableId)


Space before '('



+{

+  EFI_ACPI_TABLE_PROTOCOL *AcpiTable;

+  UINTN   Index;

+  EFI_ACPI_DESCRIPTION_HEADER *Ssdt;

+  UINTN   SsdtSize;

+  EFI_STATUS  Status;

+  UINTN   TableKey;

+

+

+  Status = gBS->LocateProtocol (, NULL,

+(VOID **));

+  if (EFI_ERROR (Status)) {

+return Status;

+  }

+

+  for (Index = 0; !EFI_ERROR(Status); Index++) {


Space before '('



+Status = GetSectionFromFv (, EFI_SECTION_RAW, Index,

+   (VOID **), );

+if (Ssdt->OemTableId == OemTableId)

+break;


Indentation should be 2 spaces after 'if'



+SsdtSize = 0;

+  }

+

+  if (SsdtSize > 0) {

+Status = AcpiTable->InstallAcpiTable (AcpiTable, Ssdt, SsdtSize,

+  );

+if (EFI_ERROR (Status)) {

+  DEBUG ((DEBUG_WARN, "%a: failed to install SSDT table %r\n",

+  __FUNCTION__, Status));

+}

+  }

+

+  return Status;

+}

  


  EFI_STATUS

  EFIAPI

@@ -620,6 +672,9 @@ ConfigInitialize (
PcdGet32 (PcdSystemTableMode) == SYSTEM_TABLE_MODE_BOTH) {

   Status = LocateAndInstallAcpiFromFv ();

   ASSERT_EFI_ERROR (Status);

+ if (PcdGet32 (PcdFanOnGpio)) {

+ FindInstallSsdt(SIGNATURE_64 ('R', 'P', 'I', 'T', 'H', 'F', 'A', 
'N'));


Space before '(' and indentation should be 2 spaces after 'if'



+ }

}

  


Status = gBS->CreateEventEx (EVT_NOTIFY_SIGNAL, TPL_NOTIFY, RegisterDevices,

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index cdce35bc74..fe3a01a570 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drive

Re: [edk2-devel] [PATCH 1/3] Platform/RaspberryPi4: Add a basic thermal zone

[Pete Batard]

Nothing major, just whitespace/style and one minor capitalization issue:

On 2020.08.14 00:00, Jeremy Linton wrote:

Rather than exporting the temp sensor or mailbox
in ACPI land we can wrap them in AML and use the default
ACPI drivers provided by the OS. This enables the use of
"sensors" in linux to report the SOC temp.

This commit also adds a basic passive cooling ACPI thermalzone
with trip points for passive cooling (throttling) handled
by the vc firmware, hibernate and critical shutdown. The
vc apparently kicks in at ~80C, so the hibernate and critical
set points are set at +5 and +10 of that. In the future
CPPC should be able to monitor the thermal throttling.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/AcpiTables/Dsdt.asl | 31 +++
  1 file changed, 31 insertions(+)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index 353af2d876..a5c9567cdf 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -252,6 +252,37 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
  }

})

  }

+

+// Define a simple thermal zone. The idea here is we compute the SOC temp

+// via a register we can read, and give it to the OS. This enables basic

+// reports from the "sensors" utility, and the OS can then poll and take

+// actions if that temp exceeds any of the given thresholds.

+Device(EC0)

+{

+  Name(_HID, EISAID("PNP0C06"))


Space between EISAID and ("PNP0C06")



+  Name (_CCA, 0x0)

+

+  // all temps in are tenths of K (aka 2732 is the min temps in linux (aka 
0C))


I'd use a capital 'L' in "Linux"



+  ThermalZone(TZ0) {


Space before '('



+Method(_TMP, 0, Serialized) {


Space before '('


+  OperationRegion (TEMS, SystemMemory, 0xfd5d2200, 0x8)

+  Field (TEMS, DWordAcc, NoLock, Preserve) {

+TMPS, 32

+  }

+  return (((419949 - ((TMPS & 0x3ff) * 487)) / 100) + 2732);

+}

+Method(_SCP, 3) { }  // receive cooling policy from OS

+

+Method(_CRT) { return(3632) }// (90K) Critical temp point 
(immediate power-off)

+Method(_HOT) { return(3582) }// (85K) HOT state where OS should 
hibernate

+Method(_PSV) { return(3532) }// (80K) Passive cooling (CPU 
throttling) trip point

+

+// SSDT inserts _AC0/_AL0 @60C here, if a FAN is configured

+

+Name(_TZP, 10)   //The OSPM must poll this device 
every 1 seconds

+Name(_PSL, Package(){ \_SB_.CPU0, \_SB_.CPU1, \_SB_.CPU2, \_SB_.CPU3})


6 x Space before '('



+  }

+}

  #endif

  


}



Reviewed by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64312): https://edk2.groups.io/g/devel/message/64312
Mute This Topic: https://groups.io/mt/76178274/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/3] Platform/RaspberryPi4: Create ACPI fan object

[Pete Batard]

Whitespace/style and typos:

On 2020.08.14 00:00, Jeremy Linton wrote:

Now that we have a thermal zone we can add active cooling
by specifying active cooling points (_ACx) which can
be tied to fan objects that turn fans on/off using GPIO
pins.

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
---
  .../RaspberryPi/Drivers/ConfigDxe/SsdtThermal.asl  | 83 ++
  1 file changed, 83 insertions(+)
  create mode 100644 Platform/RaspberryPi/Drivers/ConfigDxe/SsdtThermal.asl

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/SsdtThermal.asl 
b/Platform/RaspberryPi/Drivers/ConfigDxe/SsdtThermal.asl
new file mode 100644
index 00..c87bda6dbc
--- /dev/null
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/SsdtThermal.asl
@@ -0,0 +1,83 @@
+/** @file
+ *
+ *  Secondary System Description Table (SSDT) for active (fan) cooling
+ *
+ *  Copyright (c) 2020, Arm Ltd. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#include 
+#include 
+#include 
+
+#include 
+
+DefinitionBlock(__FILE__, "SSDT", 5, "RPIFDN", "RPITHFAN", 2)


Space before '('


+{
+#if (GPIO_FAN_PIN != 0)
+  External(\_SB_.EC0, DeviceObj)
+  External(\_SB_.EC0.TZ0, DeviceObj)
+
+  Scope (\_SB_.EC0)


3 x Space before '('


+  {
+  // Describe a fan
+  PowerResource(PFAN, 0, 0) {


Space before '('


+OperationRegion (GPIO, SystemMemory, GPIO_BASE_ADDRESS, 0x1000)
+Field (GPIO, DWordAcc, NoLock, Preserve) {
+  Offset(0x1C),


Space before '('


+  GPS0, 32,
+  GPS1, 32,
+  RES1, 32,
+  GPC0, 32,
+  GPC1, 32,
+  RES2, 32,
+  GPL1, 32,
+  GPL2, 32
+}
+// We are hitting a GPIO pin to on/off the fan
+// this assumes that UEFI has programmed the
+// direction as OUT.
+// (search "rpi gpio fan controller" for how to
+// wire this up if your not electrically inclined


"your" -> "you're"


+// the basic idea is to use a BJT/etc to switch a
+// larger voltage through a fan where the GPIO pin
+// feeds a NPN/PNP base. Thats because its unlikly


"Thats" -> "That's", "unlikly" -> "unlikely"


+// that the fan can be driven directly from the GPIO
+// pin due to hitting the current limit on the pins.
+// Matching a resistor between the GPIO->Base can
+// allow pretty much any random NPN with a reasonable
+// EC current to work (to limit the GPIO current).)
+Method (_STA) {
+  if ( GPL1 & (1 << GPIO_FAN_PIN) ) {


No space between '(' and 'GPL1', as well as between the last 2 ')'


+Return ( 1 )   // present and enabled


No spaces inside the parenthesis


+  }
+  Return ( 0 )


No spaces inside the parenthesis


+}
+Method (_ON)  {//turn fan on
+  Store((1 << GPIO_FAN_PIN), GPS0)


Space before '('


+}
+Method (_OFF) {//turn fan off
+  Store((1 << GPIO_FAN_PIN), GPC0)


Space before '('


+}
+  }
+  Device(FAN) {


Space before '('


+// Note, not currently an ACPIv4 fan
+// the latter adds speed control/detection
+// but in the case of linux needs FIF, FPS, FSL, and FST
+Name(_HID, EISAID("PNP0C0B"))
+Name(_PR0, Package() {PFAN})


2 x Space before '(', space after '{' and before '}'


+  }
+  }
+
+  // merge in an active cooling point.
+  Scope (\_SB_.EC0.TZ0)
+  {
+Method(_AC0) { return(3332) }// (60K) active cooling trip point,


Space before '('


+ // if this is lower than PSV then we
+ // prefer active cooling
+Name(_AL0, Package(){\_SB_.EC0.FAN}) // the fan used for AC0 above


Space before '(' for 'Name' and 'Package', space after () of 'Package', 
space after '{' and before '}'



+  }
+#endif
+}



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64313): https://edk2.groups.io/g/devel/message/64313
Mute This Topic: https://groups.io/mt/76178275/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Fix DBG2 UART namespace reference

[Pete Batard]

On 2020.08.13 15:27, Samer El-Haj-Mahmoud wrote:

The UART namespace reference in DBG2 is incorrect. Fix to point to the
correct name.

This fixes the certification failure reported by FWTS tests at:
https://github.com/pftf/RPi4/issues/69

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Platform/RaspberryPi/AcpiTables/Dbg2.aslc | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dbg2.aslc 
b/Platform/RaspberryPi/AcpiTables/Dbg2.aslc
index c35b15693f5a..e3f2adae7e21 100644
--- a/Platform/RaspberryPi/AcpiTables/Dbg2.aslc
+++ b/Platform/RaspberryPi/AcpiTables/Dbg2.aslc
@@ -3,7 +3,7 @@
   *  Debug Port Table (DBG2)
   *
   *  Copyright (c) 2019, Pete Batard 
- *  Copyright (c) 2012-2016, ARM Limited. All rights reserved.
+ *  Copyright (c) 2012-2020, ARM Limited. All rights reserved.
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
   *
@@ -21,13 +21,13 @@
  
  #define RPI_DBG2_NUM_DEBUG_PORTS1

  #define RPI_DBG2_NUMBER_OF_GENERIC_ADDRESS_REGISTERS1
-#define RPI_DBG2_NAMESPACESTRING_FIELD_SIZE 10
+#define RPI_DBG2_NAMESPACESTRING_FIELD_SIZE 15
  
  #if (RPI_MODEL == 4)

  #define RPI_UART_INTERFACE_TYPE 
EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_ARM_PL011_UART
  #define RPI_UART_BASE_ADDRESS   
BCM2836_PL011_UART_BASE_ADDRESS
  #define RPI_UART_LENGTH 
BCM2836_PL011_UART_LENGTH
-#define RPI_UART_STR{ '\\', '_', 'S', 'B', 
'.', 'U', 'R', 'T', '0', 0x00 }
+#define RPI_UART_STR{ '\\', '_', 'S', 'B', 
'.', 'G', 'D', 'V', '0', '.', 'U', 'R', 'T', '0', 0x00 }
  #else
  #define RPI_UART_INTERFACE_TYPE 
EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_BCM2835_UART
  #define RPI_UART_BASE_ADDRESS   
BCM2836_MINI_UART_BASE_ADDRESS
@@ -35,7 +35,7 @@
  //
  // RPI_UART_STR should match the value used Uart.asl
  //
-#define RPI_UART_STR{ '\\', '_', 'S', 'B', 
'.', 'U', 'R', 'T', 'M', 0x00 }
+#define RPI_UART_STR{ '\\', '_', 'S', 'B', 
'.', 'G', 'D', 'V', '0', '.', 'U', 'R', 'T', 'M', 0x00 }
  #endif
  
  typedef struct {




Reviewed-by: Pete Batard 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64226): https://edk2.groups.io/g/devel/message/64226
Mute This Topic: https://groups.io/mt/76168434/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform][PATCH v1 7/7] Platforms/RaspberryPi: SMBIOS minor cleanup

[Pete Batard]

From what I could see, Andrei already sent a R-b for 1-6, thus:

On 2020.07.20 19:16, Samer El-Haj-Mahmoud wrote:

Minor code cleanup:
  - Update file header to list SBBR required/recommended tables
  - Rename DataSmbiosHande to DataSmbiosHandle
  - Remove SMBIOS_HANDLE_PI_RESERVED from Type 11 template for
consistency. This is already done in LogSmbiosData().

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 43 

  1 file changed, 25 insertions(+), 18 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
index d382797602ce..d955291c5bb7 100644
--- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
+++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -1,20 +1,27 @@
  /** @file
   *
- *  Static SMBIOS Table for ARM platform
+ *  Static SMBIOS Table for the RaspberryPi platform
   *  Derived from EmulatorPkg package
   *
- *  Note SMBIOS 2.7.1 Required structures:
- *  BIOS Information (Type 0)
- *  System Information (Type 1)
- *  Board Information (Type 2)
- *  System Enclosure (Type 3)
- *  Processor Information (Type 4) - CPU Driver
- *  Cache Information (Type 7) - For cache that is external to processor
- *  System Slots (Type 9) - If system has slots
- *  Physical Memory Array (Type 16)
- *  Memory Device (Type 17) - For each socketed system-memory Device
- *  Memory Array Mapped Address (Type 19) - One per contiguous block per 
Physical Memroy Array
- *  System Boot Information (Type 32)
+ *  Note - Arm SBBR ver 1.2 required and recommended SMBIOS structures:
+ *BIOS Information (Type 0)
+ *System Information (Type 1)
+ *Board Information (Type 2) - Recommended
+ *System Enclosure (Type 3)
+ *Processor Information (Type 4) - CPU Driver
+ *Cache Information (Type 7) - For cache that is external to processor
+ *Port Information (Type 8) - Recommended for platforms with physical ports
+ *System Slots (Type 9) - If system has slots
+ *OEM Strings (Type 11) - Recommended
+ *BIOS Language Information (Type 13) - Recommended
+ *System Event Log (Type 15) - Recommended (does not exit on RPi)
+ *Physical Memory Array (Type 16)
+ *Memory Device (Type 17) - For each socketed system-memory Device
+ *Memory Array Mapped Address (Type 19) - One per contiguous block per 
Physical Memroy Array
+ *System Boot Information (Type 32)
+ *IPMI Device Information (Type 38) - Required for platforms with IPMIv1.0 
BMC Host Interface (not applicable to RPi)
+ *Onboard Devices Extended Information (Type 41) - Recommended
+ *Redfish Host Interface (Type 42) - Required for platforms supporting 
Redfish Host Interface (not applicable to RPi)
   *
   *  Copyright (c) 2017-2018, Andrey Warkentin 
   *  Copyright (c) 2013, Linaro.org
@@ -480,7 +487,7 @@ CHAR8 *mSysSlotInfoType9Strings[] = {
  /
  
  SMBIOS_TABLE_TYPE11 mOemStringsType11 = {

-  { EFI_SMBIOS_TYPE_OEM_STRINGS, sizeof (SMBIOS_TABLE_TYPE11), 
SMBIOS_HANDLE_PI_RESERVED },
+  { EFI_SMBIOS_TYPE_OEM_STRINGS, sizeof (SMBIOS_TABLE_TYPE11), 0 },
1 // StringCount
  };
  CHAR8 *mOemStringsType11Strings[] = {
@@ -641,7 +648,7 @@ CHAR8 *mBootInfoType32Strings[] = {
 @param  TemplateFixed SMBIOS structure, required.
 @param  StringPack  Array of strings to convert to an SMBIOS string pack.
 NULL is OK.
-   @param  DataSmbiosHande  The new SMBIOS record handle .
+   @param  DataSmbiosHandle  The new SMBIOS record handle.
 NULL is OK.
  **/
  
@@ -650,7 +657,7 @@ EFIAPI

  LogSmbiosData (
IN  EFI_SMBIOS_TABLE_HEADER *Template,
IN  CHAR8   **StringPack,
-  OUT EFI_SMBIOS_HANDLE   *DataSmbiosHande
+  OUT EFI_SMBIOS_HANDLE   *DataSmbiosHandle
)
  {
EFI_STATUSStatus;
@@ -716,8 +723,8 @@ LogSmbiosData (
   Record
 );
  
-  if ((Status == EFI_SUCCESS) && (DataSmbiosHande != NULL)) {

-*DataSmbiosHande = SmbiosHandle;
+  if ((Status == EFI_SUCCESS) && (DataSmbiosHandle != NULL)) {
+*DataSmbiosHandle = SmbiosHandle;
}
  
ASSERT_EFI_ERROR (Status);




Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64114): https://edk2.groups.io/g/devel/message/64114
Mute This Topic: https://groups.io/mt/75687850/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Fix RPi4 GICC PMU PPI

[Pete Batard]

Adding a tested-by, since these are values that could potentially trip 
the custom handling that Windows seems to have of MADT, and I hadn't 
tested that yet.


Testing shows that Windows is happy with these new values, so with this:

On 2020.07.31 08:55, Pete Batard via groups.io wrote:

On 2020.07.28 22:00, Samer El-Haj-Mahmoud wrote:

Arm SBSA specification section ver 6.0, 4.1.5 defines specific PPI
values for certain standard interrupt IDs. The value for
"Performance Monitors Interrupt" needs to be 23.

REF: https://developer.arm.com/documentation/den0029/latest

This partially fixes SBSA test #11 ("Incorrect PPI value") reported in
https://github.com/pftf/RPi4/issues/74

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Platform/RaspberryPi/RPi4/RPi4.dsc | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc

index c481c3534263..00683afe96b9 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -433,10 +433,10 @@ [PcdsFixedAtBuild.common]
    gRaspberryPiTokenSpaceGuid.PcdGicInterruptInterfaceHBase|0xFF844000
    gRaspberryPiTokenSpaceGuid.PcdGicInterruptInterfaceVBase|0xFF846000
    gRaspberryPiTokenSpaceGuid.PcdGicGsivId|0x19
-  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq0|0x30
-  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq1|0x31
-  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq2|0x32
-  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq3|0x33
+  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq0|23
+  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq1|23
+  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq2|23
+  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq3|23
    #
    # Fixed CPU settings.



Reviewed-by: Pete Batard 


Tested-by: Pete Batard 








-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63672): https://edk2.groups.io/g/devel/message/63672
Mute This Topic: https://groups.io/mt/75853085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] EmbeddedPkg/TimeBaseLib: Add macros to get build year/month/day

[Pete Batard]

Hi Leif,

On 2020.08.03 13:09, Leif Lindholm wrote:

Hi Pete,

Well prodded (off-list).

I expect I saw that arrive, expected the corresponding RPi
resubmission to arrive shortly afterwards for me to test with and put
it soundly at the back of my mind. Presumably you were waiting for
this to be merged before resubmitting that one?


Yes. I tend to find it inconvenient to reference to work that has not 
yet been integrated, as I'm not sure how you're suppose to reference it. 
Should you point to an edk2-devel post in the commit message? In the 
cover letter? Something else?


As a result, provided the dependency should be simple enough to review 
independently, I prefer to alleviate that issue by just waiting for it 
to be integrated. But if that's a problem, I can certainly ensure that 
future co-dependent patches are submitted together.



Anyway:
Reviewed-by: Leif Lindholm 
Pushed as bbb8a8185838.


Thanks!

/Pete



Regards,

Leif

On Fri, Jul 24, 2020 at 17:37:42 +0100, Pete Batard wrote:

These can be used, for instance, to automate the population of an SMBIOS
Type 0 BIOS Release Date when building a UEFI firmware (which is how we
plan to use these macros for the Raspberry Pi platform).

These macros should work for any compiler that follows ISO/IEC 9899, but
we add a check for the compiler we have tested to be on the safe side.

Note that we decided against adding a #error or #warn for compilers that
haven't been validated, as we don't want to introduce breakage for people
who may already be using the header with something else than gcc, MSVC or
Clang. Instead, we expect those to send a patch that adds their compiler
to the list, once they have tested the macros there.

Signed-off-by: Pete Batard 
---
  EmbeddedPkg/Include/Library/TimeBaseLib.h | 32 
  1 file changed, 32 insertions(+)

diff --git a/EmbeddedPkg/Include/Library/TimeBaseLib.h 
b/EmbeddedPkg/Include/Library/TimeBaseLib.h
index 4103c89b3891..ee2f191d985b 100644
--- a/EmbeddedPkg/Include/Library/TimeBaseLib.h
+++ b/EmbeddedPkg/Include/Library/TimeBaseLib.h
@@ -12,6 +12,38 @@
  
  #include 
  
+//

+// Convenience macros to obtain a build date
+//
+// These macros should work for any compiler that follows ISO/IEC 9899,
+// in which case __DATE__ is defined as a "Mmm dd " 11 chars string,
+// but add an explicit filter for compilers that have been validated.
+//
+#if (defined(__GNUC__) || defined(_MSC_VER) || defined(__clang__))
+#define TIME_BUILD_YEAR  (__DATE__[7] == '?' ? 1900 \
+  : (((__DATE__[7] - '0') * 1000 )  \
+  + (__DATE__[8] - '0') * 100   \
+  + (__DATE__[9] - '0') * 10\
+  + __DATE__[10] - '0'))
+#define TIME_BUILD_MONTH ( __DATE__ [2] == '?' ? 1  \
+  : __DATE__ [2] == 'n' ? ( \
+__DATE__ [1] == 'a' ? 1 : 6)\
+  : __DATE__ [2] == 'b' ? 2 \
+  : __DATE__ [2] == 'r' ? ( \
+__DATE__ [0] == 'M' ? 3 : 4)\
+  : __DATE__ [2] == 'y' ? 5 \
+  : __DATE__ [2] == 'l' ? 7 \
+  : __DATE__ [2] == 'g' ? 8 \
+  : __DATE__ [2] == 'p' ? 9 \
+  : __DATE__ [2] == 't' ? 10\
+  : __DATE__ [2] == 'v' ? 11\
+  : 12)
+#define TIME_BUILD_DAY ( __DATE__[4] == '?' ? 1 \
+  : ((__DATE__[4] == ' ' ? 0 :  \
+((__DATE__[4] - '0') * 10)) \
+  + __DATE__[5] - '0'))
+#endif
+
  // Define EPOCH (1970-JANUARY-01) in the Julian Date representation
  #define EPOCH_JULIAN_DATE   2440588
  
--

2.21.0.windows.1




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63666): https://edk2.groups.io/g/devel/message/63666
Mute This Topic: https://groups.io/mt/75769904/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 1/1] Platforms/RaspberryPi: Fix BIOS Release Date and System Manufacturer

[Pete Batard]

Per SMBIOS specs, The Type 0 BIOS Release Date is not a free form field but
must be specified in a US middle-endian format (mm/dd/), so make sure
we populate it accordingly by using the recently introduced TimeBaseLib
macros. This is required for platforms like Windows, that fail to parse the
date otherwise.

Also, the system manufacturer should not be set to the same value as the
board manufacturer for the Type 1 strings, as, on the Raspberry Pi, this is
not representative of the actual manufacturer of the system, which is the
Raspberry Pi Foundation always.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 12 
++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
index d5fb843d43ce..ff7203585acb 100644
--- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
+++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -119,11 +119,12 @@ SMBIOS_TABLE_TYPE0 mBIOSInfoType0 = {
 
 CHAR8 mBiosVendor[128]  = "EDK2";
 CHAR8 mBiosVersion[128] = "EDK2-DEV";
+CHAR8 mBiosDate[12] = "00/00/";
 
 CHAR8 *mBIOSInfoType0Strings[] = {
   mBiosVendor,  // Vendor
   mBiosVersion, // Version
-  __DATE__ " " __TIME__,// Release Date
+  mBiosDate,// Release Date
   NULL
 };
 
@@ -149,7 +150,7 @@ CHAR8 mSysInfoSerial[sizeof (UINT64) * 2 + 1];
 CHAR8 mSysInfoSKU[sizeof (UINT64) * 2 + 1];
 
 CHAR8 *mSysInfoType1Strings[] = {
-  mSysInfoManufName,
+  "Raspberry Pi Foundation",
   mSysInfoProductName,
   mSysInfoVersionName,
   mSysInfoSerial,
@@ -626,6 +627,9 @@ BIOSInfoUpdateSmbiosType0 (
   INTN   i;
   INTN   State = 0;
   INTN   Value[2];
+  INTN   Year = TIME_BUILD_YEAR;
+  INTN   Month = TIME_BUILD_MONTH;
+  INTN   Day = TIME_BUILD_DAY;
 
   // Populate the Firmware major and minor.
   Status = mFwProtocol->GetFirmwareRevision ();
@@ -648,6 +652,10 @@ BIOSInfoUpdateSmbiosType0 (
 mBiosVendor, sizeof (mBiosVendor));
   UnicodeStrToAsciiStrS ((CHAR16*)PcdGetPtr (PcdFirmwareVersionString),
 mBiosVersion, sizeof (mBiosVersion));
+  ASSERT (Year >= 0 && Year <= );
+  ASSERT (Month >= 1 && Month <= 12);
+  ASSERT (Day >= 1 && Day <= 31);
+  AsciiSPrint (mBiosDate, sizeof (mBiosDate), "%02d/%02d/%04d", Month, Day, 
Year);
 
   // Look for a "x.y" numeric string anywhere in mBiosVersion and
   // try to parse it to populate the BIOS major and minor.
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63665): https://edk2.groups.io/g/devel/message/63665
Mute This Topic: https://groups.io/mt/75963950/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 0/1] Platforms/RaspberryPi: Fix BIOS Release Date and System Manufacturer

[Pete Batard]

Changes from v1:
* Use the newly introduced EmbeddedPkg/Include/Library/TimeBaseLib.h macros.

Pete Batard (1):
  Platforms/RaspberryPi: Fix BIOS Release Date and System Manufacturer

 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 12 
++--
 1 file changed, 10 insertions(+), 2 deletions(-)

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63664): https://edk2.groups.io/g/devel/message/63664
Mute This Topic: https://groups.io/mt/75963949/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdePkg: Remove code wrapped by DISABLE_NEW_DEPRECATED_INTERFACES

[Pete Batard]

And done for RPi in https://edk2.groups.io/g/devel/message/63661

Regards,

/Pete


On 2020.07.31 16:56, Marcin Wojtas wrote:

Hi Ard,


pt., 31 lip 2020 o 10:27 Ard Biesheuvel  napisał(a):


The reason PcdSet## was deprecated in the first place was because it cannot 
signal failure, whereas PcdSet##S can.

So please fix the affected platforms by capturing the returned status value, 
and at the very least, use ASSERT_EFI_ERROR() on it so we can spot any failures 
in DEBUG builds. Just swapping out one for the other kind of defeats the 
purpose.



Done: https://edk2.groups.io/g/devel/message/63577

Best regards,
Marcin



From: Pete Batard 
Sent: Friday, July 31, 2020 09:53
To: devel@edk2.groups.io ; liming@intel.com 
; m...@semihalf.com ; Leif Lindholm 

Cc: Zhang, Shenglei ; Ard Biesheuvel ; 
Kinney, Michael D ; Ming Huang 
Subject: Re: [edk2-devel] [PATCH] MdePkg: Remove code wrapped by 
DISABLE_NEW_DEPRECATED_INTERFACES

All,

Fix for Raspberry Pi platforms submitted at:
https://edk2.groups.io/g/devel/message/63554

Regards,

/Pete

On 2020.07.31 02:55, Liming Gao wrote:

Thanks Marcin.

Leif:
Is there the way to get the fix plan from the platform owner? If so, I can 
work the plan to merge this change.

Thanks
Liming
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Marcin Wojtas
Sent: 2020年7月31日 0:09
To: Leif Lindholm 
Cc: Gao, Liming ; devel@edk2.groups.io; Zhang, Shenglei 
; Ard Biesheuvel ; Kinney, Michael D 
; Ming Huang ; Pete Batard 
Subject: Re: [edk2-devel] [PATCH] MdePkg: Remove code wrapped by 
DISABLE_NEW_DEPRECATED_INTERFACES

Hi Leif,


śr., 29 lip 2020 o 15:35 Leif Lindholm  napisał(a):


Right, so the following platforms break once this patch is merged:

- AMD Overdrive, Overdrive 1000, Cello
- Hisilicon D03, D05, D06 (some of these due to binary drivers in
edk2-non-osi)
- Marvell Armada 78x0/80x0, MacchiatoBIN


Fix for Marvell platforms submitted:
https://edk2.groups.io/g/devel/message/63472

Best regards,
Marcin


- Raspberry Pi 3/4

I think this provides enough argument to push this patch at least
until after August stable tag.

As far as I can tell, all of these are due to the PcdSet And
UnicodeStrToAsciiStr functions/macros disappearing. Presumably these
should be replaced with their S-suffixed counterparts.

Maintainers/reviewers on cc. I'd appreciate if you could update and
sanity check your platforms and send out patches.

Best Regards,

Leif

On Wed, Jul 29, 2020 at 13:24:15 +0100, Leif Lindholm wrote:

Thanks Liming,

Yes, this does affect several ARM platforms. Currently running a build
test to determine just how many. My preference would be for a change
of this magnitude to go in just after a stable tag - what, if any, are
the plans for this patch?

Best Regards,

Leif

On Wed, Jul 29, 2020 at 07:55:09 +, Gao, Liming wrote:

Include Leif and Ard. This change may impact ARM platform.

Thanks
Liming
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Liming Gao
Sent: 2020年6月9日 21:08
To: Zhang, Shenglei ; devel@edk2.groups.io
Cc: Kinney, Michael D 
Subject: Re: [edk2-devel] [PATCH] MdePkg: Remove code wrapped by 
DISABLE_NEW_DEPRECATED_INTERFACES

Shenglei:
Please also remove the deprecated code in MdeModulePkg.

Thanks
Liming

-Original Message-
From: Zhang, Shenglei 
Sent: Friday, June 5, 2020 4:13 PM
To: devel@edk2.groups.io
Cc: Kinney, Michael D ; Gao, Liming 

Subject: [PATCH] MdePkg: Remove code wrapped by 
DISABLE_NEW_DEPRECATED_INTERFACES

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2777
Code wrapped by DISABLE_NEW_DEPRECATED_INTERFACES is deprecated.
So remove it.

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Shenglei Zhang 
---
   MdePkg/Library/BaseLib/String.c| 626 -
   MdePkg/Library/BasePcdLibNull/PcdLib.c | 361 --
   MdePkg/Library/BasePrintLib/PrintLib.c | 118 -
   MdePkg/Library/DxePcdLib/DxePcdLib.c   | 399 
   MdePkg/Library/PeiPcdLib/PeiPcdLib.c   | 397 
   MdePkg/Library/UefiLib/UefiLib.c   |  92 
   MdePkg/Include/Library/BaseLib.h   | 409 
   MdePkg/Include/Library/PcdLib.h| 520 
   MdePkg/Include/Library/PrintLib.h  | 110 -
   MdePkg/Include/Library/UefiLib.h   |  53 ---
   MdePkg/MdePkg.dsc  |   1 -
   11 files changed, 3086 deletions(-)

diff --git a/MdePkg/Library/BaseLib/String.c b/MdePkg/Library/BaseLib/String.c
index 45198373f25c..f4854f357e3a 100644
--- a/MdePkg/Library/BaseLib/String.c
+++ b/MdePkg/Library/BaseLib/String.c
@@ -8,135 +8,6 @@

   #include "BaseLibInternals.h"

-#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
-
-/**
-  [ATTENTION] This function will be deprecated for security reason.
-
-  Copies one Null-terminated Unicode string to another Null-terminated Unicode
-  string and returns the new Unicode string.
-
-  This function copies the contents of t

[edk2-devel] [edk2-platforms][PATCH v2 1/1] Platforms/RaspberryPi: Switch to PcdSet##S

[Pete Batard]

According to the bug:
https://bugzilla.tianocore.org/show_bug.cgi?id=2777
the deprecated code under DISABLE_NEW_DEPRECATED_INTERFACES
will be removed, which will result in compilation breakage
of the Raspberry Pi platforms. Prevent that by switching to
the different PcdSet API.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c   | 51 +---
 Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.c |  8 +--
 2 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index bab494a7c254..af54136aded6 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -202,7 +202,8 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdCpuClock, PcdGet32 (PcdCpuClock));
+Status = PcdSet32S (PcdCpuClock, PcdGet32 (PcdCpuClock));
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (UINT32);
@@ -210,25 +211,30 @@ SetupVariables (
 ,
 NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdCustomCpuClock, PcdGet32 (PcdCustomCpuClock));
+Status = PcdSet32S (PcdCustomCpuClock, PcdGet32 (PcdCustomCpuClock));
+ASSERT_EFI_ERROR (Status);
   }
 
   if (mModelFamily >= 4 && mModelInstalledMB > 3 * 1024) {
 /*
  * This allows changing PcdRamLimitTo3GB in forms.
  */
-PcdSet32 (PcdRamMoreThan3GB, 1);
+Status = PcdSet32S (PcdRamMoreThan3GB, 1);
+ASSERT_EFI_ERROR (Status);
 
 Size = sizeof (UINT32);
 Status = gRT->GetVariable (L"RamLimitTo3GB",
,
NULL, , );
 if (EFI_ERROR (Status)) {
-  PcdSet32 (PcdRamLimitTo3GB, PcdGet32 (PcdRamLimitTo3GB));
+  Status = PcdSet32S (PcdRamLimitTo3GB, PcdGet32 (PcdRamLimitTo3GB));
+  ASSERT_EFI_ERROR (Status);
 }
   } else {
-PcdSet32 (PcdRamMoreThan3GB, 0);
-PcdSet32 (PcdRamLimitTo3GB, 0);
+Status = PcdSet32S (PcdRamMoreThan3GB, 0);
+ASSERT_EFI_ERROR (Status);
+Status = PcdSet32S (PcdRamLimitTo3GB, 0);
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (UINT32);
@@ -236,7 +242,8 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdSystemTableMode, PcdGet32 (PcdSystemTableMode));
+Status = PcdSet32S (PcdSystemTableMode, PcdGet32 (PcdSystemTableMode));
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof(AssetTagVar);
@@ -260,7 +267,8 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdSdIsArasan, PcdGet32 (PcdSdIsArasan));
+Status = PcdSet32S (PcdSdIsArasan, PcdGet32 (PcdSdIsArasan));
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (UINT32);
@@ -268,7 +276,8 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdMmcDisableMulti, PcdGet32 (PcdMmcDisableMulti));
+Status = PcdSet32S (PcdMmcDisableMulti, PcdGet32 (PcdMmcDisableMulti));
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (UINT32);
@@ -276,7 +285,8 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdMmcForce1Bit, PcdGet32 (PcdMmcForce1Bit));
+Status = PcdSet32S (PcdMmcForce1Bit, PcdGet32 (PcdMmcForce1Bit));
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (UINT32);
@@ -284,7 +294,8 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdMmcForceDefaultSpeed, PcdGet32 (PcdMmcForceDefaultSpeed));
+Status = PcdSet32S (PcdMmcForceDefaultSpeed, PcdGet32 
(PcdMmcForceDefaultSpeed));
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (UINT32);
@@ -292,7 +303,8 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdMmcSdDefaultSpeedMHz, PcdGet32 (PcdMmcSdDefaultSpeedMHz));
+Status = PcdSet32S (PcdMmcSdDefaultSpeedMHz, PcdGet32 
(PcdMmcSdDefaultSpeedMHz));
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (UINT32);
@@ -300,7 +312,8 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdMmcSdHighSpeedMHz, PcdGet32 (PcdMmcSdHighSpeedMHz));
+Status = PcdSet32S (PcdMmcSdHighSpeedMHz, PcdGet32 (PcdMmcSdHighSpeedMHz));
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (UINT32);
@@ -308,7 +321,8 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdDebugEnableJTAG, PcdGet32 (PcdDebugEnableJTAG));
+Status = PcdSet32S (PcdDebugEnableJTAG, PcdGet32 (PcdDebugEnableJTAG));
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (UINT8);
@@ -316

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Fix RPi4 GICC PMU PPI

[Pete Batard]

On 2020.07.28 22:00, Samer El-Haj-Mahmoud wrote:

Arm SBSA specification section ver 6.0, 4.1.5 defines specific PPI
values for certain standard interrupt IDs. The value for
"Performance Monitors Interrupt" needs to be 23.

REF: https://developer.arm.com/documentation/den0029/latest

This partially fixes SBSA test #11 ("Incorrect PPI value") reported in
https://github.com/pftf/RPi4/issues/74

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Platform/RaspberryPi/RPi4/RPi4.dsc | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index c481c3534263..00683afe96b9 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -433,10 +433,10 @@ [PcdsFixedAtBuild.common]
gRaspberryPiTokenSpaceGuid.PcdGicInterruptInterfaceHBase|0xFF844000
gRaspberryPiTokenSpaceGuid.PcdGicInterruptInterfaceVBase|0xFF846000
gRaspberryPiTokenSpaceGuid.PcdGicGsivId|0x19
-  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq0|0x30
-  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq1|0x31
-  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq2|0x32
-  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq3|0x33
+  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq0|23
+  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq1|23
+  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq2|23
+  gRaspberryPiTokenSpaceGuid.PcdGicPmuIrq3|23
  
#

# Fixed CPU settings.



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63556): https://edk2.groups.io/g/devel/message/63556
Mute This Topic: https://groups.io/mt/75853085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdePkg: Remove code wrapped by DISABLE_NEW_DEPRECATED_INTERFACES

[Pete Batard]

All,

Fix for Raspberry Pi platforms submitted at:
https://edk2.groups.io/g/devel/message/63554

Regards,

/Pete

On 2020.07.31 02:55, Liming Gao wrote:

Thanks Marcin.

Leif:
   Is there the way to get the fix plan from the platform owner? If so, I can 
work the plan to merge this change.

Thanks
Liming
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Marcin Wojtas
Sent: 2020年7月31日 0:09
To: Leif Lindholm 
Cc: Gao, Liming ; devel@edk2.groups.io; Zhang, Shenglei 
; Ard Biesheuvel ; Kinney, Michael D 
; Ming Huang ; Pete Batard 
Subject: Re: [edk2-devel] [PATCH] MdePkg: Remove code wrapped by 
DISABLE_NEW_DEPRECATED_INTERFACES

Hi Leif,


śr., 29 lip 2020 o 15:35 Leif Lindholm  napisał(a):


Right, so the following platforms break once this patch is merged:

- AMD Overdrive, Overdrive 1000, Cello
- Hisilicon D03, D05, D06 (some of these due to binary drivers in
   edk2-non-osi)
- Marvell Armada 78x0/80x0, MacchiatoBIN


Fix for Marvell platforms submitted:
https://edk2.groups.io/g/devel/message/63472

Best regards,
Marcin


- Raspberry Pi 3/4

I think this provides enough argument to push this patch at least
until after August stable tag.

As far as I can tell, all of these are due to the PcdSet And
UnicodeStrToAsciiStr functions/macros disappearing. Presumably these
should be replaced with their S-suffixed counterparts.

Maintainers/reviewers on cc. I'd appreciate if you could update and
sanity check your platforms and send out patches.

Best Regards,

Leif

On Wed, Jul 29, 2020 at 13:24:15 +0100, Leif Lindholm wrote:

Thanks Liming,

Yes, this does affect several ARM platforms. Currently running a build
test to determine just how many. My preference would be for a change
of this magnitude to go in just after a stable tag - what, if any, are
the plans for this patch?

Best Regards,

Leif

On Wed, Jul 29, 2020 at 07:55:09 +, Gao, Liming wrote:

Include Leif and Ard. This change may impact ARM platform.

Thanks
Liming
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Liming Gao
Sent: 2020年6月9日 21:08
To: Zhang, Shenglei ; devel@edk2.groups.io
Cc: Kinney, Michael D 
Subject: Re: [edk2-devel] [PATCH] MdePkg: Remove code wrapped by 
DISABLE_NEW_DEPRECATED_INTERFACES

Shenglei:
   Please also remove the deprecated code in MdeModulePkg.

Thanks
Liming

-Original Message-
From: Zhang, Shenglei 
Sent: Friday, June 5, 2020 4:13 PM
To: devel@edk2.groups.io
Cc: Kinney, Michael D ; Gao, Liming 

Subject: [PATCH] MdePkg: Remove code wrapped by 
DISABLE_NEW_DEPRECATED_INTERFACES

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2777
Code wrapped by DISABLE_NEW_DEPRECATED_INTERFACES is deprecated.
So remove it.

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Shenglei Zhang 
---
  MdePkg/Library/BaseLib/String.c| 626 -
  MdePkg/Library/BasePcdLibNull/PcdLib.c | 361 --
  MdePkg/Library/BasePrintLib/PrintLib.c | 118 -
  MdePkg/Library/DxePcdLib/DxePcdLib.c   | 399 
  MdePkg/Library/PeiPcdLib/PeiPcdLib.c   | 397 
  MdePkg/Library/UefiLib/UefiLib.c   |  92 
  MdePkg/Include/Library/BaseLib.h   | 409 
  MdePkg/Include/Library/PcdLib.h| 520 
  MdePkg/Include/Library/PrintLib.h  | 110 -
  MdePkg/Include/Library/UefiLib.h   |  53 ---
  MdePkg/MdePkg.dsc  |   1 -
  11 files changed, 3086 deletions(-)

diff --git a/MdePkg/Library/BaseLib/String.c b/MdePkg/Library/BaseLib/String.c
index 45198373f25c..f4854f357e3a 100644
--- a/MdePkg/Library/BaseLib/String.c
+++ b/MdePkg/Library/BaseLib/String.c
@@ -8,135 +8,6 @@

  #include "BaseLibInternals.h"

-#ifndef DISABLE_NEW_DEPRECATED_INTERFACES
-
-/**
-  [ATTENTION] This function will be deprecated for security reason.
-
-  Copies one Null-terminated Unicode string to another Null-terminated Unicode
-  string and returns the new Unicode string.
-
-  This function copies the contents of the Unicode string Source to the Unicode
-  string Destination, and returns Destination. If Source and Destination
-  overlap, then the results are undefined.
-
-  If Destination is NULL, then ASSERT().
-  If Destination is not aligned on a 16-bit boundary, then ASSERT().
-  If Source is NULL, then ASSERT().
-  If Source is not aligned on a 16-bit boundary, then ASSERT().
-  If Source and Destination overlap, then ASSERT().
-  If PcdMaximumUnicodeStringLength is not zero, and Source contains more than
-  PcdMaximumUnicodeStringLength Unicode characters, not including the
-  Null-terminator, then ASSERT().
-
-  @param  Destination A pointer to a Null-terminated Unicode string.
-  @param  Source  A pointer to a Null-terminated Unicode string.
-
-  @return Destination.
-
-**/
-CHAR16 *
-EFIAPI
-StrCpy (
-  OUT CHAR16*Destination,
-  IN  CONST CHAR16  *Source
-  )
-{
-  CHAR16*ReturnValue;
-
-  //
-  // D

[edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RaspberryPi: Switch to PcdSet##S

[Pete Batard]

According to the bug:
https://bugzilla.tianocore.org/show_bug.cgi?id=2777
the deprecated code under DISABLE_NEW_DEPRECATED_INTERFACES
will be removed, which will result in compilation breakage
of the Raspberry Pi platforms. Prevent that by switching to
the different PcdSet API.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c   | 34 ++--
 Platform/RaspberryPi/Drivers/DisplayDxe/DisplayDxe.c |  4 +--
 2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index bab494a7c254..9f3372a7631d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -202,7 +202,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdCpuClock, PcdGet32 (PcdCpuClock));
+PcdSet32S (PcdCpuClock, PcdGet32 (PcdCpuClock));
   }
 
   Size = sizeof (UINT32);
@@ -210,25 +210,25 @@ SetupVariables (
 ,
 NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdCustomCpuClock, PcdGet32 (PcdCustomCpuClock));
+PcdSet32S (PcdCustomCpuClock, PcdGet32 (PcdCustomCpuClock));
   }
 
   if (mModelFamily >= 4 && mModelInstalledMB > 3 * 1024) {
 /*
  * This allows changing PcdRamLimitTo3GB in forms.
  */
-PcdSet32 (PcdRamMoreThan3GB, 1);
+PcdSet32S (PcdRamMoreThan3GB, 1);
 
 Size = sizeof (UINT32);
 Status = gRT->GetVariable (L"RamLimitTo3GB",
,
NULL, , );
 if (EFI_ERROR (Status)) {
-  PcdSet32 (PcdRamLimitTo3GB, PcdGet32 (PcdRamLimitTo3GB));
+  PcdSet32S (PcdRamLimitTo3GB, PcdGet32 (PcdRamLimitTo3GB));
 }
   } else {
-PcdSet32 (PcdRamMoreThan3GB, 0);
-PcdSet32 (PcdRamLimitTo3GB, 0);
+PcdSet32S (PcdRamMoreThan3GB, 0);
+PcdSet32S (PcdRamLimitTo3GB, 0);
   }
 
   Size = sizeof (UINT32);
@@ -236,7 +236,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdSystemTableMode, PcdGet32 (PcdSystemTableMode));
+PcdSet32S (PcdSystemTableMode, PcdGet32 (PcdSystemTableMode));
   }
 
   Size = sizeof(AssetTagVar);
@@ -260,7 +260,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdSdIsArasan, PcdGet32 (PcdSdIsArasan));
+PcdSet32S (PcdSdIsArasan, PcdGet32 (PcdSdIsArasan));
   }
 
   Size = sizeof (UINT32);
@@ -268,7 +268,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdMmcDisableMulti, PcdGet32 (PcdMmcDisableMulti));
+PcdSet32S (PcdMmcDisableMulti, PcdGet32 (PcdMmcDisableMulti));
   }
 
   Size = sizeof (UINT32);
@@ -276,7 +276,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdMmcForce1Bit, PcdGet32 (PcdMmcForce1Bit));
+PcdSet32S (PcdMmcForce1Bit, PcdGet32 (PcdMmcForce1Bit));
   }
 
   Size = sizeof (UINT32);
@@ -284,7 +284,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdMmcForceDefaultSpeed, PcdGet32 (PcdMmcForceDefaultSpeed));
+PcdSet32S (PcdMmcForceDefaultSpeed, PcdGet32 (PcdMmcForceDefaultSpeed));
   }
 
   Size = sizeof (UINT32);
@@ -292,7 +292,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdMmcSdDefaultSpeedMHz, PcdGet32 (PcdMmcSdDefaultSpeedMHz));
+PcdSet32S (PcdMmcSdDefaultSpeedMHz, PcdGet32 (PcdMmcSdDefaultSpeedMHz));
   }
 
   Size = sizeof (UINT32);
@@ -300,7 +300,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdMmcSdHighSpeedMHz, PcdGet32 (PcdMmcSdHighSpeedMHz));
+PcdSet32S (PcdMmcSdHighSpeedMHz, PcdGet32 (PcdMmcSdHighSpeedMHz));
   }
 
   Size = sizeof (UINT32);
@@ -308,7 +308,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdDebugEnableJTAG, PcdGet32 (PcdDebugEnableJTAG));
+PcdSet32S (PcdDebugEnableJTAG, PcdGet32 (PcdDebugEnableJTAG));
   }
 
   Size = sizeof (UINT8);
@@ -316,7 +316,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet8 (PcdDisplayEnableScaledVModes, PcdGet8 
(PcdDisplayEnableScaledVModes));
+PcdSet8S (PcdDisplayEnableScaledVModes, PcdGet8 
(PcdDisplayEnableScaledVModes));
   }
 
   Size = sizeof (UINT32);
@@ -324,7 +324,7 @@ SetupVariables (
   ,
   NULL, , );
   if (EFI_ERROR (Status)) {
-PcdSet32 (PcdDisplayEnableSShot, PcdGet32 (PcdDisplayEnableSShot));
+PcdSet32S (PcdDisplayEnableSShot, PcdGet32 (PcdDisplayEnableSShot));
   }
 
   if (mModelFami

[edk2-devel] [PATCH 1/1] EmbeddedPkg/TimeBaseLib: Add macros to get build year/month/day

[Pete Batard]

These can be used, for instance, to automate the population of an SMBIOS
Type 0 BIOS Release Date when building a UEFI firmware (which is how we
plan to use these macros for the Raspberry Pi platform).

These macros should work for any compiler that follows ISO/IEC 9899, but
we add a check for the compiler we have tested to be on the safe side.

Note that we decided against adding a #error or #warn for compilers that
haven't been validated, as we don't want to introduce breakage for people
who may already be using the header with something else than gcc, MSVC or
Clang. Instead, we expect those to send a patch that adds their compiler
to the list, once they have tested the macros there.

Signed-off-by: Pete Batard 
---
 EmbeddedPkg/Include/Library/TimeBaseLib.h | 32 
 1 file changed, 32 insertions(+)

diff --git a/EmbeddedPkg/Include/Library/TimeBaseLib.h 
b/EmbeddedPkg/Include/Library/TimeBaseLib.h
index 4103c89b3891..ee2f191d985b 100644
--- a/EmbeddedPkg/Include/Library/TimeBaseLib.h
+++ b/EmbeddedPkg/Include/Library/TimeBaseLib.h
@@ -12,6 +12,38 @@
 
 #include 
 
+//
+// Convenience macros to obtain a build date
+//
+// These macros should work for any compiler that follows ISO/IEC 9899,
+// in which case __DATE__ is defined as a "Mmm dd " 11 chars string,
+// but add an explicit filter for compilers that have been validated.
+//
+#if (defined(__GNUC__) || defined(_MSC_VER) || defined(__clang__))
+#define TIME_BUILD_YEAR  (__DATE__[7] == '?' ? 1900 \
+  : (((__DATE__[7] - '0') * 1000 )  \
+  + (__DATE__[8] - '0') * 100   \
+  + (__DATE__[9] - '0') * 10\
+  + __DATE__[10] - '0'))
+#define TIME_BUILD_MONTH ( __DATE__ [2] == '?' ? 1  \
+  : __DATE__ [2] == 'n' ? ( \
+__DATE__ [1] == 'a' ? 1 : 6)\
+  : __DATE__ [2] == 'b' ? 2 \
+  : __DATE__ [2] == 'r' ? ( \
+__DATE__ [0] == 'M' ? 3 : 4)\
+  : __DATE__ [2] == 'y' ? 5 \
+  : __DATE__ [2] == 'l' ? 7 \
+  : __DATE__ [2] == 'g' ? 8 \
+  : __DATE__ [2] == 'p' ? 9 \
+  : __DATE__ [2] == 't' ? 10\
+  : __DATE__ [2] == 'v' ? 11\
+  : 12)
+#define TIME_BUILD_DAY ( __DATE__[4] == '?' ? 1 \
+  : ((__DATE__[4] == ' ' ? 0 :  \
+((__DATE__[4] - '0') * 10)) \
+  + __DATE__[5] - '0'))
+#endif
+
 // Define EPOCH (1970-JANUARY-01) in the Julian Date representation
 #define EPOCH_JULIAN_DATE   2440588
 
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#63251): https://edk2.groups.io/g/devel/message/63251
Mute This Topic: https://groups.io/mt/75769904/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RaspberryPi: Fix BIOS Release Date and System Manufacturer

[Pete Batard]

Hi Andrew,

On 2020.07.23 18:15, Andrew Fish wrote:



On Jul 23, 2020, at 8:47 AM, Leif Lindholm <mailto:l...@nuviainc.com>> wrote:


Hi Pete,

On Thu, Jul 23, 2020 at 15:38:55 +0100, Pete Batard wrote:

@@ -626,6 +627,28 @@ BIOSInfoUpdateSmbiosType0 (
   INTN   i;
   INTN   State = 0;
   INTN   Value[2];
+  INTN   Year = (__DATE__[7] == '?' ? 1900  \
+   : (((__DATE__[7] - '0') * 1000 ) \
+   + (__DATE__[8] - '0') * 100  \
+   + (__DATE__[9] - '0') * 10   \
+   + __DATE__[10] - '0'));
+  INTN   Month = ( __DATE__ [2] == '?' ? 1  \
+   : __DATE__ [2] == 'n' ? (    \
+ __DATE__ [1] == 'a' ? 1 : 6)   \
+   : __DATE__ [2] == 'b' ? 2    \
+   : __DATE__ [2] == 'r' ? (    \
+ __DATE__ [0] == 'M' ? 3 : 4)   \
+   : __DATE__ [2] == 'y' ? 5    \
+   : __DATE__ [2] == 'l' ? 7    \
+   : __DATE__ [2] == 'g' ? 8    \
+   : __DATE__ [2] == 'p' ? 9    \
+   : __DATE__ [2] == 't' ? 10   \
+   : __DATE__ [2] == 'v' ? 11   \
+   : 12);
+  INTN   Day = ( __DATE__[4] == '?' ? 1 \
+   : ((__DATE__[4] == ' ' ? 0 : \
+ ((__DATE__[4] - '0') * 10))    \
+   + __DATE__[5] - '0'));


So, this hunk is very neat, but nigh-on unreviewable.
I.e. we should defintely have it - but only once.

Could you break this up into some macros to go into some generic
helper lib? (I don't have a better idea than EmbeddedPkg TimeBaseLib,
but then that is already included in this module.)


So you would like to have a set of macros like:
TIME_GET_BUILD_YEAR, TIME_GET_BUILD_MONTH, TIME_GET_BUILD_DAY in
TimeBaseLib.h that perform the above?


Would you be OK to break that snippet out separate?


I think that's a good idea, especially as there is a potential underlying
issue with the __DATE__ format being specific to each compiler, so we
probably want to handle compiler detection somewhere, preferably 
globally.
For instance, the Intel compiler's __DATE__ format would not work 
with the

above, so I'll add some "vetted compiler" detection for the macros.


Yes, thanks.
A friendly "your compiler probably won't know what to do with this"
#error would be friendlier than whatever non-GCC/clang would generate
on encountering this.



Leif,

I was thinking the "Mmm dd ” form of __DATE__ was standard.


Just FYI, this is where I found that ICC might use something other than 
Mmm dd :


https://software.intel.com/content/www/us/en/develop/documentation/cpp-compiler-developer-guide-and-reference/top/compiler-reference/macros/iso-standard-predefined-macros.html

However, I am seeing information that ISO/IEC 9899, as far back as C99, 
does define __DATE__ as "Mmm dd ", and I'm starting to think, since 
the intel doc mentions an 11 character date, whereas "mm dd " is 
only 10 chars, and it's supposed to highlight ISO compliance, that this 
might be an unfortunate typo on the intel web site.


I don't have ICC installed at the moment, so someone may want to check 
that ICC does indeed produce "Mmm dd ".


Maybe 
all we need is a compile time assert that checks the format?


|6.10.8.1 Mandatory macros 1 The following macro names shall be defined 
by the implementation: _ _DATE_ _ The date of translation of the 
preprocessing translation unit: a character string literal of the form 
"Mmm dd ", where the names of the months are the same as those 
generated by the asctime function, and the first character of dd is a 
space character if the value is less than 10. If the date of translation 
is not available, an implementation-defined valid date shall be supplied|


It seems likely some compilers had an alternate version and chose not to 
change it and break existing code when the format got standardized. You 
would hope those compilers had some kind of optional strict ANSI flag or 
some such….


If it turns out that the ICC documentation is only a typo, then I would 
think that the need for an ASSERT might be less important.


Regards,

/Pete



Thanks,

Andrew Fish

The one thing I am not planning to look into is that, of course, as 
long as
you don't explicitly force the compiler to rebuild the sources where 
these

macros are used, then you may end up with a very obsolete build date
compared to the actual date of your last re-build.


Yeah, that's fine.


But that's mostly because
I don't think there exists a generic solution we can ise to force
recompilation of a file that uses a specific macro and also because 
our main
goal with these is to ensure that the Pi firmwares, that we produce 
through

AppVeyor, have a proper build date, and AppVeyor builds are are always
clean.


Yeah, I really don't care about that.
Or the flipside, where someone modifies only (say) the Smbios
populating code a month after they built the rest of the tree.

If someone wants to pu

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RaspberryPi: Fix BIOS Release Date and System Manufacturer

[Pete Batard]

Hi Leif,

On 2020.07.23 12:08, Leif Lindholm wrote:

On Mon, Jul 20, 2020 at 17:15:07 +0100, Pete Batard wrote:

Per SMBIOS specs, The Type 0 BIOS Release Date is not a free form field but
must be specified in a US middle-endian format (mm/dd/), so make sure
we populate it accordingly by converting gcc's __DATE__ string. This is
required for platforms like Windows, that fail to parse the date otherwise.

Also, the system manufacturer should not be set to the same value as the
board manufacturer for the Type 1 strings, as, on the Raspberry Pi, this is
not representative of the actual manufacturer of the system, which is the
Raspberry Pi Foundation always.

It should be noted that we do not expect other compilers than ones using
a __DATE__ format similar to gcc's to be used for the foreseeable future.

Signed-off-by: Pete Batard 
---
  Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 31 
++--
  1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
index d5fb843d43ce..fb775d00feba 100644
--- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
+++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -119,11 +119,12 @@ SMBIOS_TABLE_TYPE0 mBIOSInfoType0 = {
  
  CHAR8 mBiosVendor[128]  = "EDK2";

  CHAR8 mBiosVersion[128] = "EDK2-DEV";
+CHAR8 mBiosDate[12] = "00/00/";
  
  CHAR8 *mBIOSInfoType0Strings[] = {

mBiosVendor,  // Vendor
mBiosVersion, // Version
-  __DATE__ " " __TIME__,// Release Date
+  mBiosDate,// Release Date
NULL
  };
  
@@ -149,7 +150,7 @@ CHAR8 mSysInfoSerial[sizeof (UINT64) * 2 + 1];

  CHAR8 mSysInfoSKU[sizeof (UINT64) * 2 + 1];
  
  CHAR8 *mSysInfoType1Strings[] = {

-  mSysInfoManufName,
+  "Raspberry Pi Foundation",
mSysInfoProductName,
mSysInfoVersionName,
mSysInfoSerial,
@@ -626,6 +627,28 @@ BIOSInfoUpdateSmbiosType0 (
INTN   i;
INTN   State = 0;
INTN   Value[2];
+  INTN   Year = (__DATE__[7] == '?' ? 1900  \
+   : (((__DATE__[7] - '0') * 1000 ) \
+   + (__DATE__[8] - '0') * 100  \
+   + (__DATE__[9] - '0') * 10   \
+   + __DATE__[10] - '0'));
+  INTN   Month = ( __DATE__ [2] == '?' ? 1  \
+   : __DATE__ [2] == 'n' ? (\
+ __DATE__ [1] == 'a' ? 1 : 6)   \
+   : __DATE__ [2] == 'b' ? 2\
+   : __DATE__ [2] == 'r' ? (\
+ __DATE__ [0] == 'M' ? 3 : 4)   \
+   : __DATE__ [2] == 'y' ? 5\
+   : __DATE__ [2] == 'l' ? 7\
+   : __DATE__ [2] == 'g' ? 8\
+   : __DATE__ [2] == 'p' ? 9\
+   : __DATE__ [2] == 't' ? 10   \
+   : __DATE__ [2] == 'v' ? 11   \
+   : 12);
+  INTN   Day = ( __DATE__[4] == '?' ? 1 \
+   : ((__DATE__[4] == ' ' ? 0 : \
+ ((__DATE__[4] - '0') * 10))\
+   + __DATE__[5] - '0'));


So, this hunk is very neat, but nigh-on unreviewable.
I.e. we should defintely have it - but only once.

Could you break this up into some macros to go into some generic
helper lib? (I don't have a better idea than EmbeddedPkg TimeBaseLib,
but then that is already included in this module.)


So you would like to have a set of macros like:
TIME_GET_BUILD_YEAR, TIME_GET_BUILD_MONTH, TIME_GET_BUILD_DAY in 
TimeBaseLib.h that perform the above?



Would you be OK to break that snippet out separate?


I think that's a good idea, especially as there is a potential 
underlying issue with the __DATE__ format being specific to each 
compiler, so we probably want to handle compiler detection somewhere, 
preferably globally. For instance, the Intel compiler's __DATE__ format 
would not work with the above, so I'll add some "vetted compiler" 
detection for the macros.


The one thing I am not planning to look into is that, of course, as long 
as you don't explicitly force the compiler to rebuild the sources where 
these macros are used, then you may end up with a very obsolete build 
date compared to the actual date of your last re-build. But that's 
mostly because I don't think there exists a generic solution we can ise 
to force recompilation of a file that uses a specific macro and also 
because our main goal with these is to ensure that the Pi firmwares, 
that we produce through AppVeyor, have a proper build date, and AppVeyor 
builds are are always clean.


I'll send an EDK2 patch for the macros, and then a revised patch for 
this when I get a chance.


Regards,

/Pete



/
 Leif


// Populate the Firmware major and minor.
Status = mFwProtocol->GetFirmwareRevision ();
@@ -648,6 +671,10 @@ BIOSInfoUpdateSmbiosType0 (
  mBiosVendor, sizeof (mBiosVendor));
UnicodeStrToAsciiStrS ((C

[edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RaspberryPi: Fix BIOS Release Date and System Manufacturer

[Pete Batard]

Per SMBIOS specs, The Type 0 BIOS Release Date is not a free form field but
must be specified in a US middle-endian format (mm/dd/), so make sure
we populate it accordingly by converting gcc's __DATE__ string. This is
required for platforms like Windows, that fail to parse the date otherwise.

Also, the system manufacturer should not be set to the same value as the
board manufacturer for the Type 1 strings, as, on the Raspberry Pi, this is
not representative of the actual manufacturer of the system, which is the
Raspberry Pi Foundation always.

It should be noted that we do not expect other compilers than ones using
a __DATE__ format similar to gcc's to be used for the foreseeable future.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 31 
++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
index d5fb843d43ce..fb775d00feba 100644
--- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
+++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -119,11 +119,12 @@ SMBIOS_TABLE_TYPE0 mBIOSInfoType0 = {
 
 CHAR8 mBiosVendor[128]  = "EDK2";
 CHAR8 mBiosVersion[128] = "EDK2-DEV";
+CHAR8 mBiosDate[12] = "00/00/";
 
 CHAR8 *mBIOSInfoType0Strings[] = {
   mBiosVendor,  // Vendor
   mBiosVersion, // Version
-  __DATE__ " " __TIME__,// Release Date
+  mBiosDate,// Release Date
   NULL
 };
 
@@ -149,7 +150,7 @@ CHAR8 mSysInfoSerial[sizeof (UINT64) * 2 + 1];
 CHAR8 mSysInfoSKU[sizeof (UINT64) * 2 + 1];
 
 CHAR8 *mSysInfoType1Strings[] = {
-  mSysInfoManufName,
+  "Raspberry Pi Foundation",
   mSysInfoProductName,
   mSysInfoVersionName,
   mSysInfoSerial,
@@ -626,6 +627,28 @@ BIOSInfoUpdateSmbiosType0 (
   INTN   i;
   INTN   State = 0;
   INTN   Value[2];
+  INTN   Year = (__DATE__[7] == '?' ? 1900  \
+   : (((__DATE__[7] - '0') * 1000 ) \
+   + (__DATE__[8] - '0') * 100  \
+   + (__DATE__[9] - '0') * 10   \
+   + __DATE__[10] - '0'));
+  INTN   Month = ( __DATE__ [2] == '?' ? 1  \
+   : __DATE__ [2] == 'n' ? (\
+ __DATE__ [1] == 'a' ? 1 : 6)   \
+   : __DATE__ [2] == 'b' ? 2\
+   : __DATE__ [2] == 'r' ? (\
+ __DATE__ [0] == 'M' ? 3 : 4)   \
+   : __DATE__ [2] == 'y' ? 5\
+   : __DATE__ [2] == 'l' ? 7\
+   : __DATE__ [2] == 'g' ? 8\
+   : __DATE__ [2] == 'p' ? 9\
+   : __DATE__ [2] == 't' ? 10   \
+   : __DATE__ [2] == 'v' ? 11   \
+   : 12);
+  INTN   Day = ( __DATE__[4] == '?' ? 1 \
+   : ((__DATE__[4] == ' ' ? 0 : \
+ ((__DATE__[4] - '0') * 10))\
+   + __DATE__[5] - '0'));
 
   // Populate the Firmware major and minor.
   Status = mFwProtocol->GetFirmwareRevision ();
@@ -648,6 +671,10 @@ BIOSInfoUpdateSmbiosType0 (
 mBiosVendor, sizeof (mBiosVendor));
   UnicodeStrToAsciiStrS ((CHAR16*)PcdGetPtr (PcdFirmwareVersionString),
 mBiosVersion, sizeof (mBiosVersion));
+  ASSERT (Year >= 0 && Year <= );
+  ASSERT (Month >= 1 && Month <= 12);
+  ASSERT (Day >= 1 && Day <= 31);
+  AsciiSPrint (mBiosDate, sizeof (mBiosDate), "%02d/%02d/%04d", Month, Day, 
Year);
 
   // Look for a "x.y" numeric string anywhere in mBiosVersion and
   // try to parse it to populate the BIOS major and minor.
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#62851): https://edk2.groups.io/g/devel/message/62851
Mute This Topic: https://groups.io/mt/75685073/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform][PATCH v1 2/2] Platforms/RaspberryPi: Set RPi3 Language supported to English

[Pete Batard]

On 2020.07.19 00:04, Samer El-Haj-Mahmoud wrote:

Set the supported RPi3 platform language to English (US),
and remove French.

This fixes https://github.com/pftf/RPi4/issues/35

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Platform/RaspberryPi/RPi3/RPi3.dsc | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc 
b/Platform/RaspberryPi/RPi3/RPi3.dsc
index e448bbc66156..0998d8366ca9 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -1,6 +1,6 @@
  # @file
  #
-#  Copyright (c) 2011 - 2019, ARM Limited. All rights reserved.
+#  Copyright (c) 2011 - 2020, ARM Limited. All rights reserved.
  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
  #  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
  #  Copyright (c) 2017 - 2018, Andrei Warkentin 
@@ -344,6 +344,9 @@ [PcdsFixedAtBuild.common]
  
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
  
+  # Default platform supported RFC 4646 languages: (American) English

+  gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultPlatformLangCodes|"en-US"
+
gEmbeddedTokenSpaceGuid.PcdInterruptBaseAddress|0x4000
gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum|0x0
gArmTokenSpaceGuid.PcdArmArchTimerIntrNum|0x1




Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#62836): https://edk2.groups.io/g/devel/message/62836
Mute This Topic: https://groups.io/mt/75654068/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform][PATCH v1 1/2] Platforms/RaspberryPi: Set RPi4 Language supported to English

[Pete Batard]

On 2020.07.19 00:04, Samer El-Haj-Mahmoud wrote:

Set the supported RPi4 platform language to English (US),
and remove French.

This fixes https://github.com/pftf/RPi4/issues/35

Cc: Leif Lindholm 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Platform/RaspberryPi/RPi4/RPi4.dsc | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index c481c3534263..68c0e670648f 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -1,6 +1,6 @@
  # @file
  #
-#  Copyright (c) 2011 - 2019, ARM Limited. All rights reserved.
+#  Copyright (c) 2011 - 2020, ARM Limited. All rights reserved.
  #  Copyright (c) 2017 - 2018, Andrei Warkentin 
  #  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
@@ -352,6 +352,9 @@ [PcdsFixedAtBuild.common]
  
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
  
+  # Default platform supported RFC 4646 languages: (American) English

+  gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultPlatformLangCodes|"en-US"
+
  [LibraryClasses.common]
ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#62835): https://edk2.groups.io/g/devel/message/62835
Mute This Topic: https://groups.io/mt/75654067/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2][PATCH 1/1] BcmGenetDxe: don't consume RX buffer until it's actually copied

[Pete Batard]

On 2020.07.14 14:36, Leif Lindholm wrote:

On Mon, Jul 13, 2020 at 12:25:18 +0100, Pete Batard wrote:

One very minor formatting issue inline (that can be sorted during
integration):


I would also like to prepend "Silicon/" to the subject line.


Please do. It should have been there in the first place.

Regards,

/Pete


If I can do those two things:
Reviewed-by: Leif Lindholm 


On 2020.07.12 05:28, Andrei Warkentin wrote:

This was originally a bit sloppy, and could hypothetically under heavy
load result in a buffer being overwritten by hardware before the received
buffer is copied.

Signed-off-by: Andrei Warkentin 
---
   Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h   | 15 +
   Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenetUtil.c | 59 
+++-
   Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c | 26 ++---
   3 files changed, 77 insertions(+), 23 deletions(-)

diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
index 1a117b25..b39a1326 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
@@ -358,6 +358,16 @@ GenetTxIntr (
 OUT VOID  **TxBuf
 );
+UINT32
+GenetRxPending (
+  IN  GENET_PRIVATE_DATA *Genet
+  );
+
+UINT32
+GenetTxPending (
+  IN  GENET_PRIVATE_DATA *Genet
+  );
+
   EFI_STATUS
   GenetRxIntr (
 IN GENET_PRIVATE_DATA *Genet,
@@ -365,4 +375,9 @@ GenetRxIntr (
 OUT UINTN *FrameLength
 );
+VOID
+GenetRxComplete (
+  IN GENET_PRIVATE_DATA *Genet
+  );
+
   #endif /* GENET_UTIL_H__ */
diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenetUtil.c 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenetUtil.c
index 1c4c8527..a0097b0d 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenetUtil.c
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenetUtil.c
@@ -661,6 +661,7 @@ GenetDmaMapRxDescriptor (
   Genet->RxBufferMap[DescIndex].PhysAddress & 0x);
 GenetMmioWrite (Genet, GENET_RX_DESC_ADDRESS_HI (DescIndex),
   (Genet->RxBufferMap[DescIndex].PhysAddress >> 32) & 0x);
+  GenetMmioWrite (Genet, GENET_RX_DESC_STATUS (DescIndex), 0);
 return EFI_SUCCESS;
   }
@@ -753,12 +754,9 @@ GenetTxIntr (
 OUT VOID   **TxBuf
 )
   {
-  UINT32  ConsIndex, Total;
+  UINT32 Total;
-  ConsIndex = GenetMmioRead (Genet,
-GENET_TX_DMA_CONS_INDEX (GENET_DMA_DEFAULT_QUEUE)) & 0x;
-
-  Total = (ConsIndex - Genet->TxConsIndex) & 0x;
+  Total = GenetTxPending (Genet);
 if (Genet->TxQueued > 0 && Total > 0) {
   DmaUnmap (Genet->TxBufferMap[Genet->TxNext]);
   *TxBuf = Genet->TxBuffer[Genet->TxNext];
@@ -770,6 +768,46 @@ GenetTxIntr (
 }
   }
+UINT32
+GenetRxPending (
+  IN  GENET_PRIVATE_DATA *Genet
+  )
+{
+  UINT32 ProdIndex;
+  UINT32 ConsIndex;
+
+  ConsIndex = GenetMmioRead (Genet,
+GENET_RX_DMA_CONS_INDEX (GENET_DMA_DEFAULT_QUEUE)) & 0x;
+  ASSERT (ConsIndex == Genet->RxConsIndex);
+
+  ProdIndex = GenetMmioRead (Genet,
+GENET_RX_DMA_PROD_INDEX (GENET_DMA_DEFAULT_QUEUE)) & 0x;
+  return (ProdIndex - Genet->RxConsIndex) & 0x;
+}
+
+UINT32
+GenetTxPending (
+  IN  GENET_PRIVATE_DATA *Genet
+  )
+{
+  UINT32 ConsIndex;
+
+  ConsIndex = GenetMmioRead (Genet,
+ GENET_TX_DMA_CONS_INDEX (GENET_DMA_DEFAULT_QUEUE)) & 0x;


If we want to be pedantic about EDK2 formatting, this should be indented to
start after the "Ge" of GenetMmioRead above, like the previous calls.


+
+  return (ConsIndex - Genet->TxConsIndex) & 0x;
+}
+
+VOID
+GenetRxComplete (
+  IN GENET_PRIVATE_DATA *Genet
+  )
+{
+  Genet->RxConsIndex = (Genet->RxConsIndex + 1) & 0x;
+  GenetMmioWrite (Genet, GENET_RX_DMA_CONS_INDEX (GENET_DMA_DEFAULT_QUEUE),
+  Genet->RxConsIndex);
+}
+
   /**
 Simulate an "RX interrupt", returning the index of a completed RX buffer 
and
 corresponding frame length.
@@ -790,21 +828,14 @@ GenetRxIntr (
 )
   {
 EFI_STATUSStatus;
-  UINT32ProdIndex, Total;
+  UINT32Total;
 UINT32DescStatus;
-  ProdIndex = GenetMmioRead (Genet,
-GENET_RX_DMA_PROD_INDEX (GENET_DMA_DEFAULT_QUEUE)) & 0x;
-
-  Total = (ProdIndex - Genet->RxConsIndex) & 0x;
+  Total = GenetRxPending (Genet);
 if (Total > 0) {
   *DescIndex = Genet->RxConsIndex % GENET_DMA_DESC_COUNT;
   DescStatus = GenetMmioRead (Genet, GENET_RX_DESC_STATUS (*DescIndex));
   *FrameLength = SHIFTOUT (DescStatus, GENET_RX_DESC_STATUS_BUFLEN);
-
-Genet->RxConsIndex = (Genet->RxConsIndex + 1) & 0x;
-GenetMmioWrite (Genet, GENET_RX_DMA_CONS_INDEX (GENET_DMA_DEFAULT_QUEUE),
-  Genet->RxConsIndex);
   Status = EFI_SUCCESS;
 } else 

Re: [edk2-devel] [edk2-platforms][PATCH v3 1/1] Platform/RaspberryPi/Drivers: Add SD/(e)MMC card detection

[Pete Batard]

On 2020.07.14 14:25, Leif Lindholm wrote:

On Mon, Jul 13, 2020 at 12:16:20 +0100, Pete Batard wrote:

The Raspberry Pi 3 and Pi 4 platforms (with latest EEPROM) can boot
straight from USB, without the need for an SD card being present.
However, the IsCardPresent () calls from the ArasanMmcHost and SdHost
drivers are currently hardwired to return TRUE, which results in
straight to USB boot failing due to the SD drivers looping on
errors while trying to poke at a non-existent card...

Ideally, we would use the Card Detect signal from the uSD slot, to
report on the presence or absence of a card, but the Raspberry Pi
Foundation did not wire those signals in the Pi 2 and subsequent
models, leaving us with only potentially interfering SD commands
as means to perform card detection.

As a result of this, we are left with no other choice but limit
detection to occurring only once, prior to formal SD card init,
and then return the detected value for subsequent calls. This,
however, is more than good enough for the intended purpose, which
is to allow straight to USB boot. The sequence is a simplified
variant of the identification code in MmcDxe.

Tested on Raspberry Pi 2B, 3B and CM3 (for both SD controllers)
and Pi 4 (for Arasan, as that's the only controller available today)

Addresses pftf/RPi3#13, pftf/RPi3#14, pftf/RPi4#37.

Co-authored-by: Andrei Warkentin 
Signed-off-by: Pete Batard 


Some minor style comments below, I'm happy to fix them before pushing
if you're OK with these:


I agree with the proposed changes. Thanks for volunteering to fix these.

I just tested your diff with a Pi 4, for good measure, and everything 
looks good.


Regards,

/Pete




---
  Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 86 
++--
  Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c   | 75 
+++--
  Platform/RaspberryPi/Include/Protocol/RpiMmcHost.h   |  6 ++
  3 files changed, 150 insertions(+), 17 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c 
b/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
index 6d706af6f276..d2a8ffddbb66 100644
--- a/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
+++ b/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
@@ -11,7 +11,8 @@
  
  #define DEBUG_MMCHOST_SD DEBUG_VERBOSE
  
-BOOLEAN PreviousIsCardPresent = FALSE;

+BOOLEAN CardIsPresent = FALSE;
+CARD_DETECT_STATE CardDetectState = CardDetectRequired;


Global variables, so add 'm' prefix?
Also, add STATIC (which also matches SdHostDxe version)?


  UINT32 LastExecutedCommand = (UINT32) -1;
  
  STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;

@@ -239,14 +240,6 @@ CalculateClockFrequencyDivisor (
return EFI_SUCCESS;
  }
  
-BOOLEAN

-MMCIsCardPresent (
-  IN EFI_MMC_HOST_PROTOCOL *This
-)
-{
-  return TRUE;
-}
-
  BOOLEAN
  MMCIsReadOnly (
IN EFI_MMC_HOST_PROTOCOL *This
@@ -418,6 +411,10 @@ MMCNotifyState (
  
DEBUG ((DEBUG_MMCHOST_SD, "ArasanMMCHost: MMCNotifyState(State: %d)\n", State));
  
+  // Stall all operations except init until card detection has occurred.

+  if (State != MmcHwInitializationState && CardDetectState != 
CardDetectCompleted)
+return EFI_NOT_READY;
+


Add {}?


switch (State) {
case MmcHwInitializationState:
  {
@@ -489,6 +486,77 @@ MMCNotifyState (
return EFI_SUCCESS;
  }
  
+BOOLEAN

+MMCIsCardPresent (
+  IN EFI_MMC_HOST_PROTOCOL *This
+)
+{
+  EFI_STATUS Status;
+
+  //
+  // If we are already in progress (we may get concurrent calls)
+  // or completed the detection, just return the current value.
+  //
+  if (CardDetectState != CardDetectRequired)
+return CardIsPresent;


Add {}?


+
+  CardDetectState = CardDetectInProgress;
+  CardIsPresent = FALSE;
+
+  //
+  // The two following commands should succeed even if no card is present.
+  //
+  Status = MMCNotifyState (This, MmcHwInitializationState);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "MMCIsCardPresent: Error MmcHwInitializationState, 
Status=%r.\n", Status));
+// If we failed init, go back to requiring card detection
+CardDetectState = CardDetectRequired;
+return FALSE;
+  }
+
+  Status = MMCSendCommand (This, MMC_CMD0, 0);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "MMCIsCardPresent: CMD0 Error, Status=%r.\n", 
Status));
+goto out;
+  }
+
+  //
+  // CMD8 should tell us if an SD card is present.
+  //
+  Status = MMCSendCommand (This, MMC_CMD8, CMD8_SD_ARG);
+  if (!EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_INFO, "MMCIsCardPresent: Maybe SD card detected.\n"));
+ CardIsPresent = TRUE;
+ goto out;
+  }
+
+  //
+  // MMC/eMMC won't accept CMD8, but we can try CMD1.
+  //
+  Status = MMCSendCommand (This, MMC_CMD1, 
EMMC_CMD1_CAPACITY_GREATER_THAN_2GB);
+  if (!EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_INFO, "MMCIsCardPresent: Maybe MMC card detec

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Platform/RaspberryPi: remove unused variable GpuIndex from PlatformLib

[Pete Batard]

Good call.

On 2020.07.14 13:45, Leif Lindholm wrote:

Commit 678f6bff3c46 ("RPi4: reserve/map memory above 4GB when present")
removed the only user of the GpuIndex variable in
ArmPlatformGetVirtualMemoryMap, which causes a build error of NOOPT
profile with gcc 8.3. Delete the variable, and its initialization.

Cc: Andrei Warkentin 
Cc: Pete Batard 
Signed-off-by: Leif Lindholm 
---
  Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c 
b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
index 60a7b43af993..c395e0c75df7 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
+++ b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
@@ -57,7 +57,6 @@ ArmPlatformGetVirtualMemoryMap (
)
  {
UINTN Index = 0;
-  UINTN GpuIndex;
INT64 TotalMemorySize;
INT64 MemorySizeBelow3GB;
INT64 MemorySizeBelow4GB;
@@ -162,7 +161,6 @@ ArmPlatformGetVirtualMemoryMap (
VirtualMemoryInfo[Index++].Name   = L"System RAM < 1GB";
  
// GPU Reserved

-  GpuIndex = Index;
VirtualMemoryTable[Index].PhysicalBase= mVideoCoreBase;
VirtualMemoryTable[Index].VirtualBase = 
VirtualMemoryTable[Index].PhysicalBase;
VirtualMemoryTable[Index].Length  = mVideoCoreSize;



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#62497): https://edk2.groups.io/g/devel/message/62497
Mute This Topic: https://groups.io/mt/75497638/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2][PATCH 1/1] BcmGenetDxe: don't consume RX buffer until it's actually copied

[Pete Batard]

rk.c
@@ -502,9 +502,19 @@ GenetSimpleNetworkGetStatus (
  Genet->SnpMode.MediaPresent = FALSE;
} else {
  Genet->SnpMode.MediaPresent = TRUE;
+  }
+
+  if (TxBuf != NULL) {
+GenetTxIntr (Genet, TxBuf);
+  }
  
-if (TxBuf != NULL) {

-  GenetTxIntr (Genet, TxBuf);
+  if (InterruptStatus != NULL) {
+*InterruptStatus = 0;
+if (GenetRxPending (Genet) > 0) {
+  *InterruptStatus |= EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT;
+}
+if (GenetTxPending (Genet) > 0) {
+  *InterruptStatus |= EFI_SIMPLE_NETWORK_TRANSMIT_INTERRUPT;
  }
}
  
@@ -741,13 +751,8 @@ GenetSimpleNetworkReceive (

DEBUG ((DEBUG_ERROR,
  "%a: Buffer size (0x%X) is too small for frame (0x%X)\n",
  __FUNCTION__, *BufferSize, FrameLength));
-  Status = GenetDmaMapRxDescriptor (Genet, DescIndex);
-  if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "%a: Failed to remap RX descriptor!\n",
-  __FUNCTION__));
-  }
-  EfiReleaseLock (>Lock);
-  return EFI_BUFFER_TOO_SMALL;
+  Status = EFI_BUFFER_TOO_SMALL;
+  goto out;
  }
  
  if (DestAddr != NULL) {

@@ -773,11 +778,14 @@ GenetSimpleNetworkReceive (
  Status = EFI_NOT_READY;
}
  
+out:

Status = GenetDmaMapRxDescriptor (Genet, DescIndex);
if (EFI_ERROR (Status)) {
  DEBUG ((DEBUG_ERROR, "%a: Failed to remap RX descriptor!\n", 
__FUNCTION__));
}
  
+  GenetRxComplete (Genet);

+
EfiReleaseLock (>Lock);
return Status;
  }



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#62421): https://edk2.groups.io/g/devel/message/62421
Mute This Topic: https://groups.io/mt/75452213/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v3 1/1] Platform/RaspberryPi/Drivers: Add SD/(e)MMC card detection

[Pete Batard]

The Raspberry Pi 3 and Pi 4 platforms (with latest EEPROM) can boot
straight from USB, without the need for an SD card being present.
However, the IsCardPresent () calls from the ArasanMmcHost and SdHost
drivers are currently hardwired to return TRUE, which results in
straight to USB boot failing due to the SD drivers looping on
errors while trying to poke at a non-existent card...

Ideally, we would use the Card Detect signal from the uSD slot, to
report on the presence or absence of a card, but the Raspberry Pi
Foundation did not wire those signals in the Pi 2 and subsequent
models, leaving us with only potentially interfering SD commands
as means to perform card detection.

As a result of this, we are left with no other choice but limit
detection to occurring only once, prior to formal SD card init,
and then return the detected value for subsequent calls. This,
however, is more than good enough for the intended purpose, which
is to allow straight to USB boot. The sequence is a simplified
variant of the identification code in MmcDxe.

Tested on Raspberry Pi 2B, 3B and CM3 (for both SD controllers)
and Pi 4 (for Arasan, as that's the only controller available today)

Addresses pftf/RPi3#13, pftf/RPi3#14, pftf/RPi4#37.

Co-authored-by: Andrei Warkentin 
Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 86 
++--
 Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c   | 75 
+++--
 Platform/RaspberryPi/Include/Protocol/RpiMmcHost.h   |  6 ++
 3 files changed, 150 insertions(+), 17 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c 
b/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
index 6d706af6f276..d2a8ffddbb66 100644
--- a/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
+++ b/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
@@ -11,7 +11,8 @@
 
 #define DEBUG_MMCHOST_SD DEBUG_VERBOSE
 
-BOOLEAN PreviousIsCardPresent = FALSE;
+BOOLEAN CardIsPresent = FALSE;
+CARD_DETECT_STATE CardDetectState = CardDetectRequired;
 UINT32 LastExecutedCommand = (UINT32) -1;
 
 STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
@@ -239,14 +240,6 @@ CalculateClockFrequencyDivisor (
   return EFI_SUCCESS;
 }
 
-BOOLEAN
-MMCIsCardPresent (
-  IN EFI_MMC_HOST_PROTOCOL *This
-)
-{
-  return TRUE;
-}
-
 BOOLEAN
 MMCIsReadOnly (
   IN EFI_MMC_HOST_PROTOCOL *This
@@ -418,6 +411,10 @@ MMCNotifyState (
 
   DEBUG ((DEBUG_MMCHOST_SD, "ArasanMMCHost: MMCNotifyState(State: %d)\n", 
State));
 
+  // Stall all operations except init until card detection has occurred.
+  if (State != MmcHwInitializationState && CardDetectState != 
CardDetectCompleted)
+return EFI_NOT_READY;
+
   switch (State) {
   case MmcHwInitializationState:
 {
@@ -489,6 +486,77 @@ MMCNotifyState (
   return EFI_SUCCESS;
 }
 
+BOOLEAN
+MMCIsCardPresent (
+  IN EFI_MMC_HOST_PROTOCOL *This
+)
+{
+  EFI_STATUS Status;
+
+  //
+  // If we are already in progress (we may get concurrent calls)
+  // or completed the detection, just return the current value.
+  //
+  if (CardDetectState != CardDetectRequired)
+return CardIsPresent;
+
+  CardDetectState = CardDetectInProgress;
+  CardIsPresent = FALSE;
+
+  //
+  // The two following commands should succeed even if no card is present.
+  //
+  Status = MMCNotifyState (This, MmcHwInitializationState);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "MMCIsCardPresent: Error MmcHwInitializationState, 
Status=%r.\n", Status));
+// If we failed init, go back to requiring card detection
+CardDetectState = CardDetectRequired;
+return FALSE;
+  }
+
+  Status = MMCSendCommand (This, MMC_CMD0, 0);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "MMCIsCardPresent: CMD0 Error, Status=%r.\n", 
Status));
+goto out;
+  }
+
+  //
+  // CMD8 should tell us if an SD card is present.
+  //
+  Status = MMCSendCommand (This, MMC_CMD8, CMD8_SD_ARG);
+  if (!EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_INFO, "MMCIsCardPresent: Maybe SD card detected.\n"));
+ CardIsPresent = TRUE;
+ goto out;
+  }
+
+  //
+  // MMC/eMMC won't accept CMD8, but we can try CMD1.
+  //
+  Status = MMCSendCommand (This, MMC_CMD1, 
EMMC_CMD1_CAPACITY_GREATER_THAN_2GB);
+  if (!EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_INFO, "MMCIsCardPresent: Maybe MMC card detected.\n"));
+ CardIsPresent = TRUE;
+ goto out;
+  }
+
+  //
+  // SDIO?
+  //
+  Status = MMCSendCommand (This, MMC_CMD5, 0);
+  if (!EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_INFO, "MMCIsCardPresent: Maybe SDIO card detected.\n"));
+ CardIsPresent = TRUE;
+ goto out;
+  }
+
+  DEBUG ((DEBUG_INFO, "MMCIsCardPresent: Not detected, Status=%r.\n", Status));
+
+out:
+  CardDetectState = CardDetectCompleted;
+  return CardIsPresent;
+}
+
 EFI_STATUS
 MMCReceiveResponse (
   IN EFI_MMC_HOST_PROT

[edk2-devel] [edk2-platforms][PATCH v3 0/1] Platform/RaspberryPi/Drivers: Add SD/(e)MMC card detection

[Pete Batard]

This supersedes https://edk2.groups.io/g/devel/message/62339 - 62340

Changes from v2:
- Fix regression for CM3 module due to MMC/eMMC not accepting CMD8

Pete Batard (1):
  Platform/RaspberryPi/Drivers: Add SD/(e)MMC card detection

 Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 86 
++--
 Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c   | 75 
+++--
 Platform/RaspberryPi/Include/Protocol/RpiMmcHost.h   |  6 ++
 3 files changed, 150 insertions(+), 17 deletions(-)

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#62419): https://edk2.groups.io/g/devel/message/62419
Mute This Topic: https://groups.io/mt/75474583/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 0/1] Platform/RaspberryPi/Drivers: Add SD card detection

[Pete Batard]

v2 to correct a couple "STATIC" -> "static" that were applied by
an overzealous text editor.

No other changes from v1.

Pete Batard (1):
  Platform/RaspberryPi/Drivers: Add SD card detection

 Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 66 
+---
 Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c   | 65 
---
 Platform/RaspberryPi/Include/Protocol/RpiMmcHost.h   |  6 ++
 3 files changed, 120 insertions(+), 17 deletions(-)

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#62339): https://edk2.groups.io/g/devel/message/62339
Mute This Topic: https://groups.io/mt/75415098/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH v2 1/1] Platform/RaspberryPi/Drivers: Add SD card detection

[Pete Batard]

The Raspberry Pi 3 and Pi 4 platforms (with latest EEPROM) can boot
straight from USB, without the need for an SD card being present.
However, the IsCardPresent () calls from the ArasanMmcHost and SdHost
drivers are currently hardwired to return TRUE, which results in
straight to USB boot failing due to the SD drivers looping on
errors while trying to poke at a non-existent card...

Ideally, we would use the Card Detect signal from the uSD slot, to
report on the presence or absence of a card, but the Raspberry Pi
Foundation did not wire those signals in the Pi 2 and subsequent
models, leaving us with only potentially interfering SD commands
as means to perform card detection.

As a result of this, we are left with no other choice but limit
detection to occurring only once, prior to formal SD card init,
and then return the detected value for subsequent calls. This,
however, is more than good enough for the intended purpose, which
is to allow straight to USB boot.

Tested on Raspberry Pi 3 and 4, and for both SD controllers.

Addresses pftf/RPi3#13, pftf/RPi3#14, pftf/RPi4#37.

Signed-off-by: Pete Batard 
Reviewed-by: Andrei Warkentin 
Tested-by: Andrei Warkentin 
---
 Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 66 
+---
 Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c   | 65 
---
 Platform/RaspberryPi/Include/Protocol/RpiMmcHost.h   |  6 ++
 3 files changed, 120 insertions(+), 17 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c 
b/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
index 6d706af6f276..08e5be1f015f 100644
--- a/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
+++ b/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
@@ -11,7 +11,8 @@
 
 #define DEBUG_MMCHOST_SD DEBUG_VERBOSE
 
-BOOLEAN PreviousIsCardPresent = FALSE;
+BOOLEAN CardIsPresent = FALSE;
+CARD_DETECT_STATE CardDetectState = CardDetectRequired;
 UINT32 LastExecutedCommand = (UINT32) -1;
 
 STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
@@ -239,14 +240,6 @@ CalculateClockFrequencyDivisor (
   return EFI_SUCCESS;
 }
 
-BOOLEAN
-MMCIsCardPresent (
-  IN EFI_MMC_HOST_PROTOCOL *This
-)
-{
-  return TRUE;
-}
-
 BOOLEAN
 MMCIsReadOnly (
   IN EFI_MMC_HOST_PROTOCOL *This
@@ -418,6 +411,10 @@ MMCNotifyState (
 
   DEBUG ((DEBUG_MMCHOST_SD, "ArasanMMCHost: MMCNotifyState(State: %d)\n", 
State));
 
+  // Stall all operations except init until card detection has occurred.
+  if (State != MmcHwInitializationState && CardDetectState != 
CardDetectCompleted)
+return EFI_NOT_READY;
+
   switch (State) {
   case MmcHwInitializationState:
 {
@@ -489,6 +486,57 @@ MMCNotifyState (
   return EFI_SUCCESS;
 }
 
+BOOLEAN
+MMCIsCardPresent (
+  IN EFI_MMC_HOST_PROTOCOL *This
+)
+{
+  EFI_STATUS Status;
+
+  //
+  // If we are already in progress (we may get concurrent calls)
+  // or completed the detection, just return the current value.
+  //
+  if (CardDetectState != CardDetectRequired)
+return CardIsPresent;
+
+  CardDetectState = CardDetectInProgress;
+  CardIsPresent = FALSE;
+
+  //
+  // The two following commands should succeed even if no card is present.
+  //
+  Status = MMCNotifyState (This, MmcHwInitializationState);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "MMCIsCardPresent: Error MmcHwInitializationState, 
Status=%r.\n", Status));
+// If we failed init, go back to requiring card detection
+CardDetectState = CardDetectRequired;
+return FALSE;
+  }
+
+  Status = MMCSendCommand (This, MMC_CMD0, 0);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "MMCIsCardPresent: CMD0 Error, Status=%r.\n", 
Status));
+goto out;
+  }
+
+  //
+  // CMD8 should tell us if a card is present.
+  //
+  Status = MMCSendCommand (This, MMC_CMD8, CMD8_SD_ARG);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_INFO, "MMCIsCardPresent: No card detected, Status=%r.\n", 
Status));
+goto out;
+  }
+
+  DEBUG ((DEBUG_INFO, "MMCIsCardPresent: Card detected.\n"));
+  CardIsPresent = TRUE;
+
+out:
+  CardDetectState = CardDetectCompleted;
+  return CardIsPresent;
+}
+
 EFI_STATUS
 MMCReceiveResponse (
   IN EFI_MMC_HOST_PROTOCOL*This,
diff --git a/Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c 
b/Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c
index 2f31c5eb8c46..964b2d3ac5c1 100644
--- a/Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c
+++ b/Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c
@@ -64,6 +64,8 @@ STATIC CONST CHAR8 *mFsmState[] = { "identmode", "datamode", 
"readdata",
 "genpulses", "writewait2", "?",
 "startpowdown" };
 #endif /* NDEBUG */
+STATIC BOOLEAN CardIsPresent = FALSE;
+STATIC CARD_DETECT_STATE CardDet

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Silicon/Broadcom/Bcm283x: GpioLib enhancements

[Pete Batard]

On 2020.07.02 13:03, Ard Biesheuvel wrote:

On 6/29/20 8:39 PM, Pete Batard wrote:

* Add GpioPinSet () function to set a GPIO pin value
* Add GpioPinGet () function to read a GPIO pin value
* Add GpioSetPull () function to set pullup/down state of a GPIO pin

GpioSetPull () supports both the legacy method used on Bcm283[5-7]
as well as the new method used on Bcm2711.

Each of these calls was tested on Raspberry Pi 3 B+ as well as on a
Raspberry Pi 4 B.

Signed-off-by: Pete Batard 


Remind me again what the purpose of this patch is?


Feature completion, potential future improvements and providing 
additional options for testing (since one will now be able to use this 
driver to control LEDs or read switches).


It doesn't serve any *immediate* purpose.

However, I've been playing with it to simulate an SD card detect, which 
came handy for developing the other patch I sent, and I would assert 
having an established means to control GPIO signals is likely to help 
others as well.


Regards,

/Pete




---
  Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h | 44 
-
  Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h  | 17 

  Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c  | 93 


  Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.inf    |  1 +
  4 files changed, 152 insertions(+), 3 deletions(-)

diff --git 
a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h 
b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h

index e65cc5c3bbb4..8ad81776b43a 100644
--- a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h
+++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h
@@ -1,5 +1,6 @@
  /** @file
   *
+ *  Copyright (c) 2020, Pete Batard 
   *  Copyright (c) 2018, Andrei Warkentin 
   *  Copyright (c) Microsoft Corporation. All rights reserved.
   *
@@ -23,12 +24,45 @@
  #define GPIO_GPFSEL4   (GPIO_BASE_ADDRESS + 0x10)
  #define GPIO_GPFSEL5   (GPIO_BASE_ADDRESS + 0x14)
-#define GPIO_GPCLR0    (GPIO_BASE_ADDRESS + 0x28)
-#define GPIO_GPCLR1    (GPIO_BASE_ADDRESS + 0x2C)
-
  #define GPIO_GPSET0    (GPIO_BASE_ADDRESS + 0x1C)
  #define GPIO_GPSET1    (GPIO_BASE_ADDRESS + 0x20)
+#define GPIO_GPCLR0    (GPIO_BASE_ADDRESS + 0x28)
+#define GPIO_GPCLR1    (GPIO_BASE_ADDRESS + 0x2C)
+
+#define GPIO_GPLEV0    (GPIO_BASE_ADDRESS + 0x34)
+#define GPIO_GPLEV1    (GPIO_BASE_ADDRESS + 0x38)
+
+#define GPIO_GPEDS0    (GPIO_BASE_ADDRESS + 0x40)
+#define GPIO_GPEDS1    (GPIO_BASE_ADDRESS + 0x44)
+
+#define GPIO_GPREN0    (GPIO_BASE_ADDRESS + 0x4C)
+#define GPIO_GPREN1    (GPIO_BASE_ADDRESS + 0x50)
+
+#define GPIO_GPFEN0    (GPIO_BASE_ADDRESS + 0x58)
+#define GPIO_GPFEN1    (GPIO_BASE_ADDRESS + 0x5C)
+
+#define GPIO_GPHEN0    (GPIO_BASE_ADDRESS + 0x64)
+#define GPIO_GPHEN1    (GPIO_BASE_ADDRESS + 0x68)
+
+#define GPIO_GPLEN0    (GPIO_BASE_ADDRESS + 0x70)
+#define GPIO_GPLEN1    (GPIO_BASE_ADDRESS + 0x74)
+
+#define GPIO_GPAREN0   (GPIO_BASE_ADDRESS + 0x7C)
+#define GPIO_GPAREN1   (GPIO_BASE_ADDRESS + 0x80)
+
+#define GPIO_GPAFEN0   (GPIO_BASE_ADDRESS + 0x88)
+#define GPIO_GPAFEN1   (GPIO_BASE_ADDRESS + 0x8C)
+
+#define GPIO_GPPUD (GPIO_BASE_ADDRESS + 0x94)
+#define GPIO_GPPUDCLK0 (GPIO_BASE_ADDRESS + 0x98)
+#define GPIO_GPPUDCLK1 (GPIO_BASE_ADDRESS + 0x9C)
+
+#define GPIO_GPPUPPDN0 (GPIO_BASE_ADDRESS + 0xE4)
+#define GPIO_GPPUPPDN1 (GPIO_BASE_ADDRESS + 0xE8)
+#define GPIO_GPPUPPDN2 (GPIO_BASE_ADDRESS + 0xEC)
+#define GPIO_GPPUPPDN3 (GPIO_BASE_ADDRESS + 0xF0)
+
  #define GPIO_FSEL_INPUT    0x0
  #define GPIO_FSEL_OUTPUT   0x1
  #define GPIO_FSEL_ALT0 0x4
@@ -44,4 +78,8 @@
  #define GPIO_PINS  54
+#define GPIO_PULL_NONE 0x00
+#define GPIO_PULL_DOWN 0x01
+#define GPIO_PULL_UP   0x02
+
  #endif /* __BCM2836_GPIO_H__ */
diff --git a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h 
b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h

index 014c6b07a29f..75c2c8be51aa 100644
--- a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
+++ b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
@@ -24,4 +24,21 @@ GpioPinFuncGet (
    IN  UINTN Pin
    );
+VOID
+GpioPinSet (
+  IN  UINTN Pin,
+  IN  UINTN Val
+  );
+
+UINTN
+GpioPinGet (
+  IN  UINTN Pin
+  );
+
+VOID
+GpioSetPull (
+  IN  UINTN   Pin,
+  IN  UINTN   Pud
+);
+
  #endif /* __GPIO_LIB__ */
diff --git a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c 
b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c

index 542b6e8f6b2f..a4b4af59ebb1 100644
--- a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
+++ b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
@@ -2,6 +2,7 @@
   *
   *  GPIO manipulation.
   *
+ *  Copyright (c) 2020, Pete Batard 
   *  Copyright (c) 2018, Andrei Warkentin 
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -13,6 +14,7 @@
  #include 
  #include

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

__
From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> on behalf of Pete 
Batard via groups.io <mailto:pete=akeo...@groups.io>
Sent: Wednesday, June 17, 2020 11:34 AM
To: Wang, Sunny (HPS SW) <mailto:sunnyw...@hpe.com>; mailto:devel@edk2.groups.io 
<mailto:devel@edk2.groups.io>
Cc: mailto:zhichao@intel.com <mailto:zhichao@intel.com>; mailto:ray...@intel.com 
<mailto:ray...@intel.com>; mailto:ard.biesheu...@arm.com <mailto:ard.biesheu...@arm.com>; 
mailto:l...@nuviainc.com <mailto:l...@nuviainc.com>
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: 
Signal ReadyToBoot on platform recovery

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:

Thanks for checking my comments, Pete.


Or is the "one more" the issue, meaning that it would get signaled more than 
once?

[Sunny] Yeah, it would get signaled more than once if the PlatformRecovery 
option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered 
boot option inside of the application.


Okay.

One element that I'm going to point out is that, with the current EDK2
code (i.e. without this proposal applied), and after a user goes into
the setup to save their boot options in order for regular boot options
to get executed instead of PlaformRecovery, the OnReadyToBoot event is
actually called twice.

So my understanding is that, while we of course want to avoid this and
any patch proposal should actively try to prevent it, it seems we
already have behaviour in EDK2 that can lead to OnReadyToBoot being
signalled more than once.

At least the current Pi 4 platform does demonstrate this behaviour. For
instance, if you run DEBUG, you will see two instances of:

RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the ConsolePrefDxe's
OnReadyToBoot() call. I've also confirmed more specifically that
OnReadyToBoot() is indeed called twice.

I don't recall us doing much of any special with regards to boot options
for the Pi platform, so my guess is that it's probably not the only
platform where OnReadyToBoot might be signalled more than once, and that
this might be tied to a default EDK2 behaviour. Therefore I don't see
having a repeated event as a major deal breaker (though, again, if we
can avoid that, we of course will want to).


I don't mind trying an alternative approach, but I don't understand how what 
you describe would help. Can you please be more specific about what you have in 
mind?

[Sunny] Sure. I added more information below. If it is still not clear enough, 
feel free to let me know.
   1. Create a UEFI application with the code to signal ReadyToBoot and 
pick /efi/boot/bootaa64.efi from either SD or USB and run it.


So that would basically be adding code that duplicates, in part, what
Platform Recovery already does.

I have to be honest: Even outside of the extra work this would require,
I don't really like the idea of having to write our own application, as
it will introduce new possible points of failures and require extra
maintenance (especially as we will want to be able to handle network
boot and other options, and before long, I fear that we're going to have
to write our own Pi specific boot manager). Doing so simply because the
current Platform Recovery, which does suit our needs otherwise, is not
designed to call ReadyToBoot does not seem like the best course of
action in my book.

Instead, I still logically believe that any option that calls a boot
loader should signal ReadyToBoot, regardless of whether it was launched
from Boot Manager or Platform Recovery, and that it shouldn't be left to
each platform to work around that.

Of course, I understand that this would require a specs change, and that
it also may have ramifications for existing platforms that interpret the
current specs pedantically. But to me, regardless of what the specs
appear to be limiting it to right now, the logic of a "ReadyToBoot"
event is that it should be signalled whenever a bootloader is about to
be executed, rather than only when a bootloader happened to be launched
through a formal Boot Manager option.

I would therefore appreciate if other people could weigh in on this
matter, to see if I'm the only one who believes that we could ultimately
have more to gain from signalling ReadyToBoot with PlatformRecovery
options than leaving things as they stand right now...


   2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE 
driver or other places before "Default PlatformRecovery" registration:
Status = EfiBootManagerInitializeLoadOption (
   ,
   0,
 -> 0 is the OptionNumber to let application be load before " Default 
PlatformRecovery" option
 

[edk2-devel] [edk2-platforms][PATCH 1/1] Silicon/Broadcom/Bcm283x: GpioLib enhancements

[Pete Batard]

* Add GpioPinSet () function to set a GPIO pin value
* Add GpioPinGet () function to read a GPIO pin value
* Add GpioSetPull () function to set pullup/down state of a GPIO pin

GpioSetPull () supports both the legacy method used on Bcm283[5-7]
as well as the new method used on Bcm2711.

Each of these calls was tested on Raspberry Pi 3 B+ as well as on a
Raspberry Pi 4 B.

Signed-off-by: Pete Batard 
---
 Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h | 44 -
 Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h  | 17 
 Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c  | 93 

 Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.inf|  1 +
 4 files changed, 152 insertions(+), 3 deletions(-)

diff --git a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h 
b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h
index e65cc5c3bbb4..8ad81776b43a 100644
--- a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h
+++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h
@@ -1,5 +1,6 @@
 /** @file
  *
+ *  Copyright (c) 2020, Pete Batard 
  *  Copyright (c) 2018, Andrei Warkentin 
  *  Copyright (c) Microsoft Corporation. All rights reserved.
  *
@@ -23,12 +24,45 @@
 #define GPIO_GPFSEL4   (GPIO_BASE_ADDRESS + 0x10)
 #define GPIO_GPFSEL5   (GPIO_BASE_ADDRESS + 0x14)
 
-#define GPIO_GPCLR0(GPIO_BASE_ADDRESS + 0x28)
-#define GPIO_GPCLR1(GPIO_BASE_ADDRESS + 0x2C)
-
 #define GPIO_GPSET0(GPIO_BASE_ADDRESS + 0x1C)
 #define GPIO_GPSET1(GPIO_BASE_ADDRESS + 0x20)
 
+#define GPIO_GPCLR0(GPIO_BASE_ADDRESS + 0x28)
+#define GPIO_GPCLR1(GPIO_BASE_ADDRESS + 0x2C)
+
+#define GPIO_GPLEV0(GPIO_BASE_ADDRESS + 0x34)
+#define GPIO_GPLEV1(GPIO_BASE_ADDRESS + 0x38)
+
+#define GPIO_GPEDS0(GPIO_BASE_ADDRESS + 0x40)
+#define GPIO_GPEDS1(GPIO_BASE_ADDRESS + 0x44)
+
+#define GPIO_GPREN0(GPIO_BASE_ADDRESS + 0x4C)
+#define GPIO_GPREN1(GPIO_BASE_ADDRESS + 0x50)
+
+#define GPIO_GPFEN0(GPIO_BASE_ADDRESS + 0x58)
+#define GPIO_GPFEN1(GPIO_BASE_ADDRESS + 0x5C)
+
+#define GPIO_GPHEN0(GPIO_BASE_ADDRESS + 0x64)
+#define GPIO_GPHEN1(GPIO_BASE_ADDRESS + 0x68)
+
+#define GPIO_GPLEN0(GPIO_BASE_ADDRESS + 0x70)
+#define GPIO_GPLEN1(GPIO_BASE_ADDRESS + 0x74)
+
+#define GPIO_GPAREN0   (GPIO_BASE_ADDRESS + 0x7C)
+#define GPIO_GPAREN1   (GPIO_BASE_ADDRESS + 0x80)
+
+#define GPIO_GPAFEN0   (GPIO_BASE_ADDRESS + 0x88)
+#define GPIO_GPAFEN1   (GPIO_BASE_ADDRESS + 0x8C)
+
+#define GPIO_GPPUD (GPIO_BASE_ADDRESS + 0x94)
+#define GPIO_GPPUDCLK0 (GPIO_BASE_ADDRESS + 0x98)
+#define GPIO_GPPUDCLK1 (GPIO_BASE_ADDRESS + 0x9C)
+
+#define GPIO_GPPUPPDN0 (GPIO_BASE_ADDRESS + 0xE4)
+#define GPIO_GPPUPPDN1 (GPIO_BASE_ADDRESS + 0xE8)
+#define GPIO_GPPUPPDN2 (GPIO_BASE_ADDRESS + 0xEC)
+#define GPIO_GPPUPPDN3 (GPIO_BASE_ADDRESS + 0xF0)
+
 #define GPIO_FSEL_INPUT0x0
 #define GPIO_FSEL_OUTPUT   0x1
 #define GPIO_FSEL_ALT0 0x4
@@ -44,4 +78,8 @@
 
 #define GPIO_PINS  54
 
+#define GPIO_PULL_NONE 0x00
+#define GPIO_PULL_DOWN 0x01
+#define GPIO_PULL_UP   0x02
+
 #endif /* __BCM2836_GPIO_H__ */
diff --git a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h 
b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
index 014c6b07a29f..75c2c8be51aa 100644
--- a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
+++ b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
@@ -24,4 +24,21 @@ GpioPinFuncGet (
   IN  UINTN Pin
   );
 
+VOID
+GpioPinSet (
+  IN  UINTN Pin,
+  IN  UINTN Val
+  );
+
+UINTN
+GpioPinGet (
+  IN  UINTN Pin
+  );
+
+VOID
+GpioSetPull (
+  IN  UINTN   Pin,
+  IN  UINTN   Pud
+);
+
 #endif /* __GPIO_LIB__ */
diff --git a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c 
b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
index 542b6e8f6b2f..a4b4af59ebb1 100644
--- a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
+++ b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
@@ -2,6 +2,7 @@
  *
  *  GPIO manipulation.
  *
+ *  Copyright (c) 2020, Pete Batard 
  *  Copyright (c) 2018, Andrei Warkentin 
  *
  *  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -13,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -81,3 +83,94 @@ GpioPinFuncGet (
   Val &= GPIO_FSEL_MASK;
   return Val;
 }
+
+VOID
+GpioPinSet (
+  IN  UINTN Pin,
+  IN  UINTN Val
+  )
+{
+  EFI_PHYSICAL_ADDRESS Reg;
+  UINTN RegIndex;
+  UINTN SelIndex;
+
+  ASSERT (Pin < GPIO_PINS);
+
+  RegIndex = Pin / 32;
+  SelIndex = Pin % 32;
+
+  //
+  // Different base addresses are used for clear and set
+  //
+  Reg = (Val == 0) ? GPIO_GPCLR0 : GPIO_GPSET0;
+  Reg += RegIndex * sizeof (UINT32);
+  MmioWrite32 (Reg, 1 << SelIndex);
+}
+
+UINTN
+GpioPinGet (
+  IN  UINTN Pin
+  )
+{
+  EFI_PHYSICAL_ADDRESS Reg;
+  UINTN RegIn

[edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi/Drivers: Add SD card detection

[Pete Batard]

The Raspberry Pi 3 and Pi 4 platforms (with latest EEPROM) can boot
straight from USB, without the need for an SD card being present.
However, the IsCardPresent () calls from the ArasanMmcHost and SdHost
drivers are currently hardwired to return TRUE, which results in
straight to USB boot failing due to the SD drivers looping on
errors while trying to poke at a non-existent card...

Ideally, we would use the Card Detect signal from the uSD slot, to
report on the presence or absence of a card, but the Raspberry Pi
Foundation did not wire those signals in the Pi 2 and subsequent
models, leaving us with only potentially interfering SD commands
as means to perform card detection.

As a result of this, we are left with no other choice but limit
detection to occurring only once, prior to formal SD card init,
and then return the detected value for subsequent calls. This,
however, is more than good enough for the intended purpose, which
is to allow straight to USB boot.

Tested on Raspberry Pi 3 and 4, and for both SD controllers.

Addresses pftf/RPi3#13, pftf/RPi3#14, pftf/RPi4#37.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 66 
---
 Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c   | 69 
+---
 Platform/RaspberryPi/Include/Protocol/RpiMmcHost.h   |  6 ++
 3 files changed, 122 insertions(+), 19 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c 
b/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
index 6d706af6f276..08e5be1f015f 100644
--- a/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
+++ b/Platform/RaspberryPi/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
@@ -11,7 +11,8 @@
 
 #define DEBUG_MMCHOST_SD DEBUG_VERBOSE
 
-BOOLEAN PreviousIsCardPresent = FALSE;
+BOOLEAN CardIsPresent = FALSE;
+CARD_DETECT_STATE CardDetectState = CardDetectRequired;
 UINT32 LastExecutedCommand = (UINT32) -1;
 
 STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
@@ -239,14 +240,6 @@ CalculateClockFrequencyDivisor (
   return EFI_SUCCESS;
 }
 
-BOOLEAN
-MMCIsCardPresent (
-  IN EFI_MMC_HOST_PROTOCOL *This
-)
-{
-  return TRUE;
-}
-
 BOOLEAN
 MMCIsReadOnly (
   IN EFI_MMC_HOST_PROTOCOL *This
@@ -418,6 +411,10 @@ MMCNotifyState (
 
   DEBUG ((DEBUG_MMCHOST_SD, "ArasanMMCHost: MMCNotifyState(State: %d)\n", 
State));
 
+  // Stall all operations except init until card detection has occurred.
+  if (State != MmcHwInitializationState && CardDetectState != 
CardDetectCompleted)
+return EFI_NOT_READY;
+
   switch (State) {
   case MmcHwInitializationState:
 {
@@ -489,6 +486,57 @@ MMCNotifyState (
   return EFI_SUCCESS;
 }
 
+BOOLEAN
+MMCIsCardPresent (
+  IN EFI_MMC_HOST_PROTOCOL *This
+)
+{
+  EFI_STATUS Status;
+
+  //
+  // If we are already in progress (we may get concurrent calls)
+  // or completed the detection, just return the current value.
+  //
+  if (CardDetectState != CardDetectRequired)
+return CardIsPresent;
+
+  CardDetectState = CardDetectInProgress;
+  CardIsPresent = FALSE;
+
+  //
+  // The two following commands should succeed even if no card is present.
+  //
+  Status = MMCNotifyState (This, MmcHwInitializationState);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "MMCIsCardPresent: Error MmcHwInitializationState, 
Status=%r.\n", Status));
+// If we failed init, go back to requiring card detection
+CardDetectState = CardDetectRequired;
+return FALSE;
+  }
+
+  Status = MMCSendCommand (This, MMC_CMD0, 0);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "MMCIsCardPresent: CMD0 Error, Status=%r.\n", 
Status));
+goto out;
+  }
+
+  //
+  // CMD8 should tell us if a card is present.
+  //
+  Status = MMCSendCommand (This, MMC_CMD8, CMD8_SD_ARG);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_INFO, "MMCIsCardPresent: No card detected, Status=%r.\n", 
Status));
+goto out;
+  }
+
+  DEBUG ((DEBUG_INFO, "MMCIsCardPresent: Card detected.\n"));
+  CardIsPresent = TRUE;
+
+out:
+  CardDetectState = CardDetectCompleted;
+  return CardIsPresent;
+}
+
 EFI_STATUS
 MMCReceiveResponse (
   IN EFI_MMC_HOST_PROTOCOL*This,
diff --git a/Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c 
b/Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c
index 2f31c5eb8c46..d96344fd0f8e 100644
--- a/Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c
+++ b/Platform/RaspberryPi/Drivers/SdHostDxe/SdHostDxe.c
@@ -64,7 +64,9 @@ STATIC CONST CHAR8 *mFsmState[] = { "identmode", "datamode", 
"readdata",
 "genpulses", "writewait2", "?",
 "startpowdown" };
 #endif /* NDEBUG */
-STATIC UINT32 mLastGoodCmd = MMC_GET_INDX (MMC_CMD0);
+STATIC BOOLEAN CardIsPresent = FALSE;
+STATIC CARD_DETECT_STATE CardDetectState = C

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

On 2020.06.17 17:36, Andrei Warkentin wrote:

Thanks Pete.

I think the question I have, that I hope Tiano veterans can chime in, is 
whether we are doing the right thing, or if we should be overriding the 
boot mode? I.e. is it normal that we boot up in recovery until options 
are saved?


Yes, that's the other part of the problem, that I didn't want to bring 
in because it's Pi-platform specific and I still see OnReadyToBoot as an 
event we logically want to signal during Platform Recovery.


Still, that doesn't mean I wouldn't want to have feedback on this too.

Regards,

/Pete




A



*From:* devel@edk2.groups.io  on behalf of Pete 
Batard via groups.io 

*Sent:* Wednesday, June 17, 2020 11:34 AM
*To:* Wang, Sunny (HPS SW) ; devel@edk2.groups.io 

*Cc:* zhichao@intel.com ; ray...@intel.com 
; ard.biesheu...@arm.com ; 
l...@nuviainc.com 
*Subject:* Re: [edk2-devel] [edk2][PATCH 1/1] 
MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:

Thanks for checking my comments, Pete.


Or is the "one more" the issue, meaning that it would get signaled more than 
once?

[Sunny] Yeah, it would get signaled more than once if the PlatformRecovery 
option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered 
boot option inside of the application.


Okay.

One element that I'm going to point out is that, with the current EDK2
code (i.e. without this proposal applied), and after a user goes into
the setup to save their boot options in order for regular boot options
to get executed instead of PlaformRecovery, the OnReadyToBoot event is
actually called twice.

So my understanding is that, while we of course want to avoid this and
any patch proposal should actively try to prevent it, it seems we
already have behaviour in EDK2 that can lead to OnReadyToBoot being
signalled more than once.

At least the current Pi 4 platform does demonstrate this behaviour. For
instance, if you run DEBUG, you will see two instances of:

    RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the ConsolePrefDxe's
OnReadyToBoot() call. I've also confirmed more specifically that
OnReadyToBoot() is indeed called twice.

I don't recall us doing much of any special with regards to boot options
for the Pi platform, so my guess is that it's probably not the only
platform where OnReadyToBoot might be signalled more than once, and that
this might be tied to a default EDK2 behaviour. Therefore I don't see
having a repeated event as a major deal breaker (though, again, if we
can avoid that, we of course will want to).


I don't mind trying an alternative approach, but I don't understand how what 
you describe would help. Can you please be more specific about what you have in 
mind?

[Sunny] Sure. I added more information below. If it is still not clear enough, 
feel free to let me know.
   1. Create a UEFI application with the code to signal ReadyToBoot and 
pick /efi/boot/bootaa64.efi from either SD or USB and run it.


So that would basically be adding code that duplicates, in part, what
Platform Recovery already does.

I have to be honest: Even outside of the extra work this would require,
I don't really like the idea of having to write our own application, as
it will introduce new possible points of failures and require extra
maintenance (especially as we will want to be able to handle network
boot and other options, and before long, I fear that we're going to have
to write our own Pi specific boot manager). Doing so simply because the
current Platform Recovery, which does suit our needs otherwise, is not
designed to call ReadyToBoot does not seem like the best course of
action in my book.

Instead, I still logically believe that any option that calls a boot
loader should signal ReadyToBoot, regardless of whether it was launched
from Boot Manager or Platform Recovery, and that it shouldn't be left to
each platform to work around that.

Of course, I understand that this would require a specs change, and that
it also may have ramifications for existing platforms that interpret the
current specs pedantically. But to me, regardless of what the specs
appear to be limiting it to right now, the logic of a "ReadyToBoot"
event is that it should be signalled whenever a bootloader is about to
be executed, rather than only when a bootloader happened to be launched
through a formal Boot Manager option.

I would therefore appreciate if other people could weigh in on this
matter, to see if I'm the only one who believes that we could ultimately
have more to gain from signalling ReadyToBoot with PlatformRecovery
options than leaving things as they stand right now...


   2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE 
driver or other places before "Default PlatformRecovery&

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

 I was just thinking that we may not really need to make this behavior change 
in both EDK II code and UEFI specification for solving the problem specific to the case 
that OS is loaded by "Default PlatformRecovery" option,


The way I see it is that the Pi platform is unlikely to be the only one 
where PlatformRecovery is seen as a means to install an OS. Granted, 
this may seem like abusing the option, but since UEFI doesn't provide an 
"Initial OS Install" mode, I would assert that it as good a use of this 
option as any.


In other words, I don't think this improvement would only benefit the Pi 
platform.



and I'm also not sure if it is worth making this change to affect some of the 
system or BIOS vendors who have implemented their PlatformRecovery option.


That's a legitimate concern, and I would agree the one major potential 
pitfall of this proposal, if there happens to exist a system where an 
OnReadyToBoot even before running the recovery option can have adverse 
effects.


I don't really believe that such a system exists, because I expect most 
recovery boot loaders to also work (or at least have been designed to 
work) as regular boot options. But I don't have enough experience with 
platform recovery to know if that's a correct assertion to make...



If the alternative approach I mentioned works for you, I think that would be an 
easier solution.


Right now, even as the patch proposal has multiple issues that require 
it to be amended (Don't signal ReadyToBoot except for PlatformRecovery 
+ Prevent situations where ReadyToBoot could be signalled multiple 
times) I still see it as both an easier solution than the alternative, 
as well as one that *should* benefit people who design Platform Recovery 
UEFI applications in the long run. So that is why I am still trying to 
advocate for it.


But I very much hear your concerns, and I agree that specs changes are 
better avoided when possible.


Thus, at this stage, even as I don't want to drag this discussion much 
further, I don't feel like I want to commit to one solution or the other 
before we have had a chance to hear other people, who may have their own 
opinion on the matter, express their views.


Regards,

/Pete




Regards,
Sunny Wang

-Original Message-
From: Pete Batard [mailto:p...@akeo.ie]
Sent: Wednesday, June 17, 2020 6:59 PM
To: Wang, Sunny (HPS SW) ; devel@edk2.groups.io
Cc: zhichao@intel.com; ray...@intel.com; ard.biesheu...@arm.com; 
l...@nuviainc.com
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: 
Signal ReadyToBoot on platform recovery

Hi Sunny, thanks for looking into this.

On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:

Hi Pete.

Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as 
well, your change would also cause some unexpected behavior like:
1. Signal one more ReadyToBoot for the PlatformRecovery option which is an 
application that calls EfiBootManagerBoot() to launch its recovered boot option.


I'm not sure I understand how this part is unwanted.

The point of this patch is to ensure that ReadyToBoot is signalled for the 
PlatformRecovery option, so isn't what you describe above exactly what we want?

Or is the "one more" the issue, meaning that it would get signalled more than 
once?



2. Signal ReadyToBoot for SysPrep or Driver that is not really a "boot" 
option.


Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), 
which calls EfiBootManagerProcessLoadOption(),
mentions that it will load will load and start every Driver, SysPrep or 
PlatformRecovery. But the comment about the while() loop in 
EfiBootManagerProcessLoadOption() only mentions PlatformRecovery.

If needed, I guess we could amend the patch to detect the type of option and 
only signal ReadyToBoot for PlatformRecovery.


To solve your problem, creating a PlatformRecovery option with the smallest 
option number and using it instead of default one (with short-form File Path 
Media Device Path) looks like a simpler solution.


I don't mind trying an alternative approach, but I don't understand how what 
you describe would help. Can you please be more specific about what you have in 
mind?

Our main issue here is that we must have ReadyToBoot signalled so that the 
ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets 
executed in order for the boot loader invoked from PlatformRecovery  to use 
a properly initialized graphical console. So I'm not sure I quite get how 
switching from one PlatformRecovery option to another would improve things.

If it helps, here is what we currently default to, in terms of boot options, on 
a Raspberry Pi 4 platform with a newly build firmware:

[Bds]=Begin Load Options Dumping ...=
Driver Options:
SysPrep Options:
Boot Options:
  Boot: UiApp  0x0109
  Boot

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

ecovery can launch a /efi/boot/boot.efi bootloader then 
we must update the specs and the code to have ReadyToBoot also signalled 
then, because that's the logical thing to do). But right now, I'm not 
seeing how to achieve that when PlatformRecovery is the option that 
is used to launch the OS installation the bootloader. So if you can 
provide mode details on how exactly you think creating an alternate 
PlatformRecovery option would help, I would appreciate it.


Regards,

/Pete



Regards,
Sunny Wang

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Pete 
Batard
Sent: Tuesday, June 16, 2020 5:56 PM
To: devel@edk2.groups.io
Cc: zhichao@intel.com; ray...@intel.com; ard.biesheu...@arm.com; 
l...@nuviainc.com
Subject: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal 
ReadyToBoot on platform recovery

Currently, the ReadyToBoot event is only signaled when a formal Boot Manager 
option is executed (in BmBoot.c -> EfiBootManagerBoot ()).

However, with the introduction of Platform Recovery in UEFI 2.5, which may lead 
to the execution of a boot loader that has similar requirements to a regular 
one, yet is not launched as a Boot Manager option, it also becomes necessary to 
signal ReadyToBoot when a Platform Recovery boot loader runs.

Especially, this can be critical to ensuring that the graphical console is 
actually usable during platform recovery, as some platforms do rely on the 
ConsolePrefDxe driver, which only performs console initialization after 
ReadyToBoot is triggered.

This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in 
EfiBootManagerProcessLoadOption (), which is the function that sets up the 
platform recovery boot process.

Signed-off-by: Pete Batard 
---
  MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 89372b3b97b8..117f1f5b124c 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
  return EFI_SUCCESS;
}
  
+  //

+  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and 
execute the boot option.
+  //
+  EfiSignalEventReadyToBoot ();
+  //
+  // Report Status Code to indicate ReadyToBoot was signalled  //
+ REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER |
+ EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+
//
// Load and start the load option.
//
--
2.21.0.windows.1







-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61400): https://edk2.groups.io/g/devel/message/61400
Mute This Topic: https://groups.io/mt/74912987/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2][PATCH 0/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

This single patch addresses what we consider to be an overlook of the
current EDK2 codeset in that the ReadyToBoot event is only signaled when
a formal Boot Manager option is executed but not when a Platform Recovery
one is, whereas the boot loaders executed in both cases tend to be similar
in terms of requirements, and therefore, since there is no dedicated event
associated with pre Platform Recovery execution, ReadyToBoot should also
apply there.

Especially, this patch is required to fix an issue that we encounter on
the Raspberry Pi platform (https://github.com/pftf/RPi4/issues/64), as
it uses EmbeddedPkg/Drivers/ConsolePrefDxe to set up the graphical console
as default, but the code to switch to graphical is tied to the ReadyToBoot
event being triggered.

This means that, currently, unless users go to the UEFI options to save
their boot preferences, the console defaults to a non-initialized instance
that happens to be serial.

Obviously, this is very problematic as it means that installation of an
OS such as Debian-Linux (which Platform Recovery will boot into if the
ISO content have been extracted to a bootable drive) will occur on the
serial console rather than the graphical console by default, leaving
users, who do not have a serial adapter plugged in, getting only an
unexpected a black screen instead of the Debian installer...

Also, due to the nature of the UEFI firmware for the Raspberry Pi
platform, which actually resides on the bootable USB or SD media rather
than flash, and therefore is something that platform users are excepted
to update on a whim (with the effect of resetting all the UEFI variables
when they do so), and as opposed to what might be the case for other
platforms, it is not reasonable to expect for users to go to their
settings to set up the Boot Manager options so that they don't end up
using Platform Recovery. As a matter of fact, it's the opposite that is
likely to hold true, with most Raspberry Pi users using Platform
Recovery for their boot process. Especially, considering that the
platform defaults should be fine for most users, we do expect that
the bulk of UEFI vanilla Linux installations on the Raspberry Pi 4 are
going to use Platform Recovery instead of Boot Manager.

As such it is crucial that the Platform Recovery and formal Boot Manager
boot processes do behave similarly in terms of ReadyToBoot event being
signaled, hence the reason for this patch.


Note however that this may require a specs update, as the current UEFI
specs for EFI_BOOT_SERVICES.CreateEventEx() have:

> EFI_EVENT_GROUP_READY_TO_BOOT
>   This event group is notified by the system when the Boot Manager
>   is about to load and execute a boot option.

and, once this patch has been applied, we may want to update this
section to mention that it applies to both Boot Manager and Platform
Recovery.

Regards,

/Pete

Pete Batard (1):
  MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
recovery

 MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +
 1 file changed, 9 insertions(+)

-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61327): https://edk2.groups.io/g/devel/message/61327
Mute This Topic: https://groups.io/mt/74912985/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

Currently, the ReadyToBoot event is only signaled when a formal Boot
Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).

However, with the introduction of Platform Recovery in UEFI 2.5, which may
lead to the execution of a boot loader that has similar requirements to a
regular one, yet is not launched as a Boot Manager option, it also becomes
necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.

Especially, this can be critical to ensuring that the graphical console
is actually usable during platform recovery, as some platforms do rely on
the ConsolePrefDxe driver, which only performs console initialization after
ReadyToBoot is triggered.

This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in
EfiBootManagerProcessLoadOption (), which is the function that sets up the
platform recovery boot process.

Signed-off-by: Pete Batard 
---
 MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 89372b3b97b8..117f1f5b124c 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
 return EFI_SUCCESS;
   }
 
+  //
+  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and 
execute the boot option.
+  //
+  EfiSignalEventReadyToBoot ();
+  //
+  // Report Status Code to indicate ReadyToBoot was signalled
+  //
+  REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+
   //
   // Load and start the load option.
   //
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#61328): https://edk2.groups.io/g/devel/message/61328
Mute This Topic: https://groups.io/mt/74912987/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platform][PATCH v2 1/2] Platforms/RaspberryPi: Add RPi4 settings to Readme

[Pete Batard]

On 2020.06.15 22:43, Samer El-Haj-Mahmoud wrote:

Add a section to the the RPi4 Readme for 'Configuration Settings', with
instructions on scripting from the UEFI Shell.

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Pete Batard 
Cc: Andrei Warkentin 
Signed-off-by: Samer El-Haj-Mahmoud 
---
  Platform/RaspberryPi/RPi4/Readme.md | 74 +++-
  1 file changed, 73 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/RPi4/Readme.md 
b/Platform/RaspberryPi/RPi4/Readme.md
index 03eb6c391aca..98388e3caba1 100644
--- a/Platform/RaspberryPi/RPi4/Readme.md
+++ b/Platform/RaspberryPi/RPi4/Readme.md
@@ -143,4 +143,76 @@ all functionality may be available.
  
  - Network booting via onboard NIC.

  - SPCR hardcodes type to PL011, and thus will not expose correct
-  (miniUART) UART if DT overlays to switch UART are used on Pi 4B.
\ No newline at end of file
+  (miniUART) UART if DT overlays to switch UART are used on Pi 4B.
+
+# Configuration Settings
+The Raspberry Pi UEFI configuration settings can be viewed and changed using both 
the UI configuration menu (under `Device Manager` -> `Raspberry Pi 
Configuration`), as well as the UEFI Shell. To configure using the UEFI Shell, use 
`setvar` command to read/write the UEFI variables with GUID = 
`CD7CC258-31DB-22E6-9F22-63B0B8EED6B5`.
+
+The syntax to read a setting is:
+```
+setvar  -guid CD7CC258-31DB-22E6-9F22-63B0B8EED6B5
+```
+
+The syntax to write a setting is:
+```
+setvar  -guid CD7CC258-31DB-22E6-9F22-63B0B8EED6B5 -bs -rt -nv =
+```
+
+For string-type settings (e.g. Asset Tag), the syntax to write is:
+```
+setvar  -guid CD7CC258-31DB-22E6-9F22-63B0B8EED6B5 -bs -rt -nv 
=L"" =0x
+```
+
+UEFI Setting |NAME   |  VALUE
+-|---|-
+**CPU Configuration**|
+CPU Clock| `CpuClock` | Low = `0x` Default = `0x0001` 
(default) Max = `0x0002` Custom = `0x0003`
+CPU Clock Rate (MHz) | `CustomCpuClock` | Hex numeric value, 
4-bytes (e.g. `0x05DC` for 1500 MHz)
+**Display Configuration**|
+Virtual 640x480  | `DisplayEnableScaledVModes` | Checked = Bit 0 set 
(i.e.  ` \| 0x01`)
+Virtual 800x600  | `DisplayEnableScaledVModes` | Checked = Bit 1 set 
(i.e.  ` \| 0x02`)
+Virtual 1024x768 | `DisplayEnableScaledVModes` | Checked = Bit 2 set 
(i.e.  ` \| 0x04`)
+Virtual 720p | `DisplayEnableScaledVModes` | Checked = Bit 3 set 
(i.e.  ` \| 0x08`)
+Virtual 1080p| `DisplayEnableScaledVModes` | Checked = Bit 4 set 
(i.e.  ` \| 0x10`)
+Native resolution| `DisplayEnableScaledVModes` | Checked = Bit 5 set 
(i.e.  ` \| 0x20`) (default)
+Screenshot support   | `DisplayEnableSShot` | Control-Alt-F12 = `0x0001` 
(default) Not Enabled = `0x`
+**Advanced Configuration**   |
+Limit RAM to 3 GB| `RamLimitTo3GB` | Disable = `0x`  
Enabled= `0x0001` (default)
+System Table Selection   | `SystemTableMode`| ACPI = `0x` (default) 
ACPI + Devicetree = `0x0001`  Devicetree = `0x0002`
+Asset Tag| `AssetTag` | String, 32 characters or less (e.g. 
`L"ABCD123"`) (default `L""`)
+**SD/MMC Configuration** |
+uSD/eMMC Routing | `SdIsArasan` | Arasan SDHC = `0x0001` (default) 
 eMMC2 SDHCI = `0x`
+Multi-Block Support  | `MmcDisableMulti` | Multi-block transfers = 
`0x` (default) Single block transfers = `0x0001`
+uSD Max Bus Width| `MmcForce1Bit` | 4-bit Mode = `0x`  
(default) 1-bit Mode = `0x0001`
+uSD Force Default Speed  | `MmcForceDefaultSpeed` | Allow High Speed = 
`0x` (default) Force Default Speed = `0x0001`
+SD Default Speed (MHz)   | `MmcSdDefaultSpeedMHz` | Hex numeric value, 4-bytes 
(e.g. `0x0019` for 25 MHz)(default 25)
+SD High Speed (MHz)  | `MmcSdHighSpeedMHz` | Hex numeric value, 4-bytes 
(e.g. `0x0032` for 50 MHz)(default 50)
+**Debugging Configuration**  |
+JTAG Routing | `DebugEnableJTAG` | Enable JTAG via GPIO = 
`0x0001` Disable JTAG= `0x` (default)
+
+**Examples:**
+
+- To read the 'System Table Selection' setting :
+```
+setvar SystemTableMode -guid CD7CC258-31DB-22E6-9F22-63B0B8EED6B5
+```
+
+- To change the 'System Table Selection' setting to 'Devicetree' :
+```
+setvar SystemTableMode -guid CD7CC258-31DB-22E6-9F22-63B0B8EED6B5 -bs -rt -nv 
=0x0002
+```
+
+- To read the 'Limit RAM to 3 GB' setting:
+```
+setvar RamLimitTo3GB -guid CD7CC258-31DB-22E6-9F22-63B0B8EED6B5
+```
+
+- To change the 'Limit RAM to 3 GB' setting to 'Disabled':
+```
+setvar RamLimitTo3GB -guid CD7CC258-31DB-22E6-9F22-63B0B8EED6B5 -bs -rt -nv 
=0x
+```
+
+- To change the Asset Tag to the string "ASSET-TAG-123" :
+```
+setvar AssetTag -guid CD7CC258-31DB-22E6-9F22-63B0B8EE