Re: [edk2] [edk2-announce] Mailing List Move Day Set: April 4th

[Rebecca Cran via edk2-devel]

On 3/25/19 10:21 AM, stephano wrote:


This is a good point and shows the level of detail that is preserved 
by the mailing list if maintained properly. I would assume this is 
part of the reason that the Linux kernel has continued to use mailing 
lists for patch review as this level of detail is highly desired in 
their case.



Talking of such things, I noticed a couple weeks ago that the Gmane link 
at https://lists.01.org/mailman/listinfo/edk2-devel doesn't work .


From https://en.wikipedia.org/wiki/Gmane :

"In July 2016, Ingebrigtsen announced that he was considering shutting 
Gmane down, and the web interface was taken offline.^[2] 
<https://en.wikipedia.org/wiki/Gmane#cite_note-2> ^[3] 
<https://en.wikipedia.org/wiki/Gmane#cite_note-3> In August 2016 Gmane 
was acquired by Yomura Holdings. Only the message spool was transferred, 
with the software behind the site having to be redeveloped.^[4] 
<https://en.wikipedia.org/wiki/Gmane#cite_note-4> ^[5] 
<https://en.wikipedia.org/wiki/Gmane#cite_note-5> On the 6 September 
2016, it was announced that the Gmane web interface would be coming 
online again.^[6] <https://en.wikipedia.org/wiki/Gmane#cite_note-6> 
However, by February 2018 a LWN.net 
<https://en.wikipedia.org/wiki/LWN.net> article observed that the web 
interface did "never [...] return, breaking thousands of links across 
the net. The front page still says 'some things are very broken' and 
links to a blog page that was last updated in September 2016."^[7] 
<https://en.wikipedia.org/wiki/Gmane#cite_note-7>"



--
Rebecca Cran

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

Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow outdated sourceforge git mirror

[Rebecca Cran via edk2-devel]

On 3/25/19 5:49 AM, Laszlo Ersek wrote:


Any particular reason for dropping the website URL update?
<http://www.tianocore.org/edk2/> still redirects to
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II>, and your
previous patch (correctly) included that new URL.



Stephano recently posted a message with a link 
tohttps://www.tianocore.org/monthly-meeting/  which redirects to 
https://github.com/tianocore/tianocore.github.io/wiki/Monthly-Meeting, so I 
think it makes sense to keep the shorter/nicer URLs since there are redirects 
in place.

--
Rebecca Cran

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

[edk2] [PATCH] Fix links in Maintainers.txt and remove slow outdated sourceforge git mirror

[Rebecca Cran via edk2-devel]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Rebecca Cran 
---
 Maintainers.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index be77898ee2..4c9adf802b 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -40,10 +40,9 @@ Descriptions of section entries:
 EDK II
 --
 W: http://www.tianocore.org/edk2/
-L: https://lists.sourceforge.net/lists/listinfo/edk2-devel
+L: https://lists.01.org/mailman/listinfo/edk2-devel
 T: git - https://github.com/tianocore/edk2.git
 T: git (mirror) - https://bitbucket.org/tianocore/edk2.git
-T: git (mirror) - http://git.code.sf.net/p/tianocore/edk2
 T: svn (read-only, deprecated) - https://svn.code.sf.net/p/edk2/code/trunk/edk2
 
 Tianocore Stewards
-- 
2.21.0

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

Re: [edk2] [edk2-announce] March Community Meeting Minutes

[Rebecca Cran via edk2-devel]

On 3/11/19 4:20 PM, stephano wrote:


On 3/11/2019 1:55 PM, Rebecca Cran wrote:

You can't see without following the pull request *who* committed the 
change.  There are almost 1000 open pull requests, which is something 
we probably want to try and avoid. They also seem to have _lots_ of 
labels. I wonder if there's a cleaner way of handling them?


Agreed. We spoke about some of the downsides of pull requests in the 
last stewards meeting. Linus did a fair job of detailing some of these 
here:


https://github.com/torvalds/linux/pull/17

I'm going to work with EDK II maintainers to be sure that we do not 
move to a model that makes their life harder (e.g. 1000 open pull 
requests).





Also, about groups.io, I wonder if I might want to investigate their 
support for using our own domain, so people don't have to remember 
that the mailing list and documents are on groups.io and not 
tianocore.org?




Yes, I'm hoping to use our own domain with groups.io. Once we've 
completed the testing phase I'll bring this up to my boss(es) to get 
approval for an enterprise account ($200/month). That will allow us to 
use something more friendly with tianocore.org.



Thanks! Sorry for the skepticism, I've just had experiences in the past 
with new systems being introduced which made work more difficult (e.g. a 
commercial code review tool: several teams avoided it by using Review 
Board or Gerrit instead).



--
Rebecca Cran

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

Re: [edk2] [edk2-announce] March Community Meeting Minutes

[Rebecca Cran via edk2-devel]

On 3/11/19 10:33 AM, stephano wrote:



Stephano has taken an action item to work with the Kubernetes 
community to see what trade-offs and benefits they experience using 
GitHub. Kubernetes is one of the largest open source projects 
currently using GitHub for patch reviews. It is notable that a git 
module "request-pull" exists, and the kernel gives directions on how 
to use these "git style" of pull requests:



I took a look at the Kubernetes project a few days ago, and there are a 
couple of things we might _not_ want to copy, since they look to me to 
obfuscate things.


For example, the git log:


commit 50bf223a0545a121dc202de8fad673402b8ebde6 (HEAD -> master, 
origin/master, origin/HEAD)

Merge: 4ea48886df c5c4cd2580
Author: Kubernetes Prow Robot 
Date:   Mon Mar 11 12:00:15 2019 -0700

    Merge pull request #75224 from neolit123/certs-print-key-on-phase

    kubeadm: print key inside the upload-certs phase of init

commit 4ea48886df2e0830daa2384f6fe57dd55b8dbb51
Merge: 8477c486a8 58c7b5de9c
Author: Kubernetes Prow Robot 
Date:   Mon Mar 11 09:39:40 2019 -0700

    Merge pull request #75008 from nikopen/patch-4

    rebase audit-proxy image to distroless/static

commit 8477c486a81c1094440cf7c78d6be5c52b0828c4
Merge: 6ec5a7d337 fa926ed6e0
Author: Kubernetes Prow Robot 
Date:   Mon Mar 11 09:39:27 2019 -0700

    Merge pull request #74652 from cofyc/fix72500

    Delay CSI client initialization


You can't see without following the pull request *who* committed the 
change.  There are almost 1000 open pull requests, which is something we 
probably want to try and avoid. They also seem to have _lots_ of labels. 
I wonder if there's a cleaner way of handling them?



Also, about groups.io, I wonder if I might want to investigate their 
support for using our own domain, so people don't have to remember that 
the mailing list and documents are on groups.io and not tianocore.org?



--

Rebecca Cran

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

Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's public DNS servers

[Rebecca Cran via edk2-devel]

On 2/26/19 5:31 AM, Laszlo Ersek wrote:



Sorry for missing this earlier, but the patch misses the
Contributed-under and Signed-off-by lines, from the end of the commit
message.

Please repost like that, and then please also include the Reviewed-by
tags from Jaben and myself.



I'm just catching up on edk2 work again. I've just sent out a new patch.


--
Rebecca Cran

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

[edk2] [PATCH] StdLib: Update resolv.conf to use Google's DNS servers

[Rebecca Cran via edk2-devel]

The current servers listed appear to be unusable. I suspect most
people will get correct DNS servers via DHCP, but the defaults
should work for anyone.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Rebecca Cran 
Reviewed-by: Jaben Carsey 
Reviewed-by: Laszlo Ersek 
---
 StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/StdLib/Efi/StdLib/etc/resolv.conf 
b/StdLib/Efi/StdLib/etc/resolv.conf
index 3ac16ac230..724e6297b2 100644
--- a/StdLib/Efi/StdLib/etc/resolv.conf
+++ b/StdLib/Efi/StdLib/etc/resolv.conf
@@ -1,13 +1,13 @@
 #
 #   Domain name
 #
-domain  intel.com
+domain  example.com
 
 ;
 ;   Name Servers
 ;
-nameserver  206.63.63.61
-nameserver  216.251.100.1
+nameserver  8.8.8.8
+nameserver  8.8.4.4
 
 ; nameserver  10.248.2.1
 ; nameserver  10.22.224.204
-- 
2.21.0

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

Re: [edk2] Hang when calling ExitBootServices on IA32 firmware v1.0 on MinnowBoard Turbot

[Rebecca Cran via edk2-devel]

On 2/25/19 5:08 PM, Rebecca Cran via edk2-devel wrote:
I've been trying to test a boot loader on my MinnowBoard Turbot board. 
It's running the latest 1.0 firmware from firmware.intel.com, and I'm 
seeing a hang at the point when gBS->ExitBootServices is called.



I did more debugging using OVMF and found that the i386 boot loader code 
was trying to call printf (which allocates memory) after 
ExitBootServices. And that booting an i386 kernel isn't actually 
supported. So there's not a problem with the MinnowBoard firmware.



--
Rebecca Cran

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

Re: [edk2] [PATCH] Convert PosixLike scripts to sh, reduce duplication and fix some bugs

[Rebecca Cran via edk2-devel]

Thanks for the review. I have a macOS system, so I'll verify future 
changes work there too.


The problem I'm trying to solve is to make it easier to get started 
building EDK2 under FreeBSD. Currently it needs symlinks in 
BaseTools/Bin/FreeBSD-amd64 for gcc, ld, make, objcopy and python, and 
obviously needs bash installed. Since there seems to be relatively 
little shell code in the repo, I was thinking that avoiding the 
dependency on bash might be a relatively easy way to reduce the steps 
needed to get things working.



I'll try and remember about PatchCheck.py too.


--

Rebecca


On 2/25/19 8:11 PM, Feng, Bob C wrote:

Hi Rebecca,

I like the change of moving duplicated code into common files and the bug fix 
looks good.

I tested this patch on our CI system, it break the build on MacOS. There is no 
realpath command on MacOs shell.

For the patch itself, it need to pass the check of 
BaseTools/Scripts/PatchCheck.py.

Is there actual problem that need to be resolved by using sh instead of bash?

Thanks,
Bob

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Rebecca 
Cran via edk2-devel
Sent: Friday, February 22, 2019 1:13 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH] Convert PosixLike scripts to sh, reduce duplication and 
fix some bugs

Since the scripts in the PosixLike directory are very simple, convert them to 
use /bin/sh, and move duplicated code into common files (one for python 
scripts, one for C binaries).

Fix some bugs in edksetup.sh and BuildEnv: `test` uses single equals instead of 
double equals, and should have a space before the ending bracket. Fix some 
indentation, and if the user runs edksetup.sh with --help etc., quit after 
displaying the help message.
---
  BaseTools/BinWrappers/PosixLike/BPDG  | 15 ++
  BaseTools/BinWrappers/PosixLike/Brotli| 30 ++-
  .../BinWrappers/PosixLike/BrotliCompress  | 12 
  BaseTools/BinWrappers/PosixLike/DevicePath| 30 ++-
  BaseTools/BinWrappers/PosixLike/Ecc   | 15 ++
  BaseTools/BinWrappers/PosixLike/EfiRom| 30 ++-
  BaseTools/BinWrappers/PosixLike/GenCrc32  | 30 ++-
  BaseTools/BinWrappers/PosixLike/GenDepex  | 15 ++
  BaseTools/BinWrappers/PosixLike/GenFds| 15 ++
  BaseTools/BinWrappers/PosixLike/GenFfs| 30 ++-
  BaseTools/BinWrappers/PosixLike/GenFv | 30 ++-
  BaseTools/BinWrappers/PosixLike/GenFw | 30 ++-
  .../BinWrappers/PosixLike/GenPatchPcdTable| 15 ++
  BaseTools/BinWrappers/PosixLike/GenSec| 30 ++-
  .../BinWrappers/PosixLike/GenerateCapsule | 15 ++
  BaseTools/BinWrappers/PosixLike/LzmaCompress  | 30 ++-
  .../BinWrappers/PosixLike/LzmaF86Compress |  2 +-
  BaseTools/BinWrappers/PosixLike/PatchPcdValue | 15 ++
  BaseTools/BinWrappers/PosixLike/Pkcs7Sign | 15 ++
  .../PosixLike/Rsa2048Sha256GenerateKeys   | 15 ++
  .../BinWrappers/PosixLike/Rsa2048Sha256Sign   | 15 ++
  BaseTools/BinWrappers/PosixLike/Split | 30 ++-
  BaseTools/BinWrappers/PosixLike/TargetTool| 15 ++
  BaseTools/BinWrappers/PosixLike/TianoCompress | 30 ++-
  BaseTools/BinWrappers/PosixLike/Trim  | 15 ++
  BaseTools/BinWrappers/PosixLike/UPT   | 15 ++
  BaseTools/BinWrappers/PosixLike/VfrCompile| 30 ++-
  BaseTools/BinWrappers/PosixLike/VolInfo   | 30 ++-
  BaseTools/BinWrappers/PosixLike/build | 15 ++
  BaseTools/BinWrappers/PosixLike/common.sh | 12 
  BaseTools/BinWrappers/PosixLike/commonbin.sh  | 28 +
  BaseTools/BuildEnv|  3 +-
  edksetup.sh   | 12 
  33 files changed, 110 insertions(+), 559 deletions(-)  create mode 100644 
BaseTools/BinWrappers/PosixLike/common.sh
  create mode 100644 BaseTools/BinWrappers/PosixLike/commonbin.sh

diff --git a/BaseTools/BinWrappers/PosixLike/BPDG 
b/BaseTools/BinWrappers/PosixLike/BPDG
index c894384908..a9da3afb4b 100755
--- a/BaseTools/BinWrappers/PosixLike/BPDG
+++ b/BaseTools/BinWrappers/PosixLike/BPDG
@@ -1,14 +1,3 @@
-#!/usr/bin/env bash
-#python `dirname $0`/RunToolFromSource.py `basename $0` $*
+#!/bin/sh
  
-# If a ${PYTHON_COMMAND} command is available, use it in preference to python -if command -v ${PYTHON_COMMAND} >/dev/null 2>&1; then

-python_exe=${PYTHON_COMMAND}
-fi
-
-full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here -dir=$(dirname "$full_cmd") 
-cmd=${full_cmd##*/}
-
-export PYTHONPATH="$dir/../../Source/Python${PYTHONPATH:+:"$PYTHONPATH"}"
-exec "${python_

[edk2] Hang when calling ExitBootServices on IA32 firmware v1.0 on MinnowBoard Turbot

[Rebecca Cran via edk2-devel]

I've been trying to test a boot loader on my MinnowBoard Turbot board. 
It's running the latest 1.0 firmware from firmware.intel.com, and I'm 
seeing a hang at the point when gBS->ExitBootServices is called.


The last debug output is:

ConfigSccBootableDevicesAtExitBootService() End
SetUefiImageMemoryAttributes - 0x787EB000 - 0x4000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787E8000 - 0x3000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787E5000 - 0x3000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787E1000 - 0x4000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787DB000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787D5000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787CC000 - 0x9000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787C6000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787C3000 - 0x3000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787BD000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787B8000 - 0x5000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787B2000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787AC000 - 0x6000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787A9000 - 0x3000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787A5000 - 0x4000 
(0x0008)
SetUefiImageMemoryAttributes - 0x787A2000 - 0x3000 
(0x0008)
SetUefiImageMemoryAttributes - 0x7879F000 - 0x3000 
(0x0008)



The X64 firmware works fine: the boot loader finishes and the kernel 
starts running.


I looked to see where ConfigSccBootableDevicesAtExitBootService might 
be, and unfortunately it seems it's in one of the binary modules.


The code for the boot loader is in 
https://svnweb.freebsd.org/base/head/stand/efi/loader/bootinfo.c?revision=338022=markup 
.



--
Rebecca Cran

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

[edk2] [PATCH] StdLib: Update resolv.conf to use Google's public DNS servers

[Rebecca Cran via edk2-devel]

The current servers listed appear to be unusable. I suspect most
people will get correct DNS servers via DHCP, but the defaults
should work for anyone.

Change the entries to be Google's public DNS servers.
Also, change the domain name to be example.com, to be more applicable
to consumers outside Intel.
---
 StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/StdLib/Efi/StdLib/etc/resolv.conf 
b/StdLib/Efi/StdLib/etc/resolv.conf
index 3ac16ac230..724e6297b2 100644
--- a/StdLib/Efi/StdLib/etc/resolv.conf
+++ b/StdLib/Efi/StdLib/etc/resolv.conf
@@ -1,13 +1,13 @@
 #
 #   Domain name
 #
-domain  intel.com
+domain  example.com
 
 ;
 ;   Name Servers
 ;
-nameserver  206.63.63.61
-nameserver  216.251.100.1
+nameserver  8.8.8.8
+nameserver  8.8.4.4
 
 ; nameserver  10.248.2.1
 ; nameserver  10.22.224.204
-- 
2.20.1

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

Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's DNS servers.

[Rebecca Cran via edk2-devel]

On February 25, 2019 at 3:11:16 AM, Laszlo Ersek 
(ler...@redhat.com(mailto:ler...@redhat.com)) wrote: 

> 
> Can you please repost the patch with an updated subject line / commit
> message? That way we can apply it with git-am without tweaking on the
> maintainer side. 





Sure!






Rebecca





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

Re: [edk2] [PATCH] Fix links in Maintainers.txt and remove slow, outdated sourceforge git mirror

[Rebecca Cran via edk2-devel]

On 2/22/19 10:18 PM, Rebecca Cran wrote:


-T: git (mirror) - http://git.code.sf.net/p/tianocore/edk2



I removed the sourceforge git mirror because the latest changeset is 
from a couple of weeks ago. We already have Github and Bitbucket, so I'm 
not sure of the value of having a third mirror that's relatively slow to 
clone and gets outdated?



--

Rebecca Cran

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

[edk2] [PATCH] Fix links in Maintainers.txt and remove slow, outdated sourceforge git mirror

[Rebecca Cran via edk2-devel]

---
 Maintainers.txt | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 7f1061d6c1..d9d3d840c5 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -31,11 +31,10 @@ Descriptions of section entries:
 
 EDK II
 --
-W: http://www.tianocore.org/edk2/
-L: https://lists.sourceforge.net/lists/listinfo/edk2-devel
+W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
+L: https://lists.01.org/mailman/listinfo/edk2-devel
 T: git - https://github.com/tianocore/edk2.git
 T: git (mirror) - https://bitbucket.org/tianocore/edk2.git
-T: git (mirror) - http://git.code.sf.net/p/tianocore/edk2
 T: svn (read-only, deprecated) - https://svn.code.sf.net/p/edk2/code/trunk/edk2
 
 Tianocore Stewards
@@ -203,7 +202,7 @@ W: 
https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
 M: Ruiyu Ni 
 
 OvmfPkg
-W: http://www.tianocore.org/ovmf/
+W: https://github.com/tianocore/tianocore.github.io/wiki/OVMF
 M: Jordan Justen 
 M: Laszlo Ersek 
 M: Ard Biesheuvel 
-- 
2.20.1

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

Re: [edk2] [PATCH] StdLib: Update resolv.conf to use Google's DNS servers.

[Rebecca Cran via edk2-devel]

Sorry, I've fixed the subject line and added maintainers to the Cc list.

This patch also changes the domain from intel.com to example.com, to be 
more applicable to consumers outside Intel.



--

Rebecca Cran


On 2/22/19 8:38 PM, Rebecca Cran wrote:

The current servers listed appear to be unusable. I suspect most
people will get correct DNS servers via DHCP, but the defaults
should work for anyone.
---
  StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/StdLib/Efi/StdLib/etc/resolv.conf 
b/StdLib/Efi/StdLib/etc/resolv.conf
index 3ac16ac230..724e6297b2 100644
--- a/StdLib/Efi/StdLib/etc/resolv.conf
+++ b/StdLib/Efi/StdLib/etc/resolv.conf
@@ -1,13 +1,13 @@
  #
  #   Domain name
  #
-domain  intel.com
+domain  example.com
  
  ;

  ;   Name Servers
  ;
-nameserver  206.63.63.61
-nameserver  216.251.100.1
+nameserver  8.8.8.8
+nameserver  8.8.4.4
  
  ; nameserver  10.248.2.1

  ; nameserver  10.22.224.204

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

[edk2] [PATCH] Update resolv.conf to use Google's DNS servers.

[Rebecca Cran via edk2-devel]

The current servers listed appear to be unusable. I suspect most
people will get correct DNS servers via DHCP, but the defaults
should work for anyone.
---
 StdLib/Efi/StdLib/etc/resolv.conf | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/StdLib/Efi/StdLib/etc/resolv.conf 
b/StdLib/Efi/StdLib/etc/resolv.conf
index 3ac16ac230..724e6297b2 100644
--- a/StdLib/Efi/StdLib/etc/resolv.conf
+++ b/StdLib/Efi/StdLib/etc/resolv.conf
@@ -1,13 +1,13 @@
 #
 #   Domain name
 #
-domain  intel.com
+domain  example.com
 
 ;
 ;   Name Servers
 ;
-nameserver  206.63.63.61
-nameserver  216.251.100.1
+nameserver  8.8.8.8
+nameserver  8.8.4.4
 
 ; nameserver  10.248.2.1
 ; nameserver  10.22.224.204
-- 
2.20.1

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

Re: [edk2] [edk2-announce] Community Meeting Minutes

[Rebecca Cran via edk2-devel]

On 2/8/19 10:52 AM, Andrew Fish wrote:


I think the patch workflow is kind of like a coding standards. Some folks 
advocate for lots of small patches (common in open source projects), and some 
folks advocate for a patch per bug. I think the biggest upside to the patch 
granularity is it is much easier to bisect a failure.

So I've used Bitbucket with a branch per commit (you name your branch with a 
standard pattern and the bugzilla  ) model and if your branch has a patch 
series (set of commits) you can view each commit independently from the UI and 
the default view is the entire patch series. So you can see both.



I think I see the difference now: I've used several review systems, most 
recently including Bitbucket, and with Review Board, Phabricator, and I 
think Gerrit people tend to post several patches against the same bug, 
often not labeling them as patch 1/3, 2/3 etc. but just using the same 
bug number.


Seeing the entire series clearly as an email thread on here is rather nice.


--

Rebecca Cran

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

[edk2] [PATCH] Convert PosixLike scripts to sh, reduce duplication and fix some bugs

[Rebecca Cran via edk2-devel]

Since the scripts in the PosixLike directory are very simple, convert
them to use /bin/sh, and move duplicated code into common files (one for
python scripts, one for C binaries).

Fix some bugs in edksetup.sh and BuildEnv: `test` uses single equals instead
of double equals, and should have a space before the ending bracket. Fix
some indentation, and if the user runs edksetup.sh with --help etc., quit
after displaying the help message.
---
 BaseTools/BinWrappers/PosixLike/BPDG  | 15 ++
 BaseTools/BinWrappers/PosixLike/Brotli| 30 ++-
 .../BinWrappers/PosixLike/BrotliCompress  | 12 
 BaseTools/BinWrappers/PosixLike/DevicePath| 30 ++-
 BaseTools/BinWrappers/PosixLike/Ecc   | 15 ++
 BaseTools/BinWrappers/PosixLike/EfiRom| 30 ++-
 BaseTools/BinWrappers/PosixLike/GenCrc32  | 30 ++-
 BaseTools/BinWrappers/PosixLike/GenDepex  | 15 ++
 BaseTools/BinWrappers/PosixLike/GenFds| 15 ++
 BaseTools/BinWrappers/PosixLike/GenFfs| 30 ++-
 BaseTools/BinWrappers/PosixLike/GenFv | 30 ++-
 BaseTools/BinWrappers/PosixLike/GenFw | 30 ++-
 .../BinWrappers/PosixLike/GenPatchPcdTable| 15 ++
 BaseTools/BinWrappers/PosixLike/GenSec| 30 ++-
 .../BinWrappers/PosixLike/GenerateCapsule | 15 ++
 BaseTools/BinWrappers/PosixLike/LzmaCompress  | 30 ++-
 .../BinWrappers/PosixLike/LzmaF86Compress |  2 +-
 BaseTools/BinWrappers/PosixLike/PatchPcdValue | 15 ++
 BaseTools/BinWrappers/PosixLike/Pkcs7Sign | 15 ++
 .../PosixLike/Rsa2048Sha256GenerateKeys   | 15 ++
 .../BinWrappers/PosixLike/Rsa2048Sha256Sign   | 15 ++
 BaseTools/BinWrappers/PosixLike/Split | 30 ++-
 BaseTools/BinWrappers/PosixLike/TargetTool| 15 ++
 BaseTools/BinWrappers/PosixLike/TianoCompress | 30 ++-
 BaseTools/BinWrappers/PosixLike/Trim  | 15 ++
 BaseTools/BinWrappers/PosixLike/UPT   | 15 ++
 BaseTools/BinWrappers/PosixLike/VfrCompile| 30 ++-
 BaseTools/BinWrappers/PosixLike/VolInfo   | 30 ++-
 BaseTools/BinWrappers/PosixLike/build | 15 ++
 BaseTools/BinWrappers/PosixLike/common.sh | 12 
 BaseTools/BinWrappers/PosixLike/commonbin.sh  | 28 +
 BaseTools/BuildEnv|  3 +-
 edksetup.sh   | 12 
 33 files changed, 110 insertions(+), 559 deletions(-)
 create mode 100644 BaseTools/BinWrappers/PosixLike/common.sh
 create mode 100644 BaseTools/BinWrappers/PosixLike/commonbin.sh

diff --git a/BaseTools/BinWrappers/PosixLike/BPDG 
b/BaseTools/BinWrappers/PosixLike/BPDG
index c894384908..a9da3afb4b 100755
--- a/BaseTools/BinWrappers/PosixLike/BPDG
+++ b/BaseTools/BinWrappers/PosixLike/BPDG
@@ -1,14 +1,3 @@
-#!/usr/bin/env bash
-#python `dirname $0`/RunToolFromSource.py `basename $0` $*
+#!/bin/sh
 
-# If a ${PYTHON_COMMAND} command is available, use it in preference to python
-if command -v ${PYTHON_COMMAND} >/dev/null 2>&1; then
-python_exe=${PYTHON_COMMAND}
-fi
-
-full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here
-dir=$(dirname "$full_cmd")
-cmd=${full_cmd##*/}
-
-export PYTHONPATH="$dir/../../Source/Python${PYTHONPATH:+:"$PYTHONPATH"}"
-exec "${python_exe:-python}" -m $cmd.$cmd "$@"
+. "$(dirname "$(realpath "$0")")/common.sh"
diff --git a/BaseTools/BinWrappers/PosixLike/Brotli 
b/BaseTools/BinWrappers/PosixLike/Brotli
index 0945d86d92..3dfa26e517 100755
--- a/BaseTools/BinWrappers/PosixLike/Brotli
+++ b/BaseTools/BinWrappers/PosixLike/Brotli
@@ -1,29 +1,3 @@
-#!/usr/bin/env bash
-
-full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here
-dir=$(dirname "$full_cmd")
-cmd=${full_cmd##*/}
-
-if [ -n "$WORKSPACE" ] && [ -e "$WORKSPACE/Conf/BaseToolsCBinaries" ]
-then
-  exec "$WORKSPACE/Conf/BaseToolsCBinaries/$cmd"
-elif [ -n "$WORKSPACE" ] && [ -e "$EDK_TOOLS_PATH/Source/C" ]
-then
-  if [ ! -e "$EDK_TOOLS_PATH/Source/C/bin/$cmd" ]
-  then
-echo "BaseTools C Tool binary was not found ($cmd)"
-echo "You may need to run:"
-echo "  make -C $EDK_TOOLS_PATH/Source/C"
-  else
-exec "$EDK_TOOLS_PATH/Source/C/bin/$cmd" "$@"
-  fi
-elif [ -e "$dir/../../Source/C/bin/$cmd" ]
-then
-  exec "$dir/../../Source/C/bin/$cmd" "$@"
-else
-  echo "Unable to find the real '$cmd' to run"
-  echo "This message was printed by"
-  echo "  $0"
-  exit 127
-fi
+#!/bin/sh
 
+. "$(dirname "$(realpath "$0")")/commonbin.sh"
diff --git a/BaseTools/BinWrappers/PosixLike/BrotliCompress 
b/BaseTools/BinWrappers/PosixLike/BrotliCompress
index ea86705a28..7cb26a3659 100755
--- 

[edk2] [PATCH] BaseTools: Convert PosixLike scripts to sh, reduce duplication and fix some bugs in edksetup.sh and BuildEnv

[Rebecca Cran via edk2-devel]

To make it easier to use EDK2 on systems other than Linux, where the default 
shell might
not be bash, I'd like to convert the shell scripts to use POSIX sh where 
possible.

edksetup.sh and BuildEnv remain bash scripts, but I hope to convert them to sh 
in a future
changeset.

I did see the argument against using $0 in 
http://mywiki.wooledge.org/BashFAQ/028, but I'm
not sure anyone using EDK2 will run into problems the article describes.

I checked the scripts with shellcheck.


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

[edk2] Configure bugs.tianocore.org as an alias for bugzilla.tianocore.org?

[Rebecca Cran via edk2-devel]

Could we allow people to access the Bugzilla tracker via 
bugs.tianocore.org (in addition to bugzilla.tianocore.org) please?


It looks like .tianocore.org (except www, bugzilla etc.) is 
configured as address 54.245.252.80, which just times out trying to 
access via http or https.



--
Rebecca Cran

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

Re: [edk2] [edk2-announce] Community Meeting Minutes

[Rebecca Cran via edk2-devel]

On Tuesday, 19 February 2019 23:23:59 MST stephano wrote:

> Github Pull Requests
> -
> We are still considering Github as a possible platform for patch review.

One thing I've not seen mentioned here is that there's an official command line 
tool for GitHub, named 'hub': https://hub.github.com/

>From the output of 'hub --help':

These GitHub commands are provided by hub:

   browse Open a GitHub page in the default browser
   ci-status  Show the status of GitHub checks for a commit
   compareOpen a compare page on GitHub
   create Create this repository on GitHub and add GitHub as origin
   delete Delete a repository on GitHub
   fork   Make a fork of a remote repository on GitHub and add as 
remote
   issue  List or create GitHub issues
   pr List or checkout GitHub pull requests
   pull-request   Open a pull request on GitHub
   releaseList or create GitHub releases
   sync   Fetch git objects from upstream and update branches


-- 
Rebecca Cran


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

Re: [edk2] Issues with EDK-II-Debugging wiki page, and how to submit a pull request for wiki pages

[Rebecca Cran via edk2-devel]

On Thursday, 14 February 2019 12:23:05 MST Laszlo Ersek wrote:

> The wikis on github are non-intuitive, if you intend to edit them in a
> normal text editor, locally. I struggled a lot until I came up with the
> list on top. (It's possible I relied on others' advice in that; I no
> longer remember.) I hope it helps.

Yeah, thanks but no thanks. I'm not _that_ keen on making my changes if it's 
going to involve all that work!

-- 
Rebecca Cran


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

Re: [edk2] [edk2-announce] Community Meeting Minutes

[Rebecca Cran via edk2-devel]

On 2/14/19 3:13 PM, Kinney, Michael D wrote:

You can review the groups.io features.  I think what you
want is available.  Stephano has also setup an edk2 area
in groups.io for community member to try out.

https://groups.io/static/help#features

There are a number of CI services that are integrated with
GitHub.

https://github.com/marketplace/category/continuous-integration

There is work to be done to enable one of these CI services
for edk2.  Stephano has a community task to evaluate and
select a CI service.



Thanks, I'm cautiously optimistic that groups.io will maintain a nice 
email interface to the list(s). However I don't see any messages/topics 
(in https://edk2.groups.io/g/main), and it appears my test posts are 
being moderated: are there plans to start active testing at some point?



I'm not sure I'll ever be a fan of Github but hopefully it's something 
we can move forward with - and I'll continue providing other services I 
feel are missing, from the server in my basement :)



--
Rebecca Cran

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

Re: [edk2] [edk2-announce] Community Meeting Minutes

[Rebecca Cran via edk2-devel]

As a casual contributor, for me the biggest complaint I have is how busy 
the mailing list gets. I don't think a new 'announce' list is what's 
needed, perhaps a 'reviews' or 'discussion' list to split out 
discussions (from anyone) from day-to-day patches? Also, I'd be anxious 
about jumping to a new service like groups.io: most open source 
developers understand plain email, and personally I'd like that to stay. 
For example FreeBSD set up web forums, but most contributors continue to 
use the existing mailman based lists, and I suspect tend to forget the 
web interface exists.



One thing I feel that's missing from the current Github-based 
infrastructure of the web site and wiki is that as far as I know there's 
no API documentation built regularly, or automated builds etc. I'm 
hosting the API documentation at e.g. 
https://code.bluestop.org/edk2/docs/master/ . Also, one thing a review 
system like Gerrit, Github, Phabricator, Review Board etc. would give us 
is the ability to run tests (lint, build/run OVMF etc.) against patches 
and have it comment on the review about its status to give committers 
more confidence in it.



--

Rebecca Cran


On 2/14/19 12:07 PM, Jeremiah Cox via edk2-devel wrote:

Hi Ard,
My apologies as no insult was intended.  The suggestion is that, similar to 
today, folks encountering difficulties with our systems could reach out to the 
TianoCore discussion venue (our mailing list or groups.io), and our friendly 
community members (we have many) will surely assist them.

You are correct that my focus is not casual contributors, rather I want to 
encourage a large number of UEFI developers who are currently closed to stop 
their fork-modify-ship model, which is inefficient to service, go open to share 
their learnings, get current, stay current, upstream their changes (where it 
makes sense to the community), but not throw garbage over the wall.   I think 
there is some value in this endeavor.

Kind Regards,
Jeremiah


From: Ard Biesheuvel 
Sent: Friday, February 8, 2019 5:58 AM
To: Jeremiah Cox
Cc: stephano; edk2-devel@lists.01.org; Kinney, Michael D; Laszlo Ersek
Subject: Re: [edk2] [edk2-announce] Community Meeting Minutes

On Thu, 7 Feb 2019 at 18:52, Jeremiah Cox via edk2-devel
 wrote:

Apologies on the late reply, I was on vacation for several weeks and just got 
back to this.

Regarding "Patch Review System Evaluation", on the call, I disagreed with your 
conclusion, but that note is not captured below.  My reading of the email and call discussions, I 
did not hear our community reject GitHub, rather observations that it was not "perfect", 
that it does not transparently interact with folks who prefer mailing list patch systems, but it 
would be acceptable to try.  On the call you mentioned a second justification for staying with the 
mailing list system, that GitHub (really all modern patch management systems) exclude folks who 
have limited internet connectivity.  I hypothesize that this theoretical group of Tianocore 
contributors would be a very small group of folks.  Should our community optimize our systems for a 
very small, theoretical group, penalizing the overwhelming majority?  I would propose that we try a 
modern patch management system, GitHub had the best reviews in my reading, and folks with limited 
internet connectivity find a friend to act as a go between translating their email diffs into 
GitHub PRs.

I find this unnecessarily condescending. Finding a friend, seriously?

Very serious concerns have been raised about the lack of transparency
with the various systems, and the fact that I am able to consult my
own local copy of the entire review history, including all email
exchanges is a very important aspect of the current model to me, as
opposed to GitHub deciding what is important enough to keep and what
is not. In an open source project, the code base is *not* the HEAD
commit, it is the entire repository, including history, and logged
email threads with technical discussions, since they are usually not
captured in other ways.

The push to GitHub is being sold to us as a way to attract more
contributors, but it seems to me (and I have stated this multiple
times) that the mailing list is not the steep part of the learning
curve when contributing to TianoCore. So is this really about getting
outsiders to contribute to Tianocore? Or is it about reducing the
impedance mismatch with what internal teams at MicroSoft (and Intel?)
are doing, which probably already went through the learning curve when
it comes to other aspects of Tianocore.

 From a high level, it might seem that using a mailing list is the
impediment here. But in reality, contributing to open source in
general is not about whether you use GitHub or a mailing list to throw
your stuff over the fence. It is about collaborating with the
community to find common ground between the various sometimes
conflicting interests, and permitting your

[edk2] Issues with EDK-II-Debugging wiki page, and how to submit a pull request for wiki pages

[Rebecca Cran via edk2-devel]

I noticed a couple of issues with the page 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Debugging - 
'SNI' should be 'SNP', and the |PcdDebugPrintErrorLevel is missing some 
entries.

|


How do I fork the wiki repo to make a pull request? On each page there's 
a "Clone this wiki locally" box where I can clone 
https://github.com/tianocore/tianocore.github.io.wiki.git, but when I 
try and fork it I instead fork 
https://github.com/tianocore/tianocore.github.io which doesn't have the 
same files either on the master or gh-pages branches - it looks like 
https://github.com/tianocore/tianocore.github.io has the files for 
www.tianocore.org, not the wiki?



--
Rebecca Cran

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

Re: [edk2] OVMF and TCP4, HTTP protocols

[Rebecca Cran via edk2-devel]

On 2/12/19 10:44 PM, Laszlo Ersek wrote:


In your case, I think it should suffice to call ConnectController() with
Recursive=FALSE, on the controller that already has SNP. The
HttpServiceBinding, Tcp6ServiceBinding and TCPv4ServiceBinding protocols
seem to be installed on the same handle. (The device path on this handle
ends with the MAC() node.)



Thanks again. Calling CloseProtocol, DisconnectController and then 
ConnectController got things working.



--

Rebecca Cran

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

Re: [edk2] OVMF and TCP4, HTTP protocols

[Rebecca Cran via edk2-devel]

On February 6, 2019 at 4:08:03 PM, Rebecca Cran via edk2-devel 
(edk2-devel@lists.01.org) wrote:

Oh, that makes sense! Thanks, after disabling the existing code that was 
opening SNP exclusively, things started working much better. 


I have a follow-up question. After opening the EFI_SIMPLE_NETWORK protocol 
exclusively, should code be able to later call gBS->CloseProtocol on the handle 
and subsequently start using TCP/HTTP? 

From what I’ve seen, closing the protocol (I’m also calling net->Shutdown(), 
and the CloseProtocol succeeds) has no effect and the TCP and HTTP protocols 
still can’t be found/used.



— 

Rebecca Cran

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

Re: [edk2] [edk2-announce] Community Meeting Minutes

[Rebecca Cran via edk2-devel]

On February 8, 2019 at 2:01:59 AM, Laszlo Ersek 
(ler...@redhat.com(mailto:ler...@redhat.com)) wrote:

> I don't see the workflow modification as viable. The "patch series"
> concept is integral to every single open source project that I've ever
> worked with. The evolution of a feature or a bug fix over a series of
> patches is a core facet of programming and reviewing. It communicates a
> thinking process, and that's what programming is about.  

I don’t recall coming across the patch series (e.g. the 1/5 email patches) in 
other projects. In other projects people post a single patch and then update it 
following feedback on the same review. This can be either in a single, rebased 
commit, or new commits on a bug/feature branch - review systems deal with both.

> So how long do we wait?
>  


Good point!  

>  
>  
> What I find practical at this moment is what Stephano has been working
> on (thank you for all that Stephano) -- collect & file official
> improvement requests with GitHub, and then see how those things are
> addressed. In my opinion (not having seen Gerrit anyway, which remains
> to be evaluated, but not by me), GitHub is the direct runner up to the
> mailing list, so improving GitHub would be the most practical. In
> particular I envision the context improvements for the GitHub email
> notifications as something very doable for GitHub.  





I’d certainly be happy to use Github, but I do worry about tieing ourselves to 
such a closed system.






Rebecca

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

Re: [edk2] [edk2-announce] Community Meeting Minutes

[Rebecca Cran via edk2-devel]

On Thursday, 7 February 2019 11:30:38 MST stephano wrote:

> My apologies if I was not clear in the minutes. We are not rejecting 
> Github, but rather taking time to evaluate how we can supplement 
> Github's features to emulate our current patch review requirements. We 
> do not want to rush into change and risk losing data or causing 
> frustration for those developers currently contributing on a regular basis.
> 
> I am currently working off this list of issues that Laszlo brought up:
> 
> https://lists.01.org/pipermail/edk2-devel/2018-December/033509.html
> 
> To be clear, Laszlo is not the only package maintainer that has voiced 
> these concerns. The longevity of pull request branches and the fact that 
> email notifications lack context are top on my list. There are several 
> ways to overcome these obstacles, and finding the best solution will 
> ensure that if we transition to Github, that transition is successful.
> 
> The ability to allow developers to work offline (or with intermittent 
> connections) is an important aspect as well. We cannot practice 
> exclusionary or ostracizing behaviors if we expect to grow and maintain 
> a community. I cannot imagine that Github has become as popular as it is 
> if it cannot facilitate ease of offline use.

I wonder if Phabricator could be considered again, since I believe it supports 
all the features mentioned: the only thing it doesn't support as a first-class 
feature is mutli-patch reviews, which need to be done by linking separate 
reviews together using the dependency feature. I wonder if it could either be 
enhanced to support that, or people's workflow modified?

-- 
Rebecca Cran


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

Re: [edk2] OVMF and TCP4, HTTP protocols

[Rebecca Cran via edk2-devel]

On Wednesday, 6 February 2019 12:05:08 MST Laszlo Ersek wrote:

> Is "loader.efi" opaque, or do we know what it does?

It's the FreeBSD loader, so I have the complete source code for it and can 
rebuild it.

> For example, if it opens SNP with BY_DRIVER|EXCLUSIVE attributes, then
> everything on top will be disconnected.

Oh, that makes sense! Thanks, after disabling the existing code that was 
opening SNP exclusively, things started working much better.


-- 
Rebecca Cran


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

Re: [edk2] OVMF and TCP4, HTTP protocols

[Rebecca Cran via edk2-devel]

On Wednesday, 6 February 2019 09:36:43 MST Laszlo Ersek wrote:

> please refer to the HTTP_BOOT_ENABLE define in the OVMF DSC files; the
> default value is FALSE.
> 
> If you'd like HTTP over IPv6, then please pass -D NETWORK_IP6_ENABLE on
> the "build" cmdline as well.

Thanks. I'm already building with HTTP_BOOT_ENABLE though, and successfully 
fetching loader.efi from the web server. However once loader.efi runs, my code 
can't find the HTTP or TCPv4 protocols.

>>Start HTTP Boot over IPv4.
  Station IP address is 192.168.0.119

  URI: http://192.168.0.1/boot/loader.efi
  File Size: 480256 Bytes
  Downloading...100%

-- 
Rebecca Cran


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

[edk2] OVMF and TCP4, HTTP protocols

[Rebecca Cran via edk2-devel]

I'm trying to fetch a file over HTTP in a boot loader, but gBS-
>LocateHandleBuffer doesn't find either of the EFI_TCP4_SERVICE_BINDING_PROTCOL 
or EFI_HTTP_SERVICE_BINDING_PROTOCOL.

I'm running a build of OVMF from git master from a few weeks ago.
Should they exist and be usable, or does OVMF only support the 
EFI_SIMPLE_NETWORK_PROTOCOL?

-- 
Rebecca Cran


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

Re: [edk2] [edk2-announce] February Community Meeting

[Rebecca Cran via edk2-devel]

On Thursday, 31 January 2019 09:49:23 MST stephano wrote:
> We will be holding our February Community Meeting on the *2nd* Thursday
> of February to accommodate holiday schedules. Details are posted here:
> 
> https://www.tianocore.org/community-meeting/

That page 
(https://github.com/tianocore/tianocore.github.io/wiki/Community-Virtual-Meetings)
 still says "January Meeting Details" but has the details for 
February.

-- 
Rebecca Cran


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

Re: [edk2] [edk2-announce] Community Meeting Minutes

[Rebecca Cran via edk2-devel]

On Friday, 11 January 2019 12:26:30 MST stephano wrote:

> Patch Review System Evaluation
> --
> After evaluating Github, Gitlab, and Phabricator, we will be remaining
> with the mailing list for now. Github did prove a possible "2nd runner
> up" (albeit distant). Also, Stephano / Nate from Intel will be reviewing
> Gerrit use with a report being sent back to the community sometime next
> week.

I wonder if we might want to have a separate mailing list for reviews? 

I find it a bit overwhelming having both patches and more general discussions 
on the same list, since I only check it every few days.

-- 
Rebecca Cran


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

[edk2] Undefined symbols AsmCpuid, AsmReadCr0 etc. when building OvmfPkgX64 on FreeBSD

[Rebecca Cran via edk2-devel]

While the RELEASE build of OvmfPkgX64 works fine, the DEBUG build is failing 
with undefined symbols AsmCpuid etc. when building on my FreeBSD 13-CURRENT 
system.
I’m trying to build git revision 559a07d84e5af3db09ae91844e4cb924b8f60668 (from 
Thu Dec 13 16:48:44 2018 -0700).
I’m building with gcc 7.4, running the command:

build -p OvmfPkg/OvmfPkgX64.dsc -t GCC5 -b DEBUG -a X64

The last few lines of output are:


"gcc" -o 
/home/bcran/workspace/edk2/Build/OvmfX64/DEBUG_GCC5/X64/IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe/DEBUG/Ps2KeyboardDxe.dll
 -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x40 
-Wl,--entry,_ModuleEntryPoint -u _ModuleEntryPoint 
-Wl,-Map,/home/bcran/workspace/edk2/Build/OvmfX64/DEBUG_GCC5/X64/IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe/DEBUG/Ps2KeyboardDxe.map,--whole-archive
 -Wl,-melf_x86_64,--oformat=elf64-x86-64,-pie -flto -Os 
-Wl,--start-group,@/home/bcran/workspace/edk2/Build/OvmfX64/DEBUG_GCC5/X64/IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe/OUTPUT/static_library_files.lst,--end-group
 -g -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
-Wno-array-bounds -ffunction-sections -fdata-sections -include AutoGen.h 
-fno-common -DSTRING_ARRAY_NAME=Ps2KeyboardDxeStrings -m64 -fno-stack-protector 
"-DEFIAPI=__attribute__((ms_abi))" -maccumulate-outgoing-args -mno-red-zone 
-Wno-address -mcmodel=small -fpie -fno-asynchronous-unwind-tables -Wno-address 
-flto -DUSING_LTO -Os -mno-mmx -mno-sse -D DISABLE_NEW_DEPRECATED_INTERFACES 
-Wl,--defsym=PECOFF_HEADER_SIZE=0x228 
-Wl,--script=/home/bcran/workspace/edk2/BaseTools/Scripts/GccBase.lds -Wno-error
Building ... /home/bcran/workspace/edk2/PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf 
[X64]
make: Nothing to be done for 'tbuild'.
Building ... 
/home/bcran/workspace/edk2/MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
 [X64]
Building ... 
/home/bcran/workspace/edk2/MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
 [X64]
make: Nothing to be done for 'tbuild'.
make: Nothing to be done for 'tbuild'.
make: Nothing to be done for 'tbuild'.
Building ... 
/home/bcran/workspace/edk2/MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
 [X64]
/tmp//ccVNNewx.ltrans0.ltrans.o: In function `GetMemEncryptionAddressMask':
Building ... 
/home/bcran/workspace/edk2/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
 [X64]
/home/bcran/workspace/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.c:57:
 undefined reference to `AsmCpuid'
/tmp//ccVNNewx.ltrans0.ltrans.o: In function 
`WriteBackInvalidateDataCacheRange':
/home/bcran/workspace/edk2/MdePkg/Library/BaseCacheMaintenanceLib/X86Cache.c:141:
 undefined reference to `AsmCpuid'
/home/bcran/workspace/edk2/MdePkg/Library/BaseCacheMaintenanceLib/X86Cache.c:143:
 undefined reference to `AsmWbinvd'
/home/bcran/workspace/edk2/MdePkg/Library/BaseCacheMaintenanceLib/X86Cache.c:160:
 undefined reference to `AsmFlushCacheLine'
make: Nothing to be done for 'tbuild'.
/tmp//ccVNNewx.ltrans0.ltrans.o: In function `IsReadOnlyPageWriteProtected':
make: Nothing to be done for 'tbuild'.
/home/bcran/workspace/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.c:521:
 undefined reference to `AsmReadCr0'
/tmp//ccVNNewx.ltrans0.ltrans.o: In function `DisableReadOnlyPageWriteProtect':
/home/bcran/workspace/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.c:534:
 undefined reference to `AsmReadCr0'
Building ... 
/home/bcran/workspace/edk2/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf 
[X64]
/home/bcran/workspace/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.c:534:
 undefined reference to `AsmWriteCr0'
/tmp//ccVNNewx.ltrans0.ltrans.o: In function `SetMemoryEncDec':
/home/bcran/workspace/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.c:655:
 undefined reference to `AsmReadCr3'
/tmp//ccVNNewx.ltrans0.ltrans.o: In function `EnableReadOnlyPageWriteProtect':
/home/bcran/workspace/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.c:545:
 undefined reference to `AsmReadCr0'
/home/bcran/workspace/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.c:545:
 undefined reference to `AsmWriteCr0'
/tmp//ccVNNewx.ltrans0.ltrans.o: In function `InternalMemEncryptSevIsEnabled':
/home/bcran/workspace/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c:52:
 undefined reference to `AsmCpuid'
/home/bcran/workspace/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c:57:
 undefined reference to `AsmCpuid'
/tmp//ccVNNewx.ltrans0.ltrans.o: In function `AsmReadMsr32':
/home/bcran/workspace/edk2/MdePkg/Library/BaseLib/X86Msr.c:39: undefined 
reference to `AsmReadMsr64'
collect2: error: ld returned 1 exit status
make: *** [GNUmakefile:397: 
/home/bcran/workspace/edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/AmdSevDxe/AmdSevDxe/DEBUG/AmdSevDxe.dll]
 Error 1


— 
Rebecca
___

Re: [edk2] GitLab results from my POV [was: Research Request]

[Rebecca Cran via edk2-devel]

On Wednesday, 12 December 2018 06:20:24 MST Laszlo Ersek wrote:

> After having looked at GitHub, Phabricator, and GitLab, my personal
> preference remains the mailing list. A *distant* second is GitHub.
> (GitHub is "almost there", but its emails significantly lack context.)
> And Phabricator and GitLab just don't cut it for me; Phabricator doesn't
> map to multi-patch series to begin with, and GitLab is too resource
> hungry, and it did a terrible job (for me anyway) preserving history.
> 
> Can someone setup Gerrit for a test drive?...

Hopefully we'll be able to pick this up again in the new year.

-- 
Rebecca


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

Re: [edk2] my Phabricator findings [was: Research Request]

[Rebecca Cran via edk2-devel]

On December 7, 2018 at 5:00:55 AM, Laszlo Ersek 
(ler...@redhat.com(mailto:ler...@redhat.com)) wrote:

> To be honest, I'm stumped how Mozilla could adopt (according to the
> article linked at the top) "Phabricator as the primary code review
> system for Firefox".  

They previously used Review Board (https://www.reviewboard.org/), which 
similarly uses a tool ‘rbt’ (RB Tools) to post/manage reviews, so it seems 
their processes are set up to work in such a way.


I can understand that our workflow is different and not a good fit for the 
model Phabricator uses.






Rebecca

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

Re: [edk2] [edk2-announce] Research Request

[Rebecca Cran via edk2-devel]

On Thursday, 6 December 2018 07:13:24 MST Laszlo Ersek wrote:

> They don't contain any code (diff hunks). I hope I can change that in my
> email preferences (I haven't gotten around checking those yet). 

I've updated the Mail settings to inline diffs up to 200 lines, and also 
attach diffs to the emails. It sends git-style diffs - it can also be 
configured to send unified diffs instead.

>   nore...@phabricator.example.com
> 
> That doesn't look right even for this testing; can you please update the
> config? I believe the emails should come from a sender @
> code.bluestop.org. Is that correct?

I've configured it to send from p...@bluestop.org .

I'm sure there are other things that aren't properly configured (for example, 
I've not set it up so you can reply to emails and have those replies be added 
to the review), but hopefully it gives you an idea of what it can do.

-- 
Rebecca


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

Re: [edk2] [edk2-announce] Research Request

[Rebecca Cran via edk2-devel]

On December 6, 2018 at 7:13:24 AM, Laszlo Ersek 
(ler...@redhat.com(mailto:ler...@redhat.com)) wrote:

> I've just noticed that I got the following emails:
>  
> [Differential] [Request] [+ ] D1: Update URL of OVMF page
> [Differential] [Updated] D1: Update URL of OVMF page
>  
> They don't contain any code (diff hunks). I hope I can change that in my
> email preferences (I haven't gotten around checking those yet). However,
> one bit that I doubt I'll be able to update myself, is the sender for
> these emails:
>  
> nore...@phabricator.example.com  

Yeah, sorry - I’ll fix the configuration this evening to send diffs and allow 
replies to emails (and update the domain name).






Rebecca

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

Re: [edk2] [edk2-announce] Research Request

[Rebecca Cran via edk2-devel]

On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:

> Can you assist with the following please?

Also, a couple of notes:

Go to https://code.bluestop.org/settings/user/lersek/  to configure preferences 
related to emails (http/plain), diffs etc.

Install the arcanist package on your system or follow the instructions at 
https://secure.phabricator.com/book/phabricator/article/arcanist/#installing-arcanist
 to get a copy (the 'arc' command). It's the command-line interface to 
Phabricator.

https://code.bluestop.org/differential/ is your main code reviews page.
https://code.bluestop.org/diffusion/ is a repo browser.
https://code.bluestop.org/maniphest/ (if we were to use it) is for tasks and 
bugs.

-- 
Rebecca


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

Re: [edk2] [edk2-announce] Research Request

[Rebecca Cran via edk2-devel]

On Wednesday, 5 December 2018 05:55:41 MST Laszlo Ersek wrote:

> (1) Pls. explain to me how I can create an edk2 clone at
> . :)

You don't. In a production system it may be possible to clone from either 
GitHub or code.bluestop.org (which mirrors github), but the clone URL given 
when you click "Clone" on https://code.bluestop.org/diffusion/EDK/ doesn't 
work (since I've not configured it).
 
> (2) Please create a throw-away account for yourself.

Done (though not throw-away).
 
> (3) Submit a pullreq against (1), with a topic branch that has two
> commits, and simple text file modifications.

https://code.bluestop.org/D1
Since Phabricator doesn't care about topic branches (just patches), I created 
a diff to README.

-- 
Rebecca




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

Re: [edk2] [edk2-announce] Research Request

[Rebecca Cran via edk2-devel]

On Monday, 3 December 2018 02:29:28 MST Laszlo Ersek wrote:
> On 11/29/18 22:20, Rebecca Cran wrote:
> > Would you be interested in going through this process with Phabricator,
> > too?
> Sure! Just tell me where to create an account.

Go to https://code.bluestop.org/auth/register/ to create a new account on the 
system, or https://code.bluestop.org/auth/ to login using an existing GitHub 
account.

- -
Rebecca


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

Re: [edk2] [edk2-announce] Research Request

[Rebecca Cran via edk2-devel]

Would you be interested in going through this process with Phabricator, too? 

Rebecca


On November 29, 2018 at 2:48:18 AM, Laszlo Ersek 
(ler...@redhat.com(mailto:ler...@redhat.com)) wrote:

> On 11/29/18 02:07, Jeremiah Cox wrote:
> > I did a further experiment for you:
> > https://github.com/lersek/edk2/pull/2
> 
> Thanks!
> 
> > I cannot rebase away my history from PRs...
> > Hopefully you have a nice email trail too.
> 
> The emails are coming in nice, but I'm not universally pleased with the
> contents. I listed some issues regarding that in
> , but I guess I should write them
> up sometime more readably, at the end of this experiment.
> 
> Thanks!
> Laszlo
> 
> > -Original Message-
> > From: Laszlo Ersek 
> > Sent: Wednesday, November 28, 2018 2:02 PM
> > To: Jeremiah Cox ; Brian J. Johnson 
> > ; stephano 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [edk2-announce] Research Request
> > 
> > On 11/28/18 19:31, Jeremiah Cox wrote:
> > > Test PR submitted
> > 
> > Thanks!
> > Laszlo
> > 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-announce] Research Request

[Rebecca Cran via edk2-devel]

On Wednesday, 28 November 2018 11:19:33 MST Jeremiah Cox wrote:
> There is a question of how the below is automated such that when there is a
> security advisory, a Phabricator instance is patched in a timely fashion. 
> Perhaps there is a mailing list that would announce these and that could
> trigger an auto-update script.

I'm not sure most people would like installations to be automatically updated 
without at least reviewing what such a script was going to do.

I agree someone would need to monitor for security advisories though, and 
schedule maintenance windows to update it.

-- 
Rebecca


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

Re: [edk2] [edk2-announce] Research Request

[Rebecca Cran via edk2-devel]

On Tuesday, 27 November 2018 14:16:18 MST Jeremiah Cox via edk2-devel wrote:

> Do we have data on what it takes to deploy and operate Phabricator with
> Harbormaster or Jenkins?  The up front development/deployment
> activity/costs and then also the ongoing patching/servicing/maintenance
> costs?  Is Intel planning to provide this?

I haven't integrated Harbormaster or Jenkins, but for just Phabricator the 
patching/servicing has ben really simple for the year+ I've been running it. 
I'd not consider it 'production' since I'm the only person using it and I'm 
running from Git master, not a stable branch - but maintenance has been as 
simple as the following (which could of course be put in a script to reduce 
the number of steps!):

# Stop the Phabricator daemon
./bin/phd stop
# Update Phabricator
git pull
# Update libphputil
cd ../libphputil && git pull
# Upgrade arcanist (commandline interface)
cd ../arcanist && git pull
# Upgrade database schema
./bin/storage upgrade
# Start Phabricator daemon
./bin/phd start
# Reload web server
service nginx restart
service php-fpm restart

The "storage upgrade" command goes through the database looking for any 
inconsistencies - missing keys, wrong data types etc., and offers to fix them.

-- 
Rebecca


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

Re: [edk2] Newbie: Getting Ovmf built

[Rebecca Cran via edk2-devel]

On Friday, 23 November 2018 17:40:15 MST stephano wrote:

> We have a set of simple instructions for folks building on standard
> Linux distros. Please have a look at this page:
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions
> 
> Note: Be sure the TARGET_ARCH is set correctly. (E.g. TARGET_ARCH = x64)

If you just want to build OVMF, there's a simpler way. After cloning, and 
assuming you're running bash, just:

cd edk2
. ./edksetup.sh
./OvmfPkg/build.sh -a X64 -t GCC5 -b RELEASE

If the build succeeds you'll end up with Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd 
which is the 'BIOS' image to pass to Qemu, e.g.:

qemu-system-x86_64 -m 4g -drive if=pflash,format=raw,readonly,file=Build/
OvmfX64/RELEASE_GCC5/FV/OVMF.fd \
-nodefaults \
-drive format=raw,file=/hda.img -monitor stdio \
-vga std -sdl -drive format=raw,file=Install.iso

-- 
Rebecca


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

Re: [edk2] [edk2-announce][RFC] Collaboration Software

[Rebecca Cran via edk2-devel]

On Friday, 16 November 2018 19:42:51 MST Sean Brogan via edk2-devel wrote:
> Mike,
> 
> I like the github teams option for discussion as it is just there, free, and
> easy.  It integrates nicely with all other parts of github.  Notifications
> are supported for those that want email.   Is there any reason this path
> doesn't get used now as a test since tianocore is already in github?  

I do wonder why there aren't more _big_ open source projects using Github if 
it _is_ there, free and easy to use. I'm aware lots and lots use it for 
hosting their repositories, but I'm not aware of many that use it for code 
reviews, discussions etc.

I found that CoreBoot uses Gerrit: https://review.coreboot.org/q/status:open

GNOME evaluated Phabricator and GitLab (but not GitHub, because "GitHub is not 
Free Software, of couse, which makes it unacceptable to many in the GNOME 
community") - https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure .
They decided to go with GitLab:
https://mail.gnome.org/archives/desktop-devel-list/2017-May/msg00051.html

One comment from a user on the GNOME evaluation (https://wiki.gnome.org/
Initiatives/DevelopmentInfrastructure/Comments) said:

"We tried migrating libnice to phabricator.freedesktop.org and it was a bit of 
a disaster as the "drive-by" contribution process is horrible with 
Phabricator, requiring to either download a tool or copy-paste patches into a 
webpage. Upstream Phabricator is also very hostile to the github style of 
reviews (where you can review small patches, not everything squashed into one 
SVN style). Even Bugzilla with Splinter is nicer for new contributors.. So 
let's go with GitLab. That said, all of Collabora's Phabricator tools are 
already public. ? OlivieCrete"

-- 
Rebecca


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

Re: [edk2] [edk2-announce][RFC] Collaboration Software

[Rebecca Cran via edk2-devel]

On November 16, 2018 at 7:42:51 PM, Sean Brogan via edk2-devel 
(edk2-devel@lists.01.org(mailto:edk2-devel@lists.01.org)) wrote:

> I really can't get behind the Phabricator tool suite as it just has too many 
> downsides (self-hosted or pay, lack of integrations, lack of support and 
> limited searchability, poor ci integration, etc).  
>  






At least with Phabricator you don’t have to pay to self-host it. And look at 
all the features you don’t get with Github unless you pay them:


https://github.com/pricing






Rebecca


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

Re: [edk2] [edk2-announce][RFC] Collaboration Software

[Rebecca Cran via edk2-devel]

On Friday, 16 November 2018 14:42:44 MST stephano wrote:

> This is a great suggestion, thanks! Two questions:

> 1. Does it allow you to export your conversations in some way?

Conversations can followed via email, so that's one way of 'exporting' them. 
But otherwise, I suspect you'd need to either query the database directly or 
use "./bin/storage dump":

DUMP WORKFLOW

dump [options]
Dump all data in storage to stdout.

  --compress
  With --output, write a compressed file to disk instead of a
  plaintext file.

  --for-replica
  Add --master-data to the mysqldump command, generating a CHANGE
  MASTER statement in the output.

  --no-indexes
  Do not dump data in rebuildable index tables. This means backups
  are smaller and faster, but you will need to manually rebuild
  indexes after performing a restore.

  --output file
  Write output directly to disk. This handles errors better than
  using pipes. Use with --compress to gzip the output.

  --overwrite
  With --output, overwrite the output file if it already exists.


> 2. Is there a "file sharing" option if we wanted to, for example, share
> a JPG or ODF file?

Yes: Phabricator has a general file storage service, and files can be uploaded 
via that and shared in Conpherence.

-- 
Rebecca


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

Re: [edk2] [edk2-announce][RFC] Collaboration Software

[Rebecca Cran via edk2-devel]

On Friday, 16 November 2018 12:13:37 MST stephano wrote:
> The only reason I didn't include Slack is that it will only log so much
> information before things start falling off into the ether.
> 
> Does anyone in the community currently use Slack and know of an easy way
> of archiving conversations publicly?

I'm in several Slack teams: it seems to be the go-to solution for persistent 
chat nowadays. None of those pay (i.e. they're on the free tier), so are 
subject to its 10,000 message history limit.

Another option may be Conpherence, which comes with Phabricator: https://
www.phacility.com/phabricator/conpherence/ :

"Conpherence is a group messaging application integrated into Phabricator. 
Message one-on-one or with a group of people, name your room, and keep a 
history of everything in one place. Reply via email, on the web, or on your 
mobile device.

Conpherence supports Remarkup that makes it easy to link to Maniphest tasks 
and code reviews, share code snippets, format tables, and share memes. 
Conpherence even has a persistent chat sidebar built-in, so you don't need to 
keep another tab open."

-- 
Rebecca


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

[edk2] Example of email Phabricator can be configured to send on svn commit

[Rebecca Cran]

Since we've been discussing Phabricator for code reviews, I thought 
people might be interested in an example of the emails it can be 
configured to send. This one's from the FreeBSD project and its instance 
at https://reviews.freebsd.org when I committed a changeset to the SVN repo.


This revision was automatically updated to reflect the committed changes.
Closed by commit rS339796: Simplify the EFI delay() function by calling 
BS-Stall() (authored by bcran, committed by ).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D16753?vs=46794=49670#toc

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D16753?vs=46794=49670

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D16753/new/

REVISION DETAIL
  https://reviews.freebsd.org/D16753

AFFECTED FILES
  head/stand/efi/libefi/delay.c

CHANGE DETAILS

diff --git a/head/stand/efi/libefi/delay.c b/head/stand/efi/libefi/delay.c
--- a/head/stand/efi/libefi/delay.c
+++ b/head/stand/efi/libefi/delay.c
@@ -33,15 +33,5 @@
 void
 delay(int usecs)
 {
-   static EFI_EVENT ev = 0;
-   UINTN junk;
-
-   if (!ev) {
-   if (BS->CreateEvent(EVT_TIMER, TPL_APPLICATION, 0, 0, )
-   != EFI_SUCCESS)
-   return;
-   }
-
-   BS->SetTimer(ev, TimerRelative, usecs * 10);
-   BS->WaitForEvent(1, , );
+   BS->Stall(usecs);
 }



EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: bcran, imp, kevans, manu, eadler


D16753.49670.patch

diff --git a/head/stand/efi/libefi/delay.c b/head/stand/efi/libefi/delay.c
--- a/head/stand/efi/libefi/delay.c
+++ b/head/stand/efi/libefi/delay.c
@@ -33,15 +33,5 @@
 void
 delay(int usecs)
 {
-   static EFI_EVENT ev = 0;
-   UINTN junk;
-
-   if (!ev) {
-   if (BS->CreateEvent(EVT_TIMER, TPL_APPLICATION, 0, 0, )
-   != EFI_SUCCESS)
-   return;
-   }
-
-   BS->SetTimer(ev, TimerRelative, usecs * 10);
-   BS->WaitForEvent(1, , );
+   BS->Stall(usecs);
 }

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

Re: [edk2] Event Invitation: TianoCore Community Meeting - NAMO / EMEA

[Rebecca Cran]

I don't see any information about time/place/etc. - should there be an 
attachment?


On 10/5/18 1:39 PM, stephano wrote:

stephano  has invited you to TianoCore 
Community Meeting - NAMO / EMEA

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

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

Re: [edk2] [PATCH] Fix a couple of build errors in BaseTools when using gcc 8

[Rebecca Cran]

On 05/27/18 21:28, Rebecca Cran wrote:
> ---
>  BaseTools/Source/C/GenVtf/GenVtf.c  | 2 +-
>  BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Source/C/GenVtf/GenVtf.c 
> b/BaseTools/Source/C/GenVtf/GenVtf.c
> index 6f66ddc84..4d87e1c8c 100644
> --- a/BaseTools/Source/C/GenVtf/GenVtf.c
> +++ b/BaseTools/Source/C/GenVtf/GenVtf.c
> @@ -1470,7 +1470,7 @@ Returns:
>//
>FitStartPtr = (FIT_TABLE *) RelativeAddress;
>  
> -  strncpy ((CHAR8 *) >CompAddress, FIT_SIGNATURE, 8);  // 
> "_FIT_   "
> +  memcpy(>CompAddress, FIT_SIGNATURE, 8); // "_FIT_   "
>assert (((VtfInfo->CompSize & 0x00FF) % 16) == 0);
>FitStartPtr->CompSize = (VtfInfo->CompSize & 0x00FF) / 16;
>FitStartPtr->CompVersion  = MAKE_VERSION (VtfInfo->MajorVer, 
> VtfInfo->MinorVer);
> diff --git a/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp 
> b/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
> index f73b70d79..73a318724 100644
> --- a/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
> +++ b/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
> @@ -3284,7 +3284,7 @@ CVfrStringDB::GetVarStoreNameFormStringId (
>UINT8   BlockType;
>EFI_HII_STRING_PACKAGE_HDR *PkgHeader;
>
> -  if (mStringFileName == '\0' ) {
> +  if (*mStringFileName == '\0' ) {
>  return NULL;
>}
>  
> 

The change from strncpy to memcpy is because from the length argument it
appears that the contents of "CompAddress" shouldn't be NUL-terminated.

The change to the comparison is because mStringFileName is a pointer,
and comparing it against '\0' doesn't make sense. It seems the author
meant for the first character to be compared against NUL.

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

[edk2] [PATCH] Fix a couple of build errors in BaseTools when using gcc 8

[Rebecca Cran]

---
 BaseTools/Source/C/GenVtf/GenVtf.c  | 2 +-
 BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/C/GenVtf/GenVtf.c 
b/BaseTools/Source/C/GenVtf/GenVtf.c
index 6f66ddc84..4d87e1c8c 100644
--- a/BaseTools/Source/C/GenVtf/GenVtf.c
+++ b/BaseTools/Source/C/GenVtf/GenVtf.c
@@ -1470,7 +1470,7 @@ Returns:
   //
   FitStartPtr = (FIT_TABLE *) RelativeAddress;
 
-  strncpy ((CHAR8 *) >CompAddress, FIT_SIGNATURE, 8);  // "_FIT_  
 "
+  memcpy(>CompAddress, FIT_SIGNATURE, 8); // "_FIT_   "
   assert (((VtfInfo->CompSize & 0x00FF) % 16) == 0);
   FitStartPtr->CompSize = (VtfInfo->CompSize & 0x00FF) / 16;
   FitStartPtr->CompVersion  = MAKE_VERSION (VtfInfo->MajorVer, 
VtfInfo->MinorVer);
diff --git a/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp 
b/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
index f73b70d79..73a318724 100644
--- a/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
+++ b/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
@@ -3284,7 +3284,7 @@ CVfrStringDB::GetVarStoreNameFormStringId (
   UINT8   BlockType;
   EFI_HII_STRING_PACKAGE_HDR *PkgHeader;
   
-  if (mStringFileName == '\0' ) {
+  if (*mStringFileName == '\0' ) {
 return NULL;
   }
 
-- 
2.17.0

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

Re: [edk2] Ram initialization sequence in edk2

[Rebecca Cran]

On 05/17/2018 06:10 AM, Laszlo Ersek wrote:


The memory controller (or other silicon) initialization code is usually
one of the most proprietary parts of any platform firmware. It's pretty
unlikely you can get the source for it from anyone else than the
platform manufacturer, and that's assuming they're willing to let you
see it at all, even for $$$ and under strict NDA.


Agreed. Just to add that you can see a real-world example of memory 
controller initialization code - for the Quark (used in the discontinued 
Intel Galileo development boards) at 
https://github.com/tianocore/edk2/tree/master/QuarkSocPkg/QuarkNorthCluster/MemoryInit/Pei 
.


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

Re: [edk2] Trying to build OVMF fails

[Rebecca Cran]

I've had to update the toolchain definitions in edk2\Conf in the past to 
point WINSDK to a newer version, since I've been using VS2015 for a few 
years now.


The error about not finding "C:\Program" is from the build tool not 
being able to find rc.exe, likely because you don't have the Windows SDK 
version 8.0 installed.



--
Rebecca


On 5/10/2018 9:06 AM, Gao, Liming wrote:

VS build requires to install WINSDK. VS2013 requires WINSDK8. This path 
c:\Program Files (x86)\Windows Kits\8.0\bin\x64\rc.exe is from the installed 
WINSDK8.
When you installs visual studio, you can select winsdk and install it together 
VS compiler.


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Thursday, May 10, 2018 10:43 PM
To: apia...@aol.com
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Trying to build OVMF fails

On 05/10/18 15:37, apia...@aol.com wrote:

I am having a problem building OVMF to use as firmware for QEMU to test EFI 
binaries. I can only build the X64 arch of OVMF in linux.

In windows both IA32, IA32/X64, and X64 all fail with some variation of this 
error:





 "C:\Program Files (x86)\Microsoft Visual Studio 
12.0\Vc\bin\x86_amd64\cl.exe"

/Fod:\development\edk2\Build\OvmfX64\RELEASE_VS2013x86\X64\MdeModulePkg\Bus\Pci\EhciDxe\EhciDxe\OUTPUT\.\EhciUrb.obj
/nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- 
/GR- /GF /Gw /D MDEPKG_NDEBUG /D
DISABLE_NEW_DEPRECATED_INTERFACES 
/Id:\development\edk2\MdeModulePkg\Bus\Pci\EhciDxe
/Id:\development\edk2\Build\OvmfX64\RELEASE_VS2013x86\X64\MdeModulePkg\Bus\Pci\EhciDxe\EhciDxe\DEBUG
/Id:\development\edk2\MdePkg  /Id:\development\edk2\MdePkg\Include  
/Id:\development\edk2\MdePkg\Include\X64
/Id:\development\edk2\MdeModulePkg  /Id:\development\edk2\MdeModulePkg\Include
d:\development\edk2\MdeModulePkg\Bus\Pci\EhciDxe\EhciUrb.c

'c:\Program' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: '"c:\Program Files (x86)\Windows 
Kits\8.0\bin\x64\rc.exe' : return code '0x1'
Stop.

Sorry, I can't comment on the VS toolchains (I don't use them).


And in linux IA32 and IA32/X64 fail with some varation of this error:



"GenFw" -e DXE_DRIVER -o

/home/development/Desktop/edk2/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTole
rantWriteDxe/DEBUG/FaultTolerantWriteDxe.efi
/home/development/Desktop/edk2/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTole
rantWriteDxe/DEBUG/FaultTolerantWriteDxe.dll

GenFw: ERROR 3000: Invalid


/home/development/Desktop/edk2/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTole
rantWriteDxe/DEBUG/FaultTolerantWriteDxe.dll unsupported ELF EM_386 relocation 
0xa.

GenFw: ERROR 3000: Invalid


/home/development/Desktop/edk2/Build/OvmfIa32/RELEASE_GCC5/IA32/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTole
rantWriteDxe/DEBUG/FaultTolerantWriteDxe.dll unsupported ELF EM_386 relocation 
0x9.

Interesting; what gcc version are you using with the GCC5 toolchain?
I've just built OVMF like this:

$ build \
   -a IA32 \
   -p OvmfPkg/OvmfPkgIa32.dsc \
   -D SMM_REQUIRE \
   -D SECURE_BOOT_ENABLE \
   -t GCC5 \
   -n 4 \
   -b RELEASE \
   -D HTTP_BOOT_ENABLE \
   --cmd-len=65536 \
   --hash

with an up-to-date Fedora 28 install:
- gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)
- binutils-2.29.1-23.fc28.x86_64


How can I get the IA32 build working? Also I see ARM and AARCH64 OVMF images in 
packages, how are these being built? I get that

the architectures are unsupported.

Do you mean that "distro packages are unsupported by upstream edk2"?
Edk2 does support ARM and AARCH64.

It is true that the OvmfPkg DSC files target only IA32, IA32X64, and
X64, but the ArmVirtPkg DSC files target ARM and AARCH64 QEMU and Xen
virtual machines. You can build ArmVirtPkg platforms with
cross-compilers from x86_64, or natively on AARCH64 at the least (I've
never tried native building on ARM).

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

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


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

Re: [edk2] Incorrect Author on patch

[Rebecca Cran]

On 5/2/2018 7:40 AM, Laszlo Ersek wrote:


On 05/02/18 14:46, Evan Lloyd wrote:

  I can well understand why it would be useful to use Gerrit as a means
  of reviewing a patch - actually a brilliant idea,

(actually, *not* a brilliant idea, but that's just my opinion :) )


*Please* not Gerrit. If we're going to use a code review system, please 
let us choose Phabricator. It has a much nicer user interface.
You can see an example of the review requests it creates at 
https://reviews.freebsd.org/differential/ .


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

Re: [edk2] gdb reload-uefi missing EFI_SYSTEM_TABLE_POINTER [was: Source code debugging of OVMF]

[Rebecca Cran]

On 04/20/18 10:38, Johannes Swoboda wrote:
> Hello again,
> 
> Thank you again for taking the time to help me with this.
> 
> On 2018-04-20 17:58, Palmer, Thomas wrote:
>> Also, did you start qemu with the "-s" option before you started gdb?
> 
> Unfortunately, I start qemu with -s -S; then, I attach gdb. I know the
> attaching works because I gdb accepts the continue command which
> instructs qemu to begin execution of the virtual machine.
> The source [...]/gdb_uefi.py command seems to work find, but reload-efi
> -o [...]/DEBUG/GdbSyms.dll throws the error "No type named
> EFI_SYSTEM_TABLE_POINTER".
...
> Do you have any other suggestions?

I'm not sure things have loaded to the point necessary by then. I'd
suggest putting a call to CpuDeadLoop() someplace maybe near where you
want to start debugging. Then once attached to dbg, set the `Index`
variable to 1 to continue.

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

Re: [edk2] Source code debugging of OVMF

[Rebecca Cran]

On 04/16/18 12:25, Rebecca Cran wrote:
> On 04/16/18 10:13, Laszlo Ersek wrote:
> 
>> Here's another thread that you might find useful:
>>
>> http://edk2-devel.narkive.com/6BRVus92/qestion-about-how-to-debug-ovmf-on-qemu
> 
> I should get my Phabricator wiki running again, which has a
> nicely-formatted version of that - I haven't set it up again after
> moving systems.
> 

https://code.bluestop.org/w/tianocore/debugging-with-gdb/ is now working
again.

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

Re: [edk2] Source code debugging of OVMF

[Rebecca Cran]

On 04/16/18 10:13, Laszlo Ersek wrote:

> Here's another thread that you might find useful:
> 
> http://edk2-devel.narkive.com/6BRVus92/qestion-about-how-to-debug-ovmf-on-qemu

I should get my Phabricator wiki running again, which has a
nicely-formatted version of that - I haven't set it up again after
moving systems.

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

[edk2] How-to-run-OVMF wiki page links to outdated sf files area

[Rebecca Cran]

There's an outdated link on
https://github.com/tianocore/tianocore.github.io/wiki/How-to-run-OVMF :
the "OVMF downloads area" link points to
http://sourceforge.net/projects/edk2/files/OVMF, which was last updated
in 2014.

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

Re: [edk2] vUDK2018: git clone

[Rebecca Cran]

On 04/07/2018 04:10 PM, Duran, Leo wrote:

Regarding the "git clone" instructions listed on step "2.iii.a", here:
https://github.com/tianocore/tianocore.github.io/wiki/UDK2018-How-to-Build

iii. OR Checkout the vUDK2018 Tag from GitHub with the following "git" command

a.   run git clone https://github.com/tianocore/edk2.git vUDK2018

Instead of checking out the vUDK2018 Tag, that simply clones the tip of the 
master branch to a vUDK2018 directory.

So, I'd like to suggest the following changes:
iii. OR Checkout the vUDK2018 Tag from GitHub with the following "git" command

a.   Run: git clone https://github.com/tianocore/edk2.git vUDK2018

b.  Go to the vUDK2018 directory, and from there run: git checkout 
tags/vUDK2018 -b vUDK2018

... And so on, from there.


It may be better to just add the "-b" parameter, and specify the branch 
name instead of the tag - which is UDK2018, instead of vUDK2018. e.g.:


git clone https://github.com/tianocore/edk2.git -b UDK2018


An example on my machine:

bcran@muon:~/workspace % git clone https://github.com/tianocore/edk2.git 
-b UDK2018


Cloning into 'edk2'...

remote: Counting objects: 296007, done.

remote: Compressing objects: 100% (106/106), done.

remote: Total 296007 (delta 119), reused 121 (delta 89), pack-reused 295812

Receiving objects: 100% (296007/296007), 268.82 MiB | 10.08 MiB/s, done.

Resolving deltas: 100% (208848/208848), done.

Checking out files: 100% (15552/15552), done.

bcran@muon:~/workspace % cd edk2

bcran@muon:~/workspace/edk2 % git branch

* UDK2018


If you specify the tag, vUDK2018 when cloning, you're put into the 
'detached HEAD' state instead.



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

Re: [edk2] [RFC v1 00/15] *** Proposal for StandaloneMmPkg ***

[Rebecca Cran]

Could there be any confusion between 'MM' meaning Management Mode and 
Memory Management?



--
Rebecca


On 11/17/2017 4:07 PM, Supreeth Venkatesh wrote:

***
PI Specification v1.5  "Volume 4: Management Mode Core Interface"
introduces the concept of MM Standalone Mode. Initialization of this mode
can be done during the SEC phase (Section 1.5.2).
On ARMv8-A systems, ARM Trusted Firmware is responsible for launching
the normal world firmware e.g. UEFI.

The Standalone MM environment is instantiated in Secure EL0 as a separate
firmware volume. It executes as BL32 Image under control of ARM TF
which is instantiated in EL3. Both components execute in the AArch64 execution 
state.
This patchset will build upon the StandaloneSmmPkg module originally
contributed by Intel.

This package can be used in conjunction with ARM Trusted Firmware
to recreate a simple MM secure environment that demonstrates communication
between two UEFI images where one is executing in the normal world and the 
other is
executing in the secure world.

The normal world image includes:
MM Communication DXE runtime driver that implements the protocol for 
communication
with the MM environment in the secure world.

The secure world image includes:
The MM Standalone framework.

This RFC patchset includes the proposed organization/structure and
has architecture agnostic core changes only as a first pass.
Once the organization/structure have been agreed upon, patchset for
supporting libraries and AARCH64 implementation will be sent.

Steps to build MM Standalone images
In user preferred "work" directory, execute the following shell commands

git clone https://github.com/tianocore/edk2.git
git checkout master

git clone https://github.com/tianocore/edk2-platforms.git
git checkout master

mkdir arm-tf
cd arm-tf
git clone https://github.com/ARM-software/arm-trusted-firmware.git .
git checkout master
cd ..

git clone https://git.linaro.org/uefi/uefi-tools.git .
git checkout master

The following will build the MM Standalone image which runs in secure world.
./uefi-tools/edk2-build.sh -b DEBUG fvp_mm_standalone

The follwing will build the normal world UEFI image, ARM Trusted Firmware and
a Firmware Image Package (FIP) that includes both the UEFI images.
./uefi-tools/edk2-build.sh -a ./arm-tf -b DEBUG fvp_mm_normal

Boot Loader Stage 1 (BL1) binary and combined arm-tf/uefi firmware image 
package (fip) binary will be generated at:

Build Output
Build/ArmVExpress-FVP-AArch64-MM-Normal/DEBUG_GCC5/FV/bl1.bin
Build/ArmVExpress-FVP-AArch64-MM-Normal/DEBUG_GCC5/FV/fip.bin

Steps to run MM Standalone image
1. Download the ARMv8 Architecture FVP from
  https://silver.arm.com/download/download.tm?pv=3744408=1424570
  For more information, please refer
  https://developer.arm.com/products/system-design/fixed-virtual-platforms
2.  Install FVP into preferred "work" directory.
3.  Create a shell script "run_mm.sh" in the same folder where 
"FVP_Base_AEMv8A-AEMv8A" is present.
  Sample Shell script below:
 ./FVP_Base_AEMv8A-AEMv8A
 -C cache_state_modelled=0
 -C bp.secure_memory=1
 -C bp.tzc_400.diagnostics=1
 -C bp.pl011_uart0.untimed_fifos=0
 -C cluster1.NUM_CORES=4
 -C cluster0.NUM_CORES=4
 -C bp.pl011_uart0.out_file=uart0.output
 -C bp.pl011_uart1.out_file=uart1.output
 -C bp.pl011_uart2.out_file=uart2.output
 -C bp.pl011_uart3.out_file=uart3.output
 -C bp.secureflashloader.fname=""
 -C bp.flashloader0.fname=""
 -S -R
4. ./run_mm.sh
5. Output can be seen on FVP console.
6. The normal world will boot to the UEFI shell.

Sample Output

MM Standalone Output (FVP UART2)
SPM Version: Major=0x0, Minor=0x1
NumSpMemRegions - 0x6
SpMemBase   - 0xFF20
SpMemLimit  - 0x1
SpImageBase - 0xFF20
SpStackBase - 0xFF61
SpHeapBase  - 0xFF62
SpNsCommBufBase - 0xFF60
SpSharedBufBase - 0xFF50
SpImageSize - 0x30
SpPcpuStackSize - 0x2000
SpHeapSize  - 0x9E
SpNsCommBufSize - 0x1
SpPcpuSharedBufSize - 0x2
NumCpus - 0x8
CpuInfo - 0xFF500680
Mpidr   - 0x8000
LinearId- 0x0
Flags   - 0x1
Mpidr   - 0x8001
LinearId- 0x1
Flags   - 0x0
Mpidr   - 0x8002
LinearId- 0x2
Flags   - 0x0
Mpidr   - 0x8003
LinearId- 0x3
Flags   - 0x0
Mpidr   - 0x8100
LinearId- 0x4
Flags   - 0x0
Mpidr   - 0x8101
LinearId- 0x5
Flags   - 0x0
Mpidr   - 0x8102
LinearId- 0x6
Flags   - 0x0
Mpidr   - 0x8103
LinearId- 0x7
Flags   - 0x0
Found Standalone MM PE data - 0xFF201000
Found Standalone MM PE data - 0xFF201000
Standalone MM Core PE-COFF SectionHeaderOffset - 0xF60, NumberOfSections - 3
UpdateMmFoundationPeCoffPermissions: Section 0 of image at 0xFF201000 has 
0x6020 permissions
UpdateMmFoundationPeCoffPermissions: Section 0 of image at 

Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoardMax-UDK2017] Change GCC shell

[Rebecca Cran]

On 9/27/2017 3:09 AM, Guo, Mang wrote:


Change GCC shell from MinimumShell to UefiShell in ShellBinPkg.


Thanks. I've been wondering about this now that GCC correctly sets -Os 
in the build options to reduce the binary size to around the same as 
Visual C++.


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

[edk2] PI 1.6 vs. edk2 - EfiGcdMemoryTypePersistent (EFI_GCD_MEMORY_TYPE)

[Rebecca Cran]

I've noticed an inconsistency between the PI 1.6 specification and the 
edk2 implementation of EFI_GCD_MEMORY_TYPE: PI says it's 
EfiGcdMemoryTypePersistent while Pi/PiDxeCis.h has 
EfiGcdMemoryTypePersistentMemory.


Since the EfiGcdMemoryTypePersistent is mentioned several times in the 
spec I'm guessing the edk2 is wrong.



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

Re: [edk2] "practical" memory allocation limit?

[Rebecca Cran]

On 08/28/2017 10:23 AM, Andrew Fish wrote:

For X64 (x86-64) systems it is common for PEI to run in 32-bit mode with paging 
disabled. This means the DXE Core gets loaded under 4GB and and the HOBs and such are 
< 4GB. So having the initial memory map < 4GB helps with preventing 
fragmentation.


This is something I ran into with a driver I was working on: when being 
Load'd from a PCIe optrom only 4GB RAM could be seen; later, in the 
Start function, all 32GB or however much could be accessed.


Then there was still the problem of certain machines limiting 
AllocatePool calls to 4GB, which since our driver at times needed many 
times that amount required us to iterate over the memory map and call 
AllocatePages.


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

[edk2] OvmfPkg (PlatformPei?): supporting Qemu's nvdimm device

[Rebecca Cran]

I've been investigating adding support for Qemu's nvdimm devices to 
OVMF.  I was thinking such support would go into PlatformPei, but it 
looks like I can only read the ACPI NFIT in the DXE phase. So, should 
Qemu be changed to add non-volatile memory to the e820 table, or should 
such memory be added during the DXE phase instead?



--
Rebecca

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

Re: [edk2] Reconfiguring the PEI blob for the Overdrive1000 (AMD A1100)

[Rebecca Cran]

On Thu, 1 Jun 2017 07:29:05 +
Ard Biesheuvel  wrote:

> Which PEI binary are you referring to? There is the PEI core, and a
> collection of PEI modules (PEIMs) that do various platform related
> things, including PCIe link training (and believe me, looking at that
> code will make your eyes bleed), which is the only closed source PEIM
> IIRC.
> 
> Whether you can get access to the FDK is a question I cannot answer,
> but I don't think there are any people left at AMD working on the
> Seattle project.
> 
> Which tree are you building from?

I'm using the OpenPlatformPkg tree from
https://git.linaro.org/uefi/OpenPlatformPkg.git . 

The binary I was interested in is PreUefiFirmware.bin in
https://git.linaro.org/uefi/OpenPlatformPkg.git/tree/Platforms/AMD/Styx/Overdrive1000Board/Binary
 .

I should probably explain what problem I'm trying to solve. I'm working
on NVDIMM support, and have been starting to plan work around
making changes to the EDK2 to support the modules, starting with
reading the DDR4 SPD data.

However, the i2c access protocols etc. that I'd need appear to be
implemented in the PreUefiFirmware.bin binary and are currently not
exposed to UEFI drivers via the protocols from the PI spec.

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

[edk2] Reconfiguring the PEI blob for the Overdrive1000 (AMD A1100)

[Rebecca Cran]

Hi,

I recently got an ARM64 SoftIron Overdrive 1000 box which uses AMD's 
Opteron A1100, and while it's nice having most of the platform firmware 
be open source, the part I'm missing is the PEI, which is implemented in 
a binary blob. Apparently that is generated via a tool called the AMD 
Firmware Development Kit, but I can't find any reference to it outside 
of the edk2.



Is there any way a user outside of AMD can get the Firmware Development 
Kit, or somehow else reconfigure the PEI binary? I'm asking because some 
work I'm starting out on has changes for the PEI, and while I could use 
Qemu it would be nice to also develop on real hardware.



Thanks.

Rebecca

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

[edk2] OpenPlatformPkg: vendor string (edk2.sourceforge.net)

[Rebecca Cran]

I noticed that the OpenPlatformPkg in linaro and tianocore
(edk2-platforms devel-OpenPlatformPkg) git there's a "Vendor
String" of "edk2.sourceforge.net":

./Silicon/AMD/Styx/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c:134:
"edk2.sourceforge.net",  // Vendor String


Since we no longer use sourceforge, should it be updated - or is it too
late to change at this point?

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

[edk2] Warnings cross-building AARCH64 package with GCC 6.2.1 (-Wlto-type-mismatch)

[Rebecca Cran]

I suspect I should be trying to build AARCH64 stuff with something more
like gcc 4.8 instead of 6.2.1, but when I did build the
Overdrive1000Board package I saw lots of warnings complaining about the
implementation not matching the prototype (with
the warning being -Wlto-type-mismatch).  

I cross-compiled on an OpenSUSE x64 system with
aarch64-suse-linux-gcc-6, with the commandline:

build -a AARCH64 -t GCC5 -b RELEASE -p
OpenPlatformPkg/Platforms/AMD/Styx/Overdrive1000Board/Overdrive1000Board.dsc

ArmPlatformPkg is from
linaro git master, edk2 is tianocore git master

The warnings were all similar to:

/workspace/edk2/MdePkg/Include/Library/BaseMemoryLib.h:462:1:
warning: type of 'IsZeroGuid' does not match original declaration
[-Wlto-type-mismatch] IsZeroGuid ( ^
//workspace/edk2/MdePkg/Library/BaseMemoryLibOptDxe/Arm/MemLibGuid.c:158:1:
note: 'IsZeroGuid' was previously declared here IsZeroGuid (
 ^
/workspace/edk2/MdePkg/Library/BaseMemoryLibOptDxe/Arm/MemLibGuid.c:158:1:
note: code may be misoptimized unless -fno-strict-aliasing is used



Are these real problems, or just because gcc 6.2 and/or LTO aren't ready
for AARCH64 yet?


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

[edk2] Using i2c from UEFI driver or application

[Rebecca Cran]

I'm writing an application (it may also end up being a DXE driver) that 
needs to access the i2c bus. The issue I'm seeing is that the i2c/SMBus 
access protocols etc. seem to be from the PI spec, and my understanding 
is that drivers or applications aren't supposed to use PI-specific 
functionality.  Is my understanding correct, or is there some other way 
for drivers/applications to access i2c devices?


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

Re: [edk2] [platforms/devel-MinnowBoard3] Reformat ReadMe.MD with markdown (github) and simplify instructions

[Rebecca Cran]

On 2/26/2017 11:11 PM, Guo, Mang wrote:


Thanks Rebecca. I tried to apply your patch but failed with the below errors, 
could you update and send the patch again?


.git/rebase-apply/patch:16: trailing whitespace.
# INDEX


Those are because some lines in the old ReadMe.MD file had trailing 
whitespace. You should be able to avoid the errors by passing 
"--whitespace=nowarn" when running "git apply".


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

[edk2] [platforms/devel-MinnowBoard3] Reformat ReadMe.MD with markdown (github) and simplify instructions

[Rebecca Cran]

The formatting of ReadMe.MD on GitHub wasn't very nice, with steps
running into one another. This change reformats the text to use
GitHub Flavored Markdown.

It also simplifies a few of the steps, for example combining the
git clone and rename into a single command.

Cc: David Wei <david@intel.com>
Cc: Mang Guo <mang@intel.com>
Cc: Vincent Zimmer <vincent.zim...@intel.com>
Cc: Mike Wu <mike...@intel.com>
Cc: Shifeix A Lu <shifeix.a...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Rebecca Cran <rebe...@bluestop.org>
---
 ReadMe.MD | 163 ++
 1 file changed, 78 insertions(+), 85 deletions(-)

diff --git a/ReadMe.MD b/ReadMe.MD
index ec55d6569767..1e101e47714d 100644
--- a/ReadMe.MD
+++ b/ReadMe.MD
@@ -1,138 +1,131 @@
 
 This code base is designed for the MinnowBoard v3 platform using the Intel(R) 
Atom(tm) Processor E3900 Series.
 
-
-INDEX 
-
+# INDEX
+
 1.  HOW TO CREATE A FULL SOURCE TREE
 2.  HOW TO BUILD (WINDOWS ENVIRONMENT)
 3.  MAINTAINERS
-  
-
-1.   HOW TO CREATE A FULL SOURCE TREE 
-
-1) Create a new folder (directory) on the root of your local development 
machine
+
+## 1. HOW TO CREATE A FULL SOURCE TREE
+
+1. Create a new folder (directory) on the root of your local development 
machine
for use as your work space (this example uses "C:\MyWorkspace").

NOTE: Some code paths are very long, and placing the working directory too
  deep below the ROOT directory may cause the path to be longer than 
the 
  operating system or file system's maximum path length.
 
-2) Get MinnowBoard v3 branch from GitHub with the following command.
-   a. git clone https://github.com/tianocore/edk2-platforms.git -b 
devel-MinnowBoard3
+2. Get MinnowBoard v3 branch from GitHub with the following command.
+   * `git clone -b devel-MinnowBoard3 
https://github.com/tianocore/edk2-platforms.git`
   
Once the download completes, all EDK II packages and files will be found
under the "C:\MyWorkspace\edk2-platforms" directory.
 
-3) Get the BaseTools binary and copy them to BaseTools binary folder.
-   a. git clone https://github.com/tianocore/edk2-BaseTools-win32.git
-   b. Enter folder edk2-BaseTools-win32
-   b. git checkout f0c97b7716ce92f1fc657f87f29bcc9170e5eb1f
-   c. Rename folder name from "edk2-BaseTools-win32/" to "win32/" and copy
-  win32/ to the BaseTools Binary folder.
-  (C:\MyWorkspace\edk2-platforms\BaseTools\Bin\)
+3. Get the BaseTools binary and copy them to BaseTools binary folder.
+   1. Enter folder BaseTools\Bin
+   2. `git clone https://github.com/tianocore/edk2-BaseTools-win32.git Win32`
+   3. Enter folder Win32
+   4. `git checkout f0c97b7716ce92f1fc657f87f29bcc9170e5eb1f`
 
-4) Get the Intel(R) Firmware Support Package(Intel FSP)
-   a. Run "git clone -b ApolloLake https://github.com/IntelFsp/FSP.git; to 
download FSP.
-   b. Copy the ApolloLakeFspBinPkg to the folder
+4. Get the Intel(R) Firmware Support Package(Intel FSP)
+   1. Run `git clone -b ApolloLake https://github.com/IntelFsp/FSP.git` to 
download FSP.
+   2. Copy the ApolloLakeFspBinPkg to the folder
   "C:\MyWorkspace\edk2-platforms\Silicon\BroxtonSoC\BroxtonFspPkg".

-5) Install UEFI UNDI driver:
-   a. Download PREBOOT.EXE Version 21.1 from the "Intel® Ethernet Connections 
+5. Install UEFI UNDI driver:
+   1. Download PREBOOT.EXE Version 21.1 from the "Intel® Ethernet Connections
   Boot Utility, Preboot Images, and EFI Drivers" page.
   
https://downloadcenter.intel.com/download/19186/Intel-Ethernet-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers
-   b. Install PREBOOT.EXE into the default folder (C:\Intel21.1).
-   c. Copy the UEFI x64 PCI-E gigabit driver 
(C:\Intel21.1\APPS\EFI\EFIx64\EX3.EFI,
+   2. Install PREBOOT.EXE into the default folder (C:\Intel21.1).
+   3. Copy the UEFI x64 PCI-E gigabit driver 
(C:\Intel21.1\APPS\EFI\EFIx64\EX3.EFI,
   where "" is the driver version number) to the platform package 
directory below, create the folder if it does not exist:
   
"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\Common\Binaries\UNDI\I210PcieUndiDxe"
-   d. Open the file 
"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\PlatformPkg.fdf"
+   4. Open the file 
"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\PlatformPkg.fdf"
   and change the UNDI driver file name reference with the

Re: [edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Rebecca Cran]

On 2/23/2017 11:53 AM, Brian J. Johnson wrote:

Sorry if I'm bikeshedding...  NUMBER_OF_PROCESSORS isn't a good 
default for those of us who build on servers with hundreds of threads 
available.  The OS, disks, and build.exe/build.py become bottlenecks.  
Maybe we could put a cap (say, 20) on the default thread limit, so it 
uses NUMBER_OF_PROCESSORS or 20 threads, whichever is less.


Or just set a small, fixed number of threads by default and document 
better how to change it, as others suggested.


Good point. I think the best approach will be to have a --setup 
parameter which configures defaults in Conf/target.txt, after which 
users can change MAX_CONCURRENT_THREAD_NUMBER - instead of the current 
method which involves figuring out which of files ends up running 
build.exe with '-n '.


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

Re: [edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Rebecca Cran]

On 2/22/2017 9:34 AM, Richardson, Brian wrote:

Thanks for the input. For future reference, you can use the TianoCore Bugzilla 
to report issues on any EDK II feature/platform. 
https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues

I agree the readme.md should be present, and use markup instead of plain text 
to work better in github. You can open an issue on this in Bugzilla.

Normally, we ask folks to change the number of processor threads based on their 
system configuration. We don't add a larger thread number by default, but it 
might be good to set it '5' by default (assuming a dual core processor with 
hyperthreading) instead of '1' (assuming a single core system w/o threading). I 
don't know if this will cause any compatibility issues on older systems, but 
it's worth a check.

At this time, MinnowBoard 3 build is only validated in Windows. That's why 
there is no equivalent .sh file for BuildBIOS yet, but it will be added once 
Linux build is verified and checked in.


I'm more about _fixing_ issues I find rather than reporting them! Are 
you saying that patches wouldn't be welcome just now?  Is there a reason 
why you don't want to make full use of the CPU while building? And I 
understand that MinnowBoard 3 only builds under Windows at the moment, 
but if more of it built using python (and python is already listed as a 
prerequisite in the ReadMe file) the porting might be simpler.


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

Re: [edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Rebecca Cran]

On 2/21/2017 9:50 PM, Gao, Liming wrote:


   Could you introduce what change will be done for build improvement? I am 
also interested in this topic.


The first change I'd make is to set 'buildthreads' in BuildBIOS to 
%NUMBER_OF_PROCESSORS% - that by itself reduces the build time from 
around 7 minutes to 2.5 on my system. I also have some changes to the 
ReadMe.MD file to convert it to be a MD file instead of plain text, 
which massively increases readability on GitHub.  I've also been 
wondering about allowing more parameters to be passed through to 'build' 
such as reducing the verbosity to make compiler warnings more apparent. 
Finally, and this is likely more controversial - I've been wondering if 
the build scripts like BuildBIOS should be in python instead of Windows 
.cmd/.bat since python is already used elsewhere and is more flexible.


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

[edk2] Improvements to build system etc. for edk2-platforms devel-MinnowBoard3?

[Rebecca Cran]

I'm a bit of a build system geek and noticed there are some improvements 
(e.g. improving build speed) that could be made to the 
devel-MinnowBoard3 branch in edk2-platforms.  I know it's still in heavy 
development, so I'm wondering if my contributions might be welcome, or 
if I should hold off for a few more months?



--

Rebecca

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

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

[Rebecca Cran]

On 2/21/2017 12:02 PM, Laszlo Ersek wrote:


But in this case, the full edk2 codebase has to be grepped for
VA_LIST-taking functions, and all of them must be flipped to EFIAPI, if
they currently aren't EFIAPI. Covering just XenStoreVSPrint() seems
incomplete. (Note: CryptoPkg/Library/OpensslLib is an exception.)


I think this was discussed previously but I can't remember: is there a 
reason for not just compiling everything with -mabi=ms ?


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

Re: [edk2] [PATCH] Reformat ReadMe.MD with markdown (github) and simplify instructions

[Rebecca Cran]

Sorry, I didn't include the repo/branch name. This patch is for 
edk2-platforms, branch devel-MinnowBoard3.



--

Rebecca


On 2/18/2017 3:51 PM, Rebecca Cran wrote:

The formatting of ReadMe.MD on GitHub wasn't very nice, with steps
running into one another. This change reformats the text to use
GitHub Flavored Markdown.

It also simplifies a few of the steps, for example combining the
git clone and rename into a single command.
---
  ReadMe.MD | 163 ++
  1 file changed, 78 insertions(+), 85 deletions(-)

diff --git a/ReadMe.MD b/ReadMe.MD
index ec55d6569767..15638503bc91 100644
--- a/ReadMe.MD
+++ b/ReadMe.MD
@@ -1,138 +1,131 @@
  
  This code base is designed for the MinnowBoard v3 platform using the Intel(R) 
Atom(tm) Processor E3900 Series.
  
-

-INDEX
-
+# INDEX
+
  1.  HOW TO CREATE A FULL SOURCE TREE
  2.  HOW TO BUILD (WINDOWS ENVIRONMENT)
  3.  MAINTAINERS
-
-
-1.   HOW TO CREATE A FULL SOURCE TREE
-
-1) Create a new folder (directory) on the root of your local development 
machine
+
+## 1. HOW TO CREATE A FULL SOURCE TREE
+
+1. Create a new folder (directory) on the root of your local development 
machine
 for use as your work space (this example uses "C:\MyWorkspace").
 
 NOTE: Some code paths are very long, and placing the working directory too

   deep below the ROOT directory may cause the path to be longer than 
the
   operating system or file system's maximum path length.
  
-2) Get MinnowBoard v3 branch from GitHub with the following command.

-   a. git clone https://github.com/tianocore/edk2-platforms.git -b 
devel-MinnowBoard3
+2. Get MinnowBoard v3 branch from GitHub with the following command.
+   * `git clone -b devel-MinnowBoard3 
https://github.com/tianocore/edk2-platforms.git`

 Once the download completes, all EDK II packages and files will be found

 under the "C:\MyWorkspace\edk2-platforms" directory.
  
-3) Get the BaseTools binary and copy them to BaseTools binary folder.

-   a. git clone https://github.com/tianocore/edk2-BaseTools-win32.git
-   b. Enter folder edk2-BaseTools-win32
-   b. git checkout f0c97b7716ce92f1fc657f87f29bcc9170e5eb1f
-   c. Rename folder name from "edk2-BaseTools-win32/" to "win32/" and copy
-  win32/ to the BaseTools Binary folder.
-  (C:\MyWorkspace\edk2-platforms\BaseTools\Bin\)
+3. Get the BaseTools binary and copy them to BaseTools binary folder.
+   1. Enter folder BaseTools\Bin
+   2. `git clone https://github.com/tianocore/edk2-BaseTools-win32.git Win32`
+   3. Enter folder Win32
+   4. `git checkout f0c97b7716ce92f1fc657f87f29bcc9170e5eb1f`
  
-4) Get the Intel(R) Firmware Support Package(Intel FSP)

-   a. Run "git clone -b ApolloLake https://github.com/IntelFsp/FSP.git; to 
download FSP.
-   b. Copy the ApolloLakeFspBinPkg to the folder
+4. Get the Intel(R) Firmware Support Package(Intel FSP)
+   1. Run `git clone -b ApolloLake https://github.com/IntelFsp/FSP.git` to 
download FSP.
+   2. Copy the ApolloLakeFspBinPkg to the folder
"C:\MyWorkspace\edk2-platforms\Silicon\BroxtonSoC\BroxtonFspPkg".
 
-5) Install UEFI UNDI driver:

-   a. Download PREBOOT.EXE Version 21.1 from the "Intel® Ethernet Connections
+5. Install UEFI UNDI driver:
+   1. Download PREBOOT.EXE Version 21.1 from the "Intel® Ethernet Connections
Boot Utility, Preboot Images, and EFI Drivers" page.

https://downloadcenter.intel.com/download/19186/Intel-Ethernet-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers
-   b. Install PREBOOT.EXE into the default folder (C:\Intel21.1).
-   c. Copy the UEFI x64 PCI-E gigabit driver 
(C:\Intel21.1\APPS\EFI\EFIx64\EX3.EFI,
+   2. Install PREBOOT.EXE into the default folder (C:\Intel21.1).
+   3. Copy the UEFI x64 PCI-E gigabit driver 
(C:\Intel21.1\APPS\EFI\EFIx64\EX3.EFI,
where "" is the driver version number) to the platform package 
directory below, create the folder if it does not exist:

"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\Common\Binaries\UNDI\I210PcieUndiDxe"
-   d. Open the file 
"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\PlatformPkg.fdf"
+   4. Open the file 
"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\PlatformPkg.fdf"
and change the UNDI driver file name reference with the one that was 
downloaded:
   SECTION PE32 = 
BroxtonPlatformPkg/Common/Binaries/UNDI/I210PcieUndiDxe/E7006X3.EFI
 
-6) Install th

[edk2] [PATCH] Reformat ReadMe.MD with markdown (github) and simplify instructions

[Rebecca Cran]

The formatting of ReadMe.MD on GitHub wasn't very nice, with steps
running into one another. This change reformats the text to use
GitHub Flavored Markdown.

It also simplifies a few of the steps, for example combining the
git clone and rename into a single command.
---
 ReadMe.MD | 163 ++
 1 file changed, 78 insertions(+), 85 deletions(-)

diff --git a/ReadMe.MD b/ReadMe.MD
index ec55d6569767..15638503bc91 100644
--- a/ReadMe.MD
+++ b/ReadMe.MD
@@ -1,138 +1,131 @@
 
 This code base is designed for the MinnowBoard v3 platform using the Intel(R) 
Atom(tm) Processor E3900 Series.
 
-
-INDEX 
-
+# INDEX
+
 1.  HOW TO CREATE A FULL SOURCE TREE
 2.  HOW TO BUILD (WINDOWS ENVIRONMENT)
 3.  MAINTAINERS
-  
-
-1.   HOW TO CREATE A FULL SOURCE TREE 
-
-1) Create a new folder (directory) on the root of your local development 
machine
+
+## 1. HOW TO CREATE A FULL SOURCE TREE
+
+1. Create a new folder (directory) on the root of your local development 
machine
for use as your work space (this example uses "C:\MyWorkspace").

NOTE: Some code paths are very long, and placing the working directory too
  deep below the ROOT directory may cause the path to be longer than 
the 
  operating system or file system's maximum path length.
 
-2) Get MinnowBoard v3 branch from GitHub with the following command.
-   a. git clone https://github.com/tianocore/edk2-platforms.git -b 
devel-MinnowBoard3
+2. Get MinnowBoard v3 branch from GitHub with the following command.
+   * `git clone -b devel-MinnowBoard3 
https://github.com/tianocore/edk2-platforms.git`
   
Once the download completes, all EDK II packages and files will be found
under the "C:\MyWorkspace\edk2-platforms" directory.
 
-3) Get the BaseTools binary and copy them to BaseTools binary folder.
-   a. git clone https://github.com/tianocore/edk2-BaseTools-win32.git
-   b. Enter folder edk2-BaseTools-win32
-   b. git checkout f0c97b7716ce92f1fc657f87f29bcc9170e5eb1f
-   c. Rename folder name from "edk2-BaseTools-win32/" to "win32/" and copy
-  win32/ to the BaseTools Binary folder.
-  (C:\MyWorkspace\edk2-platforms\BaseTools\Bin\)
+3. Get the BaseTools binary and copy them to BaseTools binary folder.
+   1. Enter folder BaseTools\Bin
+   2. `git clone https://github.com/tianocore/edk2-BaseTools-win32.git Win32`
+   3. Enter folder Win32
+   4. `git checkout f0c97b7716ce92f1fc657f87f29bcc9170e5eb1f`
 
-4) Get the Intel(R) Firmware Support Package(Intel FSP)
-   a. Run "git clone -b ApolloLake https://github.com/IntelFsp/FSP.git; to 
download FSP.
-   b. Copy the ApolloLakeFspBinPkg to the folder
+4. Get the Intel(R) Firmware Support Package(Intel FSP)
+   1. Run `git clone -b ApolloLake https://github.com/IntelFsp/FSP.git` to 
download FSP.
+   2. Copy the ApolloLakeFspBinPkg to the folder
   "C:\MyWorkspace\edk2-platforms\Silicon\BroxtonSoC\BroxtonFspPkg".

-5) Install UEFI UNDI driver:
-   a. Download PREBOOT.EXE Version 21.1 from the "Intel® Ethernet Connections 
+5. Install UEFI UNDI driver:
+   1. Download PREBOOT.EXE Version 21.1 from the "Intel® Ethernet Connections
   Boot Utility, Preboot Images, and EFI Drivers" page.
   
https://downloadcenter.intel.com/download/19186/Intel-Ethernet-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers
-   b. Install PREBOOT.EXE into the default folder (C:\Intel21.1).
-   c. Copy the UEFI x64 PCI-E gigabit driver 
(C:\Intel21.1\APPS\EFI\EFIx64\EX3.EFI,
+   2. Install PREBOOT.EXE into the default folder (C:\Intel21.1).
+   3. Copy the UEFI x64 PCI-E gigabit driver 
(C:\Intel21.1\APPS\EFI\EFIx64\EX3.EFI,
   where "" is the driver version number) to the platform package 
directory below, create the folder if it does not exist:
   
"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\Common\Binaries\UNDI\I210PcieUndiDxe"
-   d. Open the file 
"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\PlatformPkg.fdf"
+   4. Open the file 
"C:\MyWorkspace\edk2-platforms\Platform\BroxtonPlatformPkg\PlatformPkg.fdf"
   and change the UNDI driver file name reference with the one that was 
downloaded:
  SECTION PE32 = 
BroxtonPlatformPkg/Common/Binaries/UNDI/I210PcieUndiDxe/E7006X3.EFI

-6) Install the NASM assembly language compiler:
 
-   a. Download NASM 2.12.02 binaries: 
-  
http://www.nasm.us/pub/nasm/releasebuilds/2.12.02/win32/nasm-2.12.02-win32.zip
-  
http://www.nasm.us/pub/nasm/releasebuilds/2.12.02/win64/nasm-2.12.02-win64.zip
-   b. 

Re: [edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg

[Rebecca Cran]

On 2/16/2017 3:59 PM, Shah, Tapan wrote:

UEFI Spec does not have old FMP image descriptor structures V1 and V2 defined.

MdePkg only follows the spec, so it contains the latest version # 3. But there 
are still drivers using old V1, V2 revisions and Shell 'dh' command needs to 
support decoding all revisions and needs to remain in ShellPkg.


Ah, okay - thanks. I was thinking that drivers might still like to 
support older systems that still run UEFI 2.3, 2.4 etc. and so would 
need to access the older structures.


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

[edk2] EFI_FIRMWARE_IMAGE_DESCRIPTOR v1/v2/v3: MdePkg and ShellPkg

[Rebecca Cran]

I'm a bit confused about why Firmware Management Protocol image 
descriptor structures are split between MdePkg and ShellPkg:


In MdePkg/Include/Protocol/FirmwareInformation.h there's the definition 
of EFI_FIRMWARE_IMAGE_DESCRIPTOR (version 3).  But then the 
EFI_FIRMWARE_IMAGE_DESCRIPTOR_V1 and EFI_FIRMWARE_IMAGE_DESCRIPTOR_V2 
struct definitions are in 
ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.h along with 
some seemingly-unrelated stuff - and that file appears to have a 
ridiculous number of #include's!



Is there a reasoning behind putting the older structures in ShellPkg, or 
should they be moved to FirmwareInformation.h?



--

Rebecca

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

Re: [edk2] Print from DXE_DRIVER

[Rebecca Cran]

> On Feb 8, 2017, at 5:43 PM, Andrew Fish  wrote:
> 
> If  you want to write directly to the UEFI Console you can try this. Place it 
> in the entry point of your driver in case you have some bug that is 
> preventing your from registering the Driver Binding Protocol. 
> 
> gST->ConOut->OutputString (gST->ConOut, L"Hello World\n\r");

Note that on some systems, at some times gST->ConOut may be NULL, so it might 
be worth checking before calling it (unless you know otherwise on your dev 
system).

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

[edk2] [PATCH] Fix some typos of "according"

[Rebecca Cran]

Cc: Feng Tian <feng.t...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Siyuan Fu <siyuan...@intel.com>
Cc: Jiaxin Wu <jiaxin...@intel.com>
Cc: Liming Gao <liming@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Rebecca Cran <rebe...@bluestop.org>
---
 EdkCompatibilityPkg/Sample/Tools/Source/UefiStrGather/StrGather.c | 2 +-
 MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c   | 4 ++--
 MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c  | 2 +-
 MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdMemory.c  | 2 +-
 MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdSymbol.c  | 6 +++---
 MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbDisasmSupport.c  | 2 +-
 MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbDisasmSupport.h  | 2 +-
 MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c   | 2 +-
 NetworkPkg/HttpBootDxe/HttpBootConfigStrings.uni  | 2 +-
 9 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/EdkCompatibilityPkg/Sample/Tools/Source/UefiStrGather/StrGather.c 
b/EdkCompatibilityPkg/Sample/Tools/Source/UefiStrGather/StrGather.c
index 535a265046..e71b5e4e7d 100644
--- a/EdkCompatibilityPkg/Sample/Tools/Source/UefiStrGather/StrGather.c
+++ b/EdkCompatibilityPkg/Sample/Tools/Source/UefiStrGather/StrGather.c
@@ -854,7 +854,7 @@ GetLangCode (
   }
 
   //
-  // Convert the language accoring to the table.
+  // Convert the language according to the table.
   //
   for (Index = 0; LanguageConvertTable[Index].ISO639 != NULL; Index++) {
 if (wcscmp(LanguageConvertTable[Index].ISO639, Lang) == 0) {
diff --git a/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c 
b/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
index eba938e2a9..6cfd35945a 100644
--- a/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
+++ b/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
@@ -785,7 +785,7 @@ SmmCoreGetMemoryMapMemoryAttributesTable (
 //
 
 /**
-  Set MemoryProtectionAttribute accroding to PE/COFF image section alignment.
+  Set MemoryProtectionAttribute according to PE/COFF image section alignment.
 
   @param[in]  SectionAlignmentPE/COFF section alignment
 **/
@@ -1225,7 +1225,7 @@ Finish:
 }
 
 /**
-  Find image record accroding to image base and size.
+  Find image record according to image base and size.
 
   @param[in]  ImageBaseBase of PE image
   @param[in]  ImageSizeSize of PE image
diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c 
b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
index a4579bf043..8734291ae3 100644
--- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
+++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
@@ -396,7 +396,7 @@ HttpParseUrl (
   FoundAt = FALSE;
   for (Char = Url; Char < Url + Length; Char++) {
 //
-// Update state machine accoring to next char.
+// Update state machine according to next char.
 //
 State = NetHttpParseUrlChar (*Char, State);
 
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdMemory.c 
b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdMemory.c
index 74c17bd248..3dc6376215 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdMemory.c
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdMemory.c
@@ -37,7 +37,7 @@ EdbDisplayMemoryUnit (
   UINT64 Data64;
 
   //
-  // Print accroding to width
+  // Print according to width
   //
   switch (Width) {
   case EdbWidthUint8:
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdSymbol.c 
b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdSymbol.c
index ba62c6ac27..3ca793059f 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdSymbol.c
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdSymbol.c
@@ -70,7 +70,7 @@ GetDirNameFromFullPath (
 
 /**
 
-  Construct full path accroding to dir and file path.
+  Construct full path according to dir and file path.
 
   @param  DirPath - dir path
   @param  FilePath- file path
@@ -127,7 +127,7 @@ EdbSymbolTypeToStr (
 
 /**
 
-  Find the symbol accroding to address and display symbol.
+  Find the symbol according to address and display symbol.
 
   @param  Address - SymbolAddress
   @param  DebuggerPrivate - EBC Debugger private data structure
@@ -190,7 +190,7 @@ DebuggerDisplaySymbolAccrodingToAddress (
 
 /**
 
-  Find the symbol accroding to name and display symbol.
+  Find the symbol according to name and display symbol.
 
   @param  SymbolFileName  - The Symbol File Name, NULL means for all
   @param  SymbolName  - The Symbol Name, NULL means for all
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbDisasmSupport.c 
b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbDisasmSupport.c
index 472158b8f9..26a86548b4 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbDisasmSupport.c
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbDisasmSupport.c
@@ -1178,7 +1178,7 @@ EdbShowDisasm (
 
 /**
 
-  Get registe

Re: [edk2] [PATCH] MdeModulePkg, NetworkPkg, EdkCompatibilityPkg: fix some typos of 'according'

[Rebecca Cran]

Replying in order to actually Cc the people I mentioned in the commit 
message.


--

Rebecca

On 1/26/2017 8:39 AM, Rebecca Cran wrote:

Fix some typos of "according".



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


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

[edk2] [PATCH] MdeModulePkg, NetworkPkg, EdkCompatibilityPkg: fix some typos of 'according'

[Rebecca Cran]

Fix some typos of "according".

From 79a1ef3a17cbdc46e5a85c881ba83a65b44aafeb Mon Sep 17 00:00:00 2001
From: Rebecca Cran <rebe...@bluestop.org>
Date: Thu, 26 Jan 2017 08:38:18 -0700
Subject: [PATCH] Fix some typos of "according"

Cc: Feng Tian <feng.t...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Siyuan Fu <siyuan...@intel.com>
Cc: Jiaxin Wu <jiaxin...@intel.com>
Cc: Liming Gao <liming@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Rebecca Cran <rebe...@bluestop.org>
---
 EdkCompatibilityPkg/Sample/Tools/Source/UefiStrGather/StrGather.c | 2 +-
 MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c   | 4 ++--
 MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c  | 2 +-
 MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdMemory.c  | 2 +-
 MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdSymbol.c  | 6 +++---
 MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbDisasmSupport.c  | 2 +-
 MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbDisasmSupport.h  | 2 +-
 MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Impl.c   | 2 +-
 NetworkPkg/HttpBootDxe/HttpBootConfigStrings.uni  | 2 +-
 9 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/EdkCompatibilityPkg/Sample/Tools/Source/UefiStrGather/StrGather.c 
b/EdkCompatibilityPkg/Sample/Tools/Source/UefiStrGather/StrGather.c
index 535a265046..e71b5e4e7d 100644
--- a/EdkCompatibilityPkg/Sample/Tools/Source/UefiStrGather/StrGather.c
+++ b/EdkCompatibilityPkg/Sample/Tools/Source/UefiStrGather/StrGather.c
@@ -854,7 +854,7 @@ GetLangCode (
   }
 
   //
-  // Convert the language accoring to the table.
+  // Convert the language according to the table.
   //
   for (Index = 0; LanguageConvertTable[Index].ISO639 != NULL; Index++) {
 if (wcscmp(LanguageConvertTable[Index].ISO639, Lang) == 0) {
diff --git a/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c 
b/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
index eba938e2a9..6cfd35945a 100644
--- a/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
+++ b/MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
@@ -785,7 +785,7 @@ SmmCoreGetMemoryMapMemoryAttributesTable (
 //
 
 /**
-  Set MemoryProtectionAttribute accroding to PE/COFF image section alignment.
+  Set MemoryProtectionAttribute according to PE/COFF image section alignment.
 
   @param[in]  SectionAlignmentPE/COFF section alignment
 **/
@@ -1225,7 +1225,7 @@ Finish:
 }
 
 /**
-  Find image record accroding to image base and size.
+  Find image record according to image base and size.
 
   @param[in]  ImageBaseBase of PE image
   @param[in]  ImageSizeSize of PE image
diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c 
b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
index a4579bf043..8734291ae3 100644
--- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
+++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
@@ -396,7 +396,7 @@ HttpParseUrl (
   FoundAt = FALSE;
   for (Char = Url; Char < Url + Length; Char++) {
 //
-// Update state machine accoring to next char.
+// Update state machine according to next char.
 //
 State = NetHttpParseUrlChar (*Char, State);
 
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdMemory.c 
b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdMemory.c
index 74c17bd248..3dc6376215 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdMemory.c
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdMemory.c
@@ -37,7 +37,7 @@ EdbDisplayMemoryUnit (
   UINT64 Data64;
 
   //
-  // Print accroding to width
+  // Print according to width
   //
   switch (Width) {
   case EdbWidthUint8:
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdSymbol.c 
b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdSymbol.c
index ba62c6ac27..3ca793059f 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdSymbol.c
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbCmdSymbol.c
@@ -70,7 +70,7 @@ GetDirNameFromFullPath (
 
 /**
 
-  Construct full path accroding to dir and file path.
+  Construct full path according to dir and file path.
 
   @param  DirPath - dir path
   @param  FilePath- file path
@@ -127,7 +127,7 @@ EdbSymbolTypeToStr (
 
 /**
 
-  Find the symbol accroding to address and display symbol.
+  Find the symbol according to address and display symbol.
 
   @param  Address - SymbolAddress
   @param  DebuggerPrivate - EBC Debugger private data structure
@@ -190,7 +190,7 @@ DebuggerDisplaySymbolAccrodingToAddress (
 
 /**
 
-  Find the symbol accroding to name and display symbol.
+  Find the symbol according to name and display symbol.
 
   @param  SymbolFileName  - The Symbol File Name, NULL means for all
   @param  SymbolName  - The Symbol Name, NULL means for all
diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbDisasmSupport.c 
b/MdeModulePkg/Universal/EbcDxe/E

[edk2] [PATCH 0/1] Use the Windows Kits directory in 32-bit ProgramFiles, since none exists in 64-bit one

[Rebecca Cran]

On a fresh install of Windows 10 and Visual Studio 2015 etc., "C:\Program 
Files\Windows Kits"
doesn't exist - only "C:\Program Files (x86)\Windows Kits" does. I don't know
about 32-bit Windows, but since at this point 64-bit should be most common,
update the path to the Windows SDK 8.1.

Rebecca Cran (1):
  Use the Windows Kits directory under the 32-bit Program Files

 BaseTools/Conf/tools_def.template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.11.0.windows.1

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

[edk2] [PATCH 1/1] Use the Windows Kits directory under the 32-bit Program Files

[Rebecca Cran]

On a fresh install of Windows 10 with Visual Studio 2015, a "Windows Kits"
directory only exists under the 32-bit Program Files directory, not the
64-bit one.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Rebecca Cran <rebe...@bluestop.org>
---
 BaseTools/Conf/tools_def.template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index aaae4fcd2916..5ec56ef93045 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -90,7 +90,7 @@ DEFINE WINSDK8_BIN   = ENV(WINSDK8_PREFIX)x86\
 DEFINE WINSDK8x86_BIN= ENV(WINSDK8x86_PREFIX)x64
 
 # Microsoft Visual Studio 2015 Professional Edition
-DEFINE WINSDK81_BIN   = ENV(WINSDK81_PREFIX)x86\
+DEFINE WINSDK81_BIN   = ENV(WINSDK81x86_PREFIX)x86
 DEFINE WINSDK81x86_BIN= ENV(WINSDK81x86_PREFIX)x64
 
 # These defines are needed for certain Microsoft Visual Studio tools that
-- 
2.11.0.windows.1

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

Re: [edk2] EXT FS support

[Rebecca Cran]

On 11/23/16 1:11 PM, Laszlo Ersek wrote:


Separately, a small note on ext4 (because you mention it above). I seem to 
recall a filesystem expert colleague of mine advise *against* using journaled 
filesystems for booting with e.g. grub2. The argument goes (if I recall right), 
XFS is considered to be in clean state if the data has made it to the final 
location *or* the persistent journal. When you cleanly unmount (or remount r/o) 
and shut down, the journal will be flushed to the final location, so a boot 
loader that doesn't know about the journal will read consistent data. However, 
if you crash *without* data loss, then part of the data might be in the journal 
only, and only clients that can read the journal will see consistent data.


This might or might not be
an issue, depending on what the point of the exercise is.



The problem of course is that "reset" (reboot), "reset -s" (shutdown) 
etc. don't have any hooks a driver can use to flush data, so there will 
sometimes (depending on how long ago data was written) be an unclean 
unmount. At least when booting an OS there's an ExitBootServices event 
available to make sure any data is flushed before boot services ends.


Though I've seen one person talking about how there at least used to be 
a bug that means ExitBootServices isn't/wasn't called for one OS.


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

[edk2] tianocore.org site broken

[Rebecca Cran]

It looks like the tianocore site is broken: http://tianocore.org and 
http://tianocore.org/edk2 displays 404 pages, while 
http://www.tianocore.org/udk/udk2015/# has missing images etc.


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

Re: [edk2] EXT FS support

[Rebecca Cran]

On 11/22/16 9:19 AM, Pete Batard wrote:

Hi Marcin,

I can't speak for EDK2 integration plans, but as far as side-projects
are concerned, I have been porting the various GRUB *read-only* file
systems into standalone UEFI drivers. This includes an ext2/3/4 driver
if you are interested (and you can live without write support).

Please see http://efi.akeo.ie/ as well as the github project at
https://github.com/pbatard/efifs.


Pete,

Have you seen the UEFI filesystem drivers from the rEFInd project, at 
https://sourceforge.net/p/refind/code/ci/master/tree/filesystems/ ?


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

Re: [edk2] EXT FS support

[Rebecca Cran]

On 11/22/16 8:25 AM, Marcin Wojtas wrote:

Hello everyone,

Is there any plan of adding EXT filesystem support to EDK2? If not
officially is there a chance that it exists on some old branch, or in
any side project?


The rEFInd boot manager (http://www.rodsbooks.com/refind) has drivers 
for several filesystems including EXT and NTFS. From 
http://www.rodsbooks.com/refind/drivers.html :


"As described in the next section, Selecting an EFI Driver 
[http://www.rodsbooks.com/refind/drivers.html#selecting], drivers for 
ext2fs, ext3fs, ext4fs, ReiserFS, Btrfs, and a few non-native 
filesystems come with rEFInd."



--
Rebecca

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