Re: [edk2] OVMF: cross-filesystem copy broken? ("The source and destination are the same")

[Bruce Cran]

On 11/17/2016 2:35 AM, Laszlo Ersek wrote:


There's a patch on the list for said BZ:
[edk2] [PATCH v2] API PathRemoveLastItem not handle root paths properly

so if the BZ is indeed what you're encountering, then the patch should
fix it for you. Can you please test it and report back in that thread?


Unfortunately the patch doesn't fix the problem I'm seeing.

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

[edk2] OVMF: cross-filesystem copy broken? ("The source and destination are the same")

[Bruce Cran]

I don't know if this is a known issue, but it appears that 
cross-filesystem copies no longer work. I'm running OVMF X64 built from 
git commit a0426207c133bdf40c42561f26c20c4b3114d8f9.  I've tried copying 
between filesystems in various ways - with the current directory being 
fs0, fs1, specifying the destination as the current directory, a empty 
directory or a filename. It always results in the same error:


FS0:\efi\ubuntu\> cp grubx64.efi fs1:\

cp: The source and destination are the same.


I built OVMF with: `./OvmfPkg/build.sh -a X64 -t GCC49 -b NOOPT -D 
DEBUG_ON_SERIAL_PORT=TRUE` and am running OVMF with:



qemu-system-x86_64 -name uefi -M q35 -m size=16G -cpu host -enable-kvm \
  -drive 
if=pflash,format=raw,file=workspace/edk2/Build/OvmfX64/NOOPT_GCC49/FV/OVMF.fd 
-serial pty \

  -nodefaults -s -rtc base=utc -monitor stdio --usbdevice tablet \
  -vga qxl  -sdl   \
  -device vfio-pci,host=01:00.0,id=iodrive,rombar=0 \
  -drive file=uefi.img,if=ide,media=disk,id=disk,format=raw \
  -drive file=uefi_tmp.img,if=ide,media=disk,id=disk1,format=raw


--
Bruce

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

Re: [edk2] GenFv error 3000 building OvmfPkg X64 RELEASE

[Bruce Cran]

On 11/9/2016 5:37 PM, Wu, Hao A wrote:


This issue was introduced by commit 2ff3293. And it has been fixed via
commit 49d8f53.

Could you help to update the repository and see whether this issue still
exists? Thanks in advance.


Thanks - after rebuilding BaseTools and regenerating the files in Conf 
the problem has been fixed.


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

[edk2] GenFv error 3000 building OvmfPkg X64 RELEASE

[Bruce Cran]

I'm getting a failure when building (with gcc 6.2.1) OVMF X64 RELEASE 
(DEBUG builds fine) with the latest edk2 git master:


> ./OvmfPkg/build.sh -a X64 -t GCC49 -b RELEASE

.

Generating PEIFV FV
###
Generate Region at Offset 0x10
   Region Size = 0xA0
   Region Name = FV

Generating DXEFV FV








###Return Value = 2


GenFv: ERROR 3000: Invalid
GenFds.py...
  RelocateImage() call failed on rebase of 
/home/bcran/workspace/edk2/Build/OvmfX64/RELEASE_GCC49/FV/Ffs/F6697AC4-A776-4EE1-B643-1FEFF2B615BBIncompatiblePciDeviceSupportDxe/F6697AC4-A776-4EE1-B643-1FEFF2B615BB.ffs

 : error 7000: Failed to generate FV
GenFv: ERROR 3000: Invalid

  Could not rebase 
/home/bcran/workspace/edk2/Build/OvmfX64/RELEASE_GCC49/FV/Ffs/F6697AC4-A776-4EE1-B643-1FEFF2B615BBIncompatiblePciDeviceSupportDxe/F6697AC4-A776-4EE1-B643-1FEFF2B615BB.ffs.



### ['GenFv', '-a', 
'/home/bcran/workspace/edk2/Build/OvmfX64/RELEASE_GCC49/FV/Ffs/DXEFV.inf', 
'-o', 
'/home/bcran/workspace/edk2/Build/OvmfX64/RELEASE_GCC49/FV/DXEFV.Fv', 
'-i', '/home/bcran/workspace/edk2/Build/OvmfX64/RELEASE_GCC49/FV/DXEFV.inf']



build.py...
 : error 7000: Failed to execute command
GenFds -f /home/bcran/workspace/edk2/OvmfPkg/OvmfPkgX64.fdf 
--conf=/home/bcran/workspace/edk2/Conf -o 
/home/bcran/workspace/edk2/Build/OvmfX64/RELEASE_GCC49 -t GCC49 -b 
RELEASE -p /home/bcran/workspace/edk2/OvmfPkg/OvmfPkgX64.dsc -a X64 -D 
"EFI_SOURCE=/home/bcran/workspace/edk2/EdkCompatibilityPkg" -D 
"EDK_SOURCE=/home/bcran/workspace/edk2/EdkCompatibilityPkg" -D 
"TOOL_CHAIN_TAG=GCC49" -D "TOOLCHAIN=GCC49" -D "TARGET=RELEASE" -D 
"FAMILY=GCC" -D "WORKSPACE=/home/bcran/workspace/edk2" -D 
"EDK_TOOLS_PATH=/home/bcran/workspace/edk2/BaseTools" -D "ARCH=X64" -D 
"ECP_SOURCE=/home/bcran/workspace/edk2/EdkCompatibilityPkg" 
[/mnt/bcran/workspace/edk2]


- Failed -
Build end time: 10:42:33, Nov.09 2016
Build total time: 00:01:24

--
Bruce

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

Re: [edk2] OvmfPkg: hang in SetInterruptState with git 245cda6641ade1f1013c2d5c9c838f2706636828

[Bruce Cran]

On 10/18/2016 1:43 AM, Laszlo Ersek wrote:

On 10/18/16 02:06, Bruce Cran wrote:

I've just built both OVMF _and_ Qemu from the latest git sources, so I
don't know which is at fault - but I'm seeing a hang in:

#0  0x7f9dc030 in SetInterruptState (InterruptState=104 'h')
 at /home/bcran/workspace/edk2/MdePkg/Library/BaseLib/Cpu.c:60

It's at line 60 when it calls EnableInterrupts().

Introduced when? :)

It's been a while since we committed anything to OvmfPkg that could
cause this. Similarly, I don't recall anything risky like this going
into UefiCpuPkg. I rebuild OVMF every few days, against current master,
and I'm not seeing this. (Just retested at aaba2a44c24e.)


Just to follow up, I've just got around to re-trying it after a couple 
of weeks of new OpenSUSE Tumleweed kernels coming through, along with a 
new build of qemu and OVMF - and the problem has disappeared.


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

[edk2] OvmfPkg: hang in SetInterruptState with git 245cda6641ade1f1013c2d5c9c838f2706636828

[Bruce Cran]

I've just built both OVMF _and_ Qemu from the latest git sources, so I 
don't know which is at fault - but I'm seeing a hang in:


#0  0x7f9dc030 in SetInterruptState (InterruptState=104 'h')
at /home/bcran/workspace/edk2/MdePkg/Library/BaseLib/Cpu.c:60

It's at line 60 when it calls EnableInterrupts().

The entire backtrace is:

#0  0x7f9dc030 in SetInterruptState (InterruptState=104 'h')
at /home/bcran/workspace/edk2/MdePkg/Library/BaseLib/Cpu.c:60
#1  0x7f9d6c57 in UpdateIdtTable (IdtTable=0xd, 
TemplateMap=0x7fadd478, ExceptionHandlerData=0x7f9e2460)
at 
/home/bcran/workspace/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiDxeSmmCpuException.c:146

#2  0x7f9d5ff0 in InitializeCpuInterruptHandlers (VectorInfo=0xd)
at 
/home/bcran/workspace/edk2/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeException.c:111

#3  0x7f9d65fd in HasErrorCode ()
#4  0x000d in ?? ()
#5  0x7fadd478 in ?? ()
#6  0x7fa7b748 in ?? ()
#7  0x0012 in ?? ()
#8  0x7fadd4a0 in ?? ()
#9  0x in ?? ()


I _have_ tried going back to older revisions of qemu so I'm wondering if 
this could be a problem introduced by OVMF?


--
Bruce

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

Re: [edk2] [Patch V4] BaseTools: support the NOOPT target with the GCC tool chains

[Bruce Cran]

On 10/10/2016 8:00 PM, Yonghong Zhu wrote:


Update the tools_def.template to add NOOPT support with GCC tool chains.
Also disable -flto and -Os in NOOPT target for GCC5.

Cc: Liming Gao 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 


Tested-by: Bruce Cran 

Tested with GCC49 and GCC5 toolchain builds and verified neither causes 
gdb single-stepping to jump around.


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

Re: [edk2] [PATCH] Add NOOPT build targets to OvmfPkg for source level debugging

[Bruce Cran]

On 10/10/2016 4:29 PM, Laszlo Ersek wrote:



(maybe the subject can be rewritten as

   OvmfPkg: add NOOPT build target for source level debugging

but I can do that later when I commit the patch.)


Oh, good point!

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

[edk2] [PATCH] Add NOOPT build targets to OvmfPkg for source level debugging

[Bruce Cran]

From ef7b3dfe26bb7748d838974af57cd73e40e24c94 Mon Sep 17 00:00:00 2001
From: Bruce Cran 
Date: Mon, 10 Oct 2016 09:35:50 -0600
Subject: [PATCH] Add NOOPT build targets to OvmfPkg for source level debugging

Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Yonghong Zhu 
Cc: Laszlo Ersek 
Signed-off-by: Bruce Cran 
---
 OvmfPkg/OvmfPkgIa32.dsc| 2 +-
 OvmfPkg/OvmfPkgIa32X64.dsc | 2 +-
 OvmfPkg/OvmfPkgX64.dsc | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 7213197..41500ca 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -26,7 +26,7 @@
   DSC_SPECIFICATION  = 0x00010005
   OUTPUT_DIRECTORY   = Build/OvmfIa32
   SUPPORTED_ARCHITECTURES= IA32
-  BUILD_TARGETS  = DEBUG|RELEASE
+  BUILD_TARGETS  = NOOPT|DEBUG|RELEASE
   SKUID_IDENTIFIER   = DEFAULT
   FLASH_DEFINITION   = OvmfPkg/OvmfPkgIa32.fdf
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index c27024a..1bd4b21 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -26,7 +26,7 @@
   DSC_SPECIFICATION  = 0x00010005
   OUTPUT_DIRECTORY   = Build/Ovmf3264
   SUPPORTED_ARCHITECTURES= IA32|X64
-  BUILD_TARGETS  = DEBUG|RELEASE
+  BUILD_TARGETS  = NOOPT|DEBUG|RELEASE
   SKUID_IDENTIFIER   = DEFAULT
   FLASH_DEFINITION   = OvmfPkg/OvmfPkgIa32X64.fdf
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index c34b266..460f7bb 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -26,7 +26,7 @@
   DSC_SPECIFICATION  = 0x00010005
   OUTPUT_DIRECTORY   = Build/OvmfX64
   SUPPORTED_ARCHITECTURES= X64
-  BUILD_TARGETS  = DEBUG|RELEASE
+  BUILD_TARGETS  = NOOPT|DEBUG|RELEASE
   SKUID_IDENTIFIER   = DEFAULT
   FLASH_DEFINITION   = OvmfPkg/OvmfPkgX64.fdf
 
-- 
2.10.0

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

Re: [edk2] [Patch V2] BaseTools: support the NOOPT target with the GCC tool chains

[Bruce Cran]

On 10/04/2016 07:30 PM, Yonghong Zhu wrote:


Update the tools_def.template to add NOOPT support with GCC tool chains.

Cc: Liming Gao 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 


Reviewed-by: Bruce Cran 
Tested-by: Bruce Cran 

Tested with both GCC49 and GCC5 toolchain settings (using gcc 6.2.1 for 
both) and verified that both have functional debugging, though gdb skips 
around with GCC5 as expected due to LTCG.


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

Re: [edk2] [Patch] BaseTools: support the NOOPT target with the GCC tool chains

[Bruce Cran]

On 10/3/2016 10:09 AM, Laszlo Ersek wrote:


"BaseTools/Scripts/GccBase.lds" discards the gnu_debuglink section --
intentionally, from commit efe690cab3fb5 ("BaseTools GCC: add unified
GCC linker script for all archs and versions").

If this section is necessary for debugging, then why does the DEBUG
build work? In other words, why does the DEBUG build contain
gnu_debuglink despite the discard rule? Ard, any idea?


tools_def.template contains a command to add it:

DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
--add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug


I've followed up with the original email to say that adding a NOOPT line 
fixes debugging for me.


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

Re: [edk2] [Patch] BaseTools: support the NOOPT target with the GCC tool chains

[Bruce Cran]

On 9/30/2016 1:44 AM, Yonghong Zhu wrote:

Update the tools_def.template to add NOOPT support with GCC tool chains.


In the section "GCC Common" there's

DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = 
--add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug

RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG   =

A NOOPT line similar to the DEBUG one needs to be added for debugging to 
work.
I've verified that by adding it the reload-uefi command runs and 
single-stepping works.


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

Re: [edk2] [Patch] BaseTools: support the NOOPT target with the GCC tool chains

[Bruce Cran]

On 10/3/2016 2:59 AM, Laszlo Ersek wrote:


Can you compare "DEBUG/GdbSyms.dll" with "NOOPT/GdbSyms.dll", just
visually, using "nm" and/or "readelf"? Something might stand out.


The NOOPT GdbSyms.dll file is missing the .gnu_debuglink section. It's 
also missing ".LCx" (where x is 0 to 20) symbols in the .symtab section.


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

Re: [edk2] [Patch] BaseTools: support the NOOPT target with the GCC tool chains

[Bruce Cran]

(cc'ing Andrei Warkentin)

On 9/30/2016 4:11 AM, Laszlo Ersek wrote:

Can you please test this in the environment where you wanted to use it
originally? (I assume you were using some kind of source level debugging.)

For that, you'll probably have to add NOOPT to BUILD_TARGETS in the
OvmfPkg/OvmfPkg*.dsc files. If you do that and everything works fine for
you, I'd appreciate if you could also submit the OvmfPkg patch to the list.


The patch looks good, but unfortunately for some reason it breaks 
debugging using Andrei's gdb_uefi.py script: loading symbols fails:


The target architecture is assumed to be i386:x86-64:intel
0x7e65dec8 in ?? ()
Python Exception  No type named 
EFI_SYSTEM_TABLE_POINTER.:

/home/bcran/.gdbinit:8: Error in sourced command file:
Error occurred in Python command: No type named EFI_SYSTEM_TABLE_POINTER.

I've verified that a DEBUG build with the same git checkout does still 
work. I've looked through OvmfX64.dsc and couldn't see anything that 
depends on DEBUG that would be omitting stuff for NOOPT, so I'm stuck.


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

[edk2] NOOPT OVMF build (or otherwise with optimizations disabled)

[Bruce Cran]

Would it be possible to either have a NOOPT build for OVMF added, or 
have the DEBUG build disable optimizations?   Personally I'd expect 
debug builds in general to disable optimizations to allow easy 
source-level debugging, but it seems the decision has been made to keep 
optimizations enabled for EDK2 and have a NOOPT configuration for debugging?



--
Bruce

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

Re: [edk2] Ingebrigtsen: The End of Gmane?

[Bruce Cran]

On 9/6/16 3:25 AM, Laszlo Ersek wrote:


The gmane web interface is gone, and I'm unaware of anyone who has
picked up the archive and exposed it under the same URLs (via domain
name transfer etc). So, at the moment (to my knowledge) all our
historical gmane links are broken. Neither do I know how someone could
access edk2-devel messages that predate Mike's enablement of the
built-in  archive.


As of today, it seems a reboot is underway: 
http://home.gmane.org/2016/09/06/reboot-v1/


"I just re-enabled some of the URLs and traffic is flowing.

This rebuild is going to require an ongoing effort to bring it back to 
its former glory but we will get there shortly."


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

Re: [edk2] OVMF not booting when built with GCC5 toolset?

[Bruce Cran]

On 8/29/2016 12:45 AM, Shi, Steven wrote:

This issue is just fixed in GCC main trunk. I tried below latest GCC trunk 
version and it can pass build the edk2 with GCC5 toolset. FYI.


Thanks!

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

Re: [edk2] OVMF not booting when built with GCC5 toolset?

[Bruce Cran]

On 8/19/2016 8:35 AM, Bruce Cran wrote:
When I built and ran it using the same commands (with the exception of 
adding "-vnc :0" to the qemu cmdline) I got the same problem as 
before, and serial.log contained just:


SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78 



Sorry, I'd added -O0 to the debug build flags to let me better debug 
code. With that removed, I now get the following in serial.log:


SecCoreStartupWithStack(0x0, 0x0)
Register PPI Notify: 
Install PPI: 
Install PPI: 
The 8519680th FV start address is 0x0810248, size is 0xFFFD13C4, 
handle is 0x827F01

Register PPI Notify: 
Register PPI Notify: 
Install PPI: 
Install PPI: 
Loading PEIM at 0x000 EntryPoint=0x000 
SecCoreStartupWithStack(0x, 0xAE569B3A)
Register PPI Notify: 
SecCoreStartupWithStack(0x, 0xAE569B3A)
Register PPI Notify: 
SecCoreStartupWithStack(0x, 0xAE569B3A)
Register PPI Notify: 
SecCoreStartupWithStack(0x, 0xAE569B3A)
Register PPI Notify: 
SecCoreStartupWithStack(0x, 0xAE569B3A)
Register PPI Notify: 

Those last 2 lines repeat about 100 times.

--
Bruce

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

Re: [edk2] OVMF not booting when built with GCC5 toolset?

[Bruce Cran]

On 8/18/2016 8:08 PM, Shi, Steven wrote:

I build OVMF GCC X64 image, can boot Qemu into shell with below commands. I can 
enter shell, reconnect -r, exit to setup, and the vga display looks good to me. 
What build command did you use?
  
build -t GCC5 -a X64  -p OvmfPkg/OvmfPkgX64.dsc -n 5 -b DEBUG -DDEBUG_ON_SERIAL_PORT

qemu-system-x86_64 -bios OVMF.fd -serial file:serial.log -m 4096 -hda fat:. 
-monitor stdio -s


When I built and ran it using the same commands (with the exception of 
adding "-vnc :0" to the qemu cmdline) I got the same problem as before, 
and serial.log contained just:


SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78SecCoreStartupWithStack(0x30202C78

The version of gcc I'm using is:

gcc version 6.1.1 20160707 [gcc-6-branch revision 238088] (SUSE Linux)

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

Re: [edk2] OVMF not booting when built with GCC5 toolset?

[Bruce Cran]

On 8/18/2016 10:57 AM, Michael Zimmermann wrote:
IA32 or X64? I noticed that EmulatorPkg-X64 just produces a segfault 
when booting. IA32 works just fine. I didn't try to use GCC49 yet.


X64 - both DEBUG and RELEASE.

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

[edk2] OVMF not booting when built with GCC5 toolset?

[Bruce Cran]

I just tried building OVMF from git tip with the GCC5 toolset and the 
emulated vga display never got initialized.  Rebuilding with GCC49 worked.


Bruce

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

Re: [edk2] Build traceback with new CLANG35 toolset

[Bruce Cran]

On 8/2/2016 12:53 PM, Ard Biesheuvel wrote:


CLANG35 is not new, and currently only supports ARM and AARCH64


Oops - thanks. I was thinking of CLANG38 that hasn't been committed yet.

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

[edk2] Build traceback with new CLANG35 toolset

[Bruce Cran]

I was just testing the new GCC5 and CLANG35 toolsets that have landed in 
git master: GCC5 works perfectly, but with CLANG35 I get the following 
log and traceback:


Build environment: Linux-4.6.4-2-default-x86_64-with-SuSE-20160728-x86_64
Build start time: 12:12:40, Aug.02 2016

WORKSPACE= /mnt/user/workspace/edk2
ECP_SOURCE   = /mnt/user/workspace/edk2/EdkCompatibilityPkg
EDK_SOURCE   = /mnt/user/workspace/edk2/EdkCompatibilityPkg
EFI_SOURCE   = /mnt/user/workspace/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH   = /mnt/user/workspace/edk2/BaseTools

Architecture(s)  = X64
Build target = RELEASE
Toolchain= CLANG35

Active Platform  = /mnt/user/workspace/edk2/MyPkg/MyPkg.dsc

Processing meta-data .

build.py...
 : error C0DE: Unknown fatal error when processing 
[/mnt/user/workspace/edk2/MyPkg/MyPkg.inf]


(Please send email to edk2-devel@lists.01.org for help, attaching 
following call stack trace!)


(Python 2.7.12 on linux2) Traceback (most recent call last):
  File 
"/mnt/user/workspace/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
line 2270, in Main

MyBuild.Launch()
  File 
"/mnt/user/workspace/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
line 2022, in Launch

self._MultiThreadBuildPlatform()
  File 
"/mnt/user/workspace/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", 
line 1857, in _MultiThreadBuildPlatform

Ma.CreateMakeFile(True)
  File 
"/mnt/user/workspace/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", 
line 3923, in CreateMakeFile

if Makefile.Generate():
  File 
"/mnt/user/workspace/edk2/BaseTools/Source/Python/AutoGen/GenMake.py", 
line 184, in Generate

FileContent = self._TEMPLATE_.Replace(self._TemplateDict)
  File 
"/mnt/user/workspace/edk2/BaseTools/Source/Python/AutoGen/GenMake.py", 
line 525, in _CreateTemplateDict

RespDict = self.CommandExceedLimit()
  File 
"/mnt/user/workspace/edk2/BaseTools/Source/Python/AutoGen/GenMake.py", 
line 716, in CommandExceedLimit

Str = self._AutoGenObject._BuildOption[Tool]['FLAGS']
KeyError: 'FLAGS'

--
Bruce

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

Re: [edk2] Ingebrigtsen: The End of Gmane?

[Bruce Cran]

On 7/28/2016 1:19 PM, Andrew Fish wrote:


Seems he will send you the disks. What could go wrong?


I'm actually tempted to take him up on that offer.
Just today I went looking for information about UefiDebugLib to see if 
it was possible for a driver to print debug information to the serial 
port (or other sort of debug device) instead of the console, and came 
across the thread at
http://comments.gmane.org/gmane.comp.bios.tianocore.devel/3024 where 
thanks to Google's cache I learned that:


"The EDK used some Tiano and implementation defined protocols to support DEBUG 
and ASSERT macros. So DEBUG
and ASSERT from the EDK can only be reliably used if you compile all the EDK 
firmware together. As Liming
points out it is much safer to use a UEFI console based debug message for 
developing generic drivers and
applications."

It's a shame to lose information like that.

--
Bruce

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

Re: [edk2] Ingebrigtsen: The End of Gmane?

[Bruce Cran]

On 7/28/16 6:46 PM, Kinney, Michael D wrote:


Built-in archives for edk2-devel and edk2-bugs and now enabled.


Thanks!

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

Re: [edk2] Ingebrigtsen: The End of Gmane?

[Bruce Cran]

On 7/28/16 1:13 PM, Laszlo Ersek wrote:


The direct (and less important) issue is that we might have to find a
new archival service. And that our gmane links captured in various
places would break.


Since this ML is on Mailman, maybe Intel (i.e. owners of 01.org) can 
enable the built-in archives feature?


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

Re: [edk2] [PATCH v2] [BaseTools/Scripts]: Preserve hii section in GCC binaries

[Bruce Cran]

On 7/21/2016 1:41 PM, Palmer, Thomas wrote:

But the patch worked?


Yup - see my other email with the "Tested-by" line.
Thanks!

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

Re: [edk2] [PATCH v2] [BaseTools/Scripts]: Preserve hii section in GCC binaries

[Bruce Cran]

On 7/21/2016 9:09 AM, Laszlo Ersek wrote:

I clicked the link myself, before posting my email, and it didn't work. :)


Damn, seems I deleted it for some reason. I've created another copy at 
http://bluestop.org/edk2/docs/GccHiiResourcesBug.tgz .


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

Re: [edk2] [PATCH v2] [BaseTools/Scripts]: Preserve hii section in GCC binaries

[Bruce Cran]

On 7/20/2016 8:07 PM, Thomas Palmer wrote:

This change keeps the .hii sections in GCC built binaries.  Please
refer to email thread titled "[edk2] HII
gEfiHiiPackageListProtocolGuid problem with  GCC48 (VS2012x86 works)"


Reviewed-by: Bruce Cran 
Tested-by: Bruce Cran 

--
Bruce

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

Re: [edk2] [PATCH v2] [BaseTools/Scripts]: Preserve hii section in GCC binaries

[Bruce Cran]

On 7/21/16 6:47 AM, Laszlo Ersek wrote:


Can you guys please test this? See:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/13438


I'd forgotten I'd provided a project to replicate the problem - that's 
nice! :)


I'll try and get around to testing it later today.

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

Re: [edk2] code documentation generator?

[Bruce Cran]

On 7/21/16 8:21 AM, Michael Zimmermann wrote:


since EDK2's code is very good commented/documented, wouldn't it make sense
to support tools like doxygen to generate standalone/online documentation
like the one that once was available at phoenix?

Or is there something like that already and I just didn't see it?



I've been running doxygen over the tree every few weeks, and putting the 
results at http://bluestop.org/edk2/docs/ .


master  - http://bluestop.org/edk2/docs/trunk/
UDK2015 - http://bluestop.org/edk2/docs/UDK2015/
UDK2014.SP1 - http://bluestop.org/edk2/docs/UDK2014.SP1/
UDK2010.SR1 - http://bluestop.org/edk2/docs/UDK2010.SR1/


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

Re: [edk2] Tianocore Bugzilla Server is now live

[Bruce Cran]

On 7/20/16 4:47 PM, Kinney, Michael D wrote:


I am pleased to announce that the Bugzilla server for Tianocore
is now live and ready to be used.  The server URL is:

  https://tianocore.acgmultimedia.com


Great! Would it be possible to have a nicer URL though - something like 
"https://bugs.tianocore.org";?


--
Bruce

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

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Bruce Cran]

On 7/14/2016 4:20 PM, Laszlo Ersek wrote:


On 07/14/16 23:57, Bruce Cran wrote:


I wonder if -Os might be a better default optimization? Or perhaps
there's plenty of flash on devices nowadays and performance is more
important than size?

Beware of -Os with GCC48:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10963


Oh, good point. Also, at this point any optimization is a _huge_ 
improvement! :)


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

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

[Bruce Cran]

On 7/14/2016 7:16 AM, Ard Biesheuvel wrote:


Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to GCC44.


I wonder if -Os might be a better default optimization? Or perhaps 
there's plenty of flash on devices nowadays and performance is more 
important than size?


At least for our driver, I see a 33% size reduction with -O2 and 44% 
with -Os for the driver .efi file. Perhaps more importantly, the .rom 
file (i.e. efirom output) has no reduction with -O2 and a 14% reduction 
with -Os.


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

Re: [edk2] [Patch 1/2] MdeModulePkg: Update PXE driver to follow edk2 coding standards.

[Bruce Cran]

On 6/29/2016 8:07 PM, Fu Siyuan wrote:


-  @param  TTLThe time to live field of the IP header.
+  @param  TtlThe time to live field of the IP header.


This appears to have caused a build error:

edk2/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c: In 
function ‘PxeBcConfigureUdpWriteInstance’:
edk2/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcSupport.c:82:32: 
error: ‘TTL’ undeclared (first use in this function)

   Udp4CfgData.TimeToLive = TTL;

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

[edk2] Problem building FDF with Capsule and FmpPayload sections

[Bruce Cran]

I'm having a problem building a basic FDF file for a capsule, which 
contains the following:


[Defines]
  FDF_SPECIFICATION = 0x00010019


[FmpPayload.payload1]
IMAGE_HEADER_INIT_SECTION=0x02
IMAGE_TYPE_ID=abcdef12-abc-abcd-abcd-abcdef123456
IMAGE_INDEX=0x1
HARDWARE_INSTANCE=0x0
FILE_DATA=typeone.bin

[Capsule.FmpCapsuleImage]
CAPSULE_GUID = 6dcbd5ed-e82d-4c44-bda1-7194199ad92a # normal FMP header 
special GUID defined in UEFI spec

CAPSULE_FLAGS = PersistAcrossReset, InitiateReset
CAPSULE_HEADER_SIZE = 0x20 # normal header
CAPSULE_HEADER_INIT_VERSION = 0x1 # FMP header

FILE_DATA = driver.efi
FMP_PAYLOAD = payload1


The build system, both on master and UDK2015, generate the error:

package.fdf(6): error 3000: Invalid syntax/format
Missing keywords IMAGE_HEADER_INIT_VERSION, IMAGE_TYPE_ID, 
IMAGE_INDEX, HARDWARE_INSTANCE in FMP payload section near line 5, 
column 1: [FmpPayload.payload1]



Since the keywords _are_ there I guess I've missed something else?

--
Bruce

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

Re: [edk2] Firmware Management Protocol: CHAR16* fields in EFI_FIRMWARE_IMAGE_DESCRIPTOR

[Bruce Cran]

On 7/7/2016 2:06 PM, Andrew Fish wrote:


Probably worth brining it up with the UEFI Forum.


Thanks, I've just emailed them.

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

Re: [edk2] Firmware Management Protocol: CHAR16* fields in EFI_FIRMWARE_IMAGE_DESCRIPTOR

[Bruce Cran]

On 7/7/2016 2:27 PM, Marvin H?user wrote:


I don't think these strings can ever be statically allocated. If pointers to 
stack variables were used, the strings would be theoretically invalid the 
moment the exposing function returns. Furthermore they can't be part oft he 
struct itself as that would change the offsets of all other members after the 
string. Hence I think it can be concluded they are always dynamically allocated.
And as one can be sure they are dynamically allocated, I think it's the task of 
the function that uninstalls the protocol to free the two buffers. Should the 
protocol not be uninstalled till ExitBootServices(), it doesn't matter either 
because the OS loader may treat Boot Services code and data as free space.

Did I miss something?


They could be globals. The problem is that the memory leak occurs every 
time a FMP client calls the GetImageInfo function, and since UEFI scales 
down to small embedded systems (e.g. it runs on my credit card-sized 
HiKey board), that's a bad thing.  Elsewhere in the spec I see it called 
out who's responsible for memory management, so either I'm missing 
something or there was a mistake in this place.


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

[edk2] Firmware Management Protocol: CHAR16* fields in EFI_FIRMWARE_IMAGE_DESCRIPTOR

[Bruce Cran]

Before I go hassling the USWG, I thought I'd check here in case anyone 
knows.


In the Firmware Management Protocol introduced in UEFI 2.3, there's a 
EFI_FIRMWARE_IMAGE_DESCRIPTOR structure that has two CHAR16* fields, 
'ImageIdName' and 'VersionName'. The UEFI spec doesn't say anything 
about memory allocation, but they're strings that at least in our driver 
are dynamically allocated.


Since there's no FMP 'cleanup' function, I'm wondering if there was some 
sort of mistake specifying those, because I don't see a way to avoid 
leaking memory.


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

Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.

[Bruce Cran]

On 6/27/2016 1:25 AM, Cinnamon Shia wrote:

Let data of DXE memory status code can be used by other modules.
1. Save the address of DXE memory status code table to DxeConfigurationTable.
2. Save the address of SMM memory status code table to SmmConfigurationTable.
3. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public header file.


I'm getting an error building OVMF today, which appears related:

In file included from 
/home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/SerialStatusCodeWorker.c:15:0:
/home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h:63:3: 
error: conflicting types for ‘RUNTIME_MEMORY_STATUSCODE_HEADER’

 } RUNTIME_MEMORY_STATUSCODE_HEADER;
   ^~~~
In file included from 
/home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/StatusCodeRuntimeDxe.h:22:0,
 from 
/home/bcran/workspace/edk2/IntelFrameworkModulePkg/Universal/StatusCode/RuntimeDxe/SerialStatusCodeWorker.c:15:
/home/bcran/workspace/edk2/MdeModulePkg/Include/Guid/MemoryStatusCodeRecord.h:76:3: 
note: previous declaration of ‘RUNTIME_MEMORY_STATUSCODE_HEADER’ was here

 } RUNTIME_MEMORY_STATUSCODE_HEADER;
   ^~~~

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

Re: [edk2] Segfault in GenFw when building driver with new CLANG38 toolchain

[Bruce Cran]

On 6/28/2016 10:40 PM, Shi, Steven wrote:


OK. Could you let me know your driver code size change from GCC49 to GCC53? I 
wish GCC53 can improve it.


The change from GCC49 to GCC53 is rather good - the driver .efi file has 
reduced from 751K to 589KB.

Thanks for implementing this!

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

Re: [edk2] Segfault in GenFw when building driver with new CLANG38 toolchain

[Bruce Cran]

On 6/28/2016 10:28 PM, Shi, Steven wrote:


OK. How about GCC53?  Can GCC53 build your driver?


Yes, GCC53 works fine (the"gcc" it runs actually being gcc 6.1.1). 
Sorry, I know not having access to the driver binary will make it almost 
impossible to debug!


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

Re: [edk2] Segfault in GenFw when building driver with new CLANG38 toolchain

[Bruce Cran]

On 6/28/2016 9:51 PM, Shi, Steven wrote:


Can you build the OVMF with CLANG38 in your side?
And if possible, pls send me your driver .dll Elf image and I can try to debug 
the GenFw convert in my side.


Yes, both DEBUG and RELEASE X64 builds of OVMF complete fine.

I wish I could send the driver binaries, but I'd need to get sign-off 
from Legal, and considering the delay and work involved, I'm not sure 
it's worth it. I'll see if I can find some time to play around with 
settings etc. to see if I can see what's going wrong.


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

[edk2] Segfault in GenFw when building driver with new CLANG38 toolchain

[Bruce Cran]

After applying Steven's (cc'd) patch set and building our driver with 
the CLANG38 toolchain, GenFw crashes with a segmentation fault.  Due to 
unresolved memset and memcpy symbols, I've added the flags "-fbuiltin 
-fno-lto".


#0  0x0040bccf in WriteRelocations64 () at Elf64Convert.c:975
#1  0x00408219 in ConvertElf (FileBuffer=0x7fffde28, 
FileLength=0x7fffde24) at ElfConvert.c:207

#2  0x00405189 in main (argc=0, argv=0x7fffe098) at GenFw.c:2031


Elf64Convert.c:975:  VerboseMsg ("Relocation: 0x%08X", 
*(UINT64*)CoffFileGoTPcRelPtr);


(gdb) p CoffFileGoTPcRelPtr

$1 = (UINT64 *) 0x776f8160

(gdb) p *CoffFileGoTPcRelPtr

Cannot access memory at address 0x776f8160


--
Bruce

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

Re: [edk2] [PATCH 0/7] Introduce three new toolchains in edk2

[Bruce Cran]

On 6/28/2016 8:09 PM, Gao, Liming wrote:

   Yes. We add EFIAPI in such function, and define 
"-DEFIAPI=__attribute__((ms_abi))" in GCC CC_FLAGS.


Thanks. Unfortunately the code needs to remain portable across Windows, 
Linux and other systems, so the best solution is probably a macro 
similar to EFIAPI but which isn't specific to UEFI.


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

Re: [edk2] [PATCH 0/7] Introduce three new toolchains in edk2

[Bruce Cran]

On 6/28/16 9:18 AM, Shi, Steven wrote:

Introduce three new toolchains in edk2. The first two ones support Link Time 
Optimization (LTO) for aggressive code size improvement and the third one is 
for static analysis.

CLANG38: Enable LLVM Link Time Optimization (LTO) and code size 
optimization flag (-Os) by default for aggressive code size improvement.

> X64 code is small code model + position independent code (PIE).

One problem I've run into trying to build with clang is that we have a 
set of files which are the same across platforms, and they use varargs.


With gcc, we can just set -mabi=ms and be done with it, but it appears 
clang doesn't have that option.  Do you know of a way to set the default 
ABI with clang, or would we need to add an __attribute__((ms_abi)) 
anywhere we need to use varargs?


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

[edk2] [PATCH] ArmVirtPkg: Re-add the Driver Health Manager

[Bruce Cran]

Change-Id: I2973d251e18583531bf4579ba8dfa8101bea0939
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bruce Cran 
---
 ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
 ArmVirtPkg/ArmVirtQemu.fdf   | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.fdf | 1 +
 ArmVirtPkg/ArmVirtXen.dsc| 1 +
 ArmVirtPkg/ArmVirtXen.fdf| 1 +
 6 files changed, 6 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 8a5306b..8248fd6 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -334,6 +334,7 @@
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index ac2f1f1..d98a01c 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -167,6 +167,7 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
   INF MdeModulePkg/Application/UiApp/UiApp.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 52f1612..2fc50bd 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -310,6 +310,7 @@
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.fdf b/ArmVirtPkg/ArmVirtQemuKernel.fdf
index f6dcbc1..1229e6b 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.fdf
+++ b/ArmVirtPkg/ArmVirtQemuKernel.fdf
@@ -187,6 +187,7 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
   INF MdeModulePkg/Application/UiApp/UiApp.inf
 
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index a869986..1df751f 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -212,6 +212,7 @@
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
 
   OvmfPkg/XenBusDxe/XenBusDxe.inf
diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
index b1e00e5..ec99724 100644
--- a/ArmVirtPkg/ArmVirtXen.fdf
+++ b/ArmVirtPkg/ArmVirtXen.fdf
@@ -174,6 +174,7 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
+  INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
 
   INF OvmfPkg/XenBusDxe/XenBusDxe.inf
-- 
2.8.4

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

[edk2] [PATCH] OvmfPkg: Re-add the Driver Health Manager

[Bruce Cran]

From: Bruce Cran 

Change-Id: I7549947ccb78aa316ff9082f336a3ad32769a0c6
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bruce Cran 
---
 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 6 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 737f300..6d07464 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -563,6 +563,7 @@
   PcAtChipsetPkg/KbcResetDxe/Reset.inf
   MdeModulePkg/Universal/Metronome/Metronome.inf
   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 8bba8a6..59a4024 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -235,6 +235,7 @@ INF  
MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
 INF  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
 INF  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
 INF  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
 INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
 INF  MdeModulePkg/Application/UiApp/UiApp.inf
 INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 854cf6d..25fcb38 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -572,6 +572,7 @@
   PcAtChipsetPkg/KbcResetDxe/Reset.inf
   MdeModulePkg/Universal/Metronome/Metronome.inf
   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 73b50f5..c6167a4 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -235,6 +235,7 @@ INF  
MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
 INF  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
 INF  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
 INF  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
 INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
 INF  MdeModulePkg/Application/UiApp/UiApp.inf
 INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 0cb2f60..cb7ccf7 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -570,6 +570,7 @@
   PcAtChipsetPkg/KbcResetDxe/Reset.inf
   MdeModulePkg/Universal/Metronome/Metronome.inf
   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
   NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 1e3387f..30b0c2b 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -235,6 +235,7 @@ INF  
MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
 INF  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
 INF  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
 INF  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
+INF  MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
 INF  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
 INF  MdeModulePkg/Application/UiApp/UiApp.inf
 INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
-- 
2.8.4

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

[edk2] Driver Health HII menu missing in OVMF master

[Bruce Cran]

I just noticed that between UDK2015 and master branches in 
https://github.com/tianocore/edk2 the Driver Health display in "Device 
Manager" has disappeared.


Was its removal deliberate - has it been moved elsewhere?

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

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

[Bruce Cran]

On 6/19/16 9:21 PM, Zeng, Star wrote:


1. The memory allocate and free in PiSmmCore are SMRAM that is not related to 
UEFI memory map.
2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader should have 
got the memory map before ExitBootServices.
That means the memory free should not impact the memory map *got by UEFI OS 
loader*, it will only impact the memory map if the UEFI OS loader will call 
GetMemoryMap() again.



I just found the following post about Linux and how it calls 
ExitBootServices, which may be relevant:


http://linux-kernel.2935.n7.nabble.com/PATCH-x86-efi-retry-ExitBootServices-on-failure-td664938.html

"ExitBootServices is absolutely supposed to return a failure if any
ExitBootServices event handler changes the memory map.  Basically the
get_map loop should run again if ExitBootServices returns an error the
first time.  I would say it would be fair that if ExitBootServices gives 
an error the second time then Linux would be fine in returning control 
back to BIOS."


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

Re: [edk2] [PATCH v1 1/2] MdeModulePkg: Minimize usage of FreePool() during ExitBS().

[Bruce Cran]

On 6/19/16 9:21 PM, Zeng, Star wrote:


2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader should have 
got the memory map before ExitBootServices.
That means the memory free should not impact the memory map *got by UEFI OS 
loader*, it will only impact the memory map if the UEFI OS loader will call 
GetMemoryMap() again.


But aren't boot services supposed to be unavailable during 
ExitBootServices? So regardless of whether the memory map should or 
should not be changed, it's possible that gBS is NULL and so it's not 
possible to call gBS->FreePool?


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

Re: [edk2] [PATCH 0/2] Update UNIXGCC toolchain and make it work again

[Bruce Cran]

On 6/17/16 3:18 PM, Laszlo Ersek wrote:


Given that neither your blurb subject says OvmfPkg, nor was I CC'd as
OvmfPkg co-maintainer, in general I would have blissfully slid over your
email. However, in Thunderbird's threaded view, I noticed that Jordan
responded, which made me slightly curious, and I started reading your
email. That's when I found the OVMF mention at the bottom, and saw the
OvmfPkg/ paths in the diffstat.


This is one of the advantages of having a tool which manages reviews - 
the ability to specify people who should automatically be CC'd on review 
requests given a specified path in the source tree :)


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

Re: [edk2] [Patch 2/2] NetworkPkg: Stop the timer before clean IP service.

[Bruce Cran]

On 6/1/16 7:55 PM, Wu, Jiaxin wrote:


Thanks for your catching, I will check my git email setting.


Sorry, it was actually meant for Siyuan.

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

Re: [edk2] [Patch 2/2] NetworkPkg: Stop the timer before clean IP service.

[Bruce Cran]

On 5/25/16 7:04 PM, Fu Siyuan wrote:

In Ip6CleanService()it first cleaned some resources, then stop the timer .
While before the timer stopped it may try to access some already freed
data, which may generate an exception.
This patch updates the driver to stop the timer event before starting to
clean up the service data.

Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Subramanian Sriram 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 


I'm seeing strange "authored by" data in your changesets. For example, in:

NetworkPkg: Stop the timer before clean IP service.
5c944a654a68

Authored by Fu, Siyuan Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=sfu5> on Wed, 
May 25, 7:04 PM.


Could you check your git email setting please?

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

Re: [edk2] [RFC V2] Proposal to organize packages into directories

[Bruce Cran]

On 5/26/2016 4:53 PM, Andrew Fish wrote:

2) Pthreads is not directly supported in Windows. This could also be worked 
around with 3rd party software.


The standard solution for pthreads on Windows is pthreads-win32: 
https://www.sourceware.org/pthreads-win32/


--
Bruce

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

Re: [edk2] [PATCH] [Vlv2TbltDevicePkg] Update the core version string to UEFI 2.50.

[Bruce Cran]

On 5/18/2016 7:35 PM, Wei, David wrote:


I am OK with this patch.

Reviewed-by: zwei4  


I don't see it in the list of changesets on the UDK2015 branch yet (i.e. 
https://github.com/tianocore/edk2/commits/UDK2015).

Do you know when it will be committed?

--
Bruce


-Original Message-
From: Bruce Cran [mailto:br...@cran.org.uk]
Sent: Thursday, May 19, 2016 3:27 AM
To: edk2-devel@lists.01.org
Cc: He, Tim ; Wei, David 
Subject: Re: [edk2] [PATCH] [Vlv2TbltDevicePkg] Update the core version string 
to UEFI 2.50.

Since the MBMAX firmware is now being built against the UDK2015 branch,
the 'Core Version' string in PlatformSetupDxe should be updated to UEFI
2.50.

Obviously, this patch should be applied to the UDK2015 branch.


On 05/18/2016 01:24 PM, Bruce Cran wrote:

Also, see
https://github.com/bcran/edk2/commit/349b5ee989a876457e65176556a164a1825531d5
.


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

Re: [edk2] [RFC] Email tags for Bugzilla and administrative events

[Bruce Cran]

On 5/23/2016 12:33 PM, Mangefeste, Tony wrote:

3. The server URL is (https://tianocore.acgmultimedia.com).  At this time I'd 
like to ask all maintainers to please logon and create an account.  I will use 
this information to assign package maintainers to specific security groups, 
email and such.


It should probably be updated to v5.0.3 before going live 
(https://www.bugzilla.org/releases/5.0.3/release-notes.html).


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

Re: [edk2] [PATCH] [MdePkg/BaseLib]: Remove overreaction to SourceLen in StrCpyS

[Bruce Cran]

On 5/18/2016 10:00 AM, Thomas Palmer wrote:

I will publicly speculate that most uses/users of StrCpyS expect it
to copy as much of the source string as possible instead of
ASSERT'ing or returning an error (and copying nothing) when the
source string is longer than the destination buffer.  If the source
length copied must be limited, the developer should choose StrnCpyS
instead where the source length limit can be explicitly stated.


Exactly! I was unhappy when I recently discovered the current behavior.

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

Re: [edk2] [PATCH] [Vlv2TbltDevicePkg] Update the core version string to UEFI 2.50.

[Bruce Cran]

Since the MBMAX firmware is now being built against the UDK2015 branch, 
the 'Core Version' string in PlatformSetupDxe should be updated to UEFI 
2.50.


Obviously, this patch should be applied to the UDK2015 branch.


On 05/18/2016 01:24 PM, Bruce Cran wrote:
Also, see 
https://github.com/bcran/edk2/commit/349b5ee989a876457e65176556a164a1825531d5 
.

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

[edk2] [PATCH] [Vlv2TbltDevicePkg] Update the core version string to UEFI 2.50.

[Bruce Cran]

Also, see 
https://github.com/bcran/edk2/commit/349b5ee989a876457e65176556a164a1825531d5 
.




>From 349b5ee989a876457e65176556a164a1825531d5 Mon Sep 17 00:00:00 2001
From: Bruce Cran 
Date: Wed, 18 May 2016 13:22:46 -0600
Subject: [PATCH] [Vlv2TbltDevicePkg] Update the core version string to UEFI
 2.50.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bruce Cran 
---
 Vlv2TbltDevicePkg/PlatformSetupDxe/VfrStrings.uni | Bin 214666 -> 214666 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/Vlv2TbltDevicePkg/PlatformSetupDxe/VfrStrings.uni b/Vlv2TbltDevicePkg/PlatformSetupDxe/VfrStrings.uni
index 144579aa2c5d5f2946a0fff2fc14a261d78f3e10..44c864facee4f7ef2250e7944963ce9321a0adcc 100644
GIT binary patch
delta 28
hcmeC`___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg RamDiskDxe: Fix wrong HII behavior for more than 8 RAM disks

[Bruce Cran]

On 4/20/2016 5:10 AM, Laszlo Ersek wrote:


On 04/20/16 07:57, Hao Wu wrote:

The RamDiskDxe driver originally uses a variable-length HII varstore to
retrieve the HII checkbox status of each registered RAM disk.

could you please test this patch, for
?


Sorry for the delay. I've just tested it and it works great and fixes 
issue 81.


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

Re: [edk2] OVMF: hang when booting Linux via GRUB after driver allocates 2GB above 4GB

[Bruce Cran]

On 4/19/16 6:04 AM, Laszlo Ersek wrote:


Bruce, could you please test this? If 742563777e8d is indeed the
solution, I will file an RHBZ (for the RHEL kernel) to backport it.



Laszlo, I've just verified that 742563777e8d does indeed fix the 
problem: that kernel successfully boots after the memory allocation, 
whereas 3625c2c234ef66acf21a72d (the commit before it) just reboots. I 
checked that _without_ the memory allocation, that kernel also boots fine).


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

Re: [edk2] OVMF: hang when booting Linux via GRUB after driver allocates 2GB above 4GB

[Bruce Cran]

On 4/19/2016 6:04 AM, Laszlo Ersek wrote:


Bruce, could you please test this? If 742563777e8d is indeed the
solution, I will file an RHBZ (for the RHEL kernel) to backport it.


Will do. Thanks for all your work on this!

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

Re: [edk2] OVMF: hang when booting Linux via GRUB after driver allocates 2GB above 4GB

[Bruce Cran]

On 4/18/16 8:36 AM, Laszlo Ersek wrote:


BTW, what happens if you boot UEFI Windows (i.e., 8+) in your VM? Does
it boot?


Yes, Windows 10 (build 1511) boots fine, as does OpenSUSE with kernel 
4.5.0.  That being the case, I'll file a bug with the CentOS tracker.


By the way, when I fetch the memory map (gBS->GetMemoryMap) in the 
optrom driver's entrypoint, it only reports 4GB RAM (therefore it makes 
sense that your AllocatePages call would fail); by the time its 
BindingStart function is called, however, it reports the full 16GB.


That's where I was allocating the 2GB at 6GB (in BindingStart), but I've 
now adapted the Hello application from AppPkg to do the allocation 
instead, to get vfio out of the way and let me just run an application 
to allocate the memory.


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

Re: [edk2] OVMF: hang when booting Linux via GRUB after driver allocates 2GB above 4GB

[Bruce Cran]

On 4/16/16 7:08 PM, Bruce Cran wrote:


Jumping to kernel EFI handover point at ofs 30
ConvertPages: Incompatible memory types


And doing some more digging including learning how to get debug output 
from the early kernel stages, Linux is getting quite some way through 
before hanging.  I've attached the boot log.


I've tried adding "efi=debug,noruntime" but disable use of runtime 
services doesn't have any effect on the hang.


--
Bruce Cran
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.10.0-327.13.1.el7.x86_64 
(buil...@kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) 
(GCC) ) #1 SMP Thu Mar 31 16:04:38 UTC 2016
[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.10.0-327.13.1.el7.x86_64 
root=/dev/mapper/centos-root ro crashkernel=auto rd.lvm.lv=centos/root 
rd.lvm.lv=centos/swap rhgb debug earlyprintk=efi,keep ignore_loglevel core 
efi=debug uefi_debug console=ttyS0 LANG=en_US.UTF-8
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009] usable
[0.00] BIOS-e820: [mem 0x0010-0x007f] usable
[0.00] BIOS-e820: [mem 0x0080-0x00807fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x00808000-0x0080] usable
[0.00] BIOS-e820: [mem 0x0081-0x008f] ACPI NVS
[0.00] BIOS-e820: [mem 0x0090-0xbe9a1fff] usable
[0.00] BIOS-e820: [mem 0xbe9a2000-0xbe9a2fff] reserved
[0.00] BIOS-e820: [mem 0xbe9a3000-0xbe9c2fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbe9c3000-0xbe9ecfff] reserved
[0.00] BIOS-e820: [mem 0xbe9ed000-0xbeda6fff] usable
[0.00] BIOS-e820: [mem 0xbeda7000-0xbee12fff] reserved
[0.00] BIOS-e820: [mem 0xbee13000-0xbfe92fff] usable
[0.00] BIOS-e820: [mem 0xbfe93000-0xbfeeafff] reserved
[0.00] BIOS-e820: [mem 0xbfeeb000-0xbfef2fff] ACPI data
[0.00] BIOS-e820: [mem 0xbfef3000-0xbfef6fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbfef7000-0xbffc] usable
[0.00] BIOS-e820: [mem 0xbffd-0xbffe] reserved
[0.00] BIOS-e820: [mem 0xbfff-0xbfff] usable
[0.00] BIOS-e820: [mem 0xffe0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00043fff] usable
[0.00] debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] e820: update [mem 0xbe95d018-0xbe9a0857] usable ==> usable
[0.00] extended physical RAM map:
[0.00] reserve setup_data: [mem 0x-0x0009] 
usable
[0.00] reserve setup_data: [mem 0x0010-0x007f] 
usable
[0.00] reserve setup_data: [mem 0x0080-0x00807fff] 
ACPI NVS
[0.00] reserve setup_data: [mem 0x00808000-0x0080] 
usable
[0.00] reserve setup_data: [mem 0x0081-0x008f] 
ACPI NVS
[0.00] reserve setup_data: [mem 0x0090-0xbe95d017] 
usable
[0.00] reserve setup_data: [mem 0xbe95d018-0xbe9a0857] 
usable
[0.00] reserve setup_data: [mem 0xbe9a0858-0xbe9a1fff] 
usable
[0.00] reserve setup_data: [mem 0xbe9a2000-0xbe9a2fff] 
reserved
[0.00] reserve setup_data: [mem 0xbe9a3000-0xbe9c2fff] 
ACPI NVS
[0.00] reserve setup_data: [mem 0xbe9c3000-0xbe9ecfff] 
reserved
[0.00] reserve setup_data: [mem 0xbe9ed000-0xbeda6fff] 
usable
[0.00] reserve setup_data: [mem 0xbeda7000-0xbee12fff] 
reserved
[0.00] reserve setup_data: [mem 0xbee13000-0xbfe92fff] 
usable
[0.00] reserve setup_data: [mem 0xbfe93000-0xbfeeafff] 
reserved
[0.00] reserve setup_data: [mem 0xbfeeb000-0xbfef2fff] 
ACPI data
[0.00] reserve setup_data: [mem 0xbfef3000-0xbfef6fff] 
ACPI NVS
[0.00] reserve setup_data: [mem 0xbfef7000-0xbffc] 
usable
[0.00] reserve setup_data: [mem 0xbffd-0xbffe] 
reserved
[0.00] reserve setup_data: [mem 0xbfff-0xbfff] 
usable
[0.00] reserve setup_data: [mem 0xffe0-0x] 
reserved
[0.00] reserve setup_data: [mem 0x0001-0x00043fff] 
usable
[0.00] efi: EFI v2.60 by EDK II
[0.00] efi:  SMBIOS=0xbedd6000  ACPI=0xbfef2000  ACPI 2.0=0xbfef2014 
[0.00] efi: mem

Re: [edk2] OVMF: hang when booting Linux via GRUB after driver allocates 2GB above 4GB

[Bruce Cran]

On 4/16/16 1:28 PM, Bruce Cran wrote:

On 4/16/16 12:28 PM, Laszlo Ersek wrote:


Then boot the guest again, as you would normally do (including your
driver in OVMF), just pass the above triplet with the -kernel / -initrd
/ -append options.


With a debug OVMF build, I get some possibly useful information on the 
debug console. At one point, the following gets printed:


ConvertPages: failed to find range 18000 - 1F000

The last messages to be printed before the system hangs, are:

Reading kernel image ...Select item 0x11
 [done]
Select Item: 0x14
Select Item: 0x15
Select Item: 0x8
Initrd size: 0x1C68B0F
Reading initrd image ...Select Item 0x12
 [done]
Jumping to kernel EFI handover point at ofs 30
ConvertPages: Incompatible memory types

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

Re: [edk2] OVMF: hang when booting Linux via GRUB after driver allocates 2GB above 4GB

[Bruce Cran]

On 4/16/16 12:28 PM, Laszlo Ersek wrote:


Then boot the guest again, as you would normally do (including your
driver in OVMF), just pass the above triplet with the -kernel / -initrd
/ -append options.


So, without the driver loaded booting Linux directly works fine: however 
with the driver loaded the boot process hangs. So I guess we've just 
ruled out the bug being in GRUB.


--
Bruce Cran

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

[edk2] OVMF: hang when booting Linux via GRUB after driver allocates 2GB above 4GB

[Bruce Cran]

I've been trying to debug a problem I've come across when booting Linux 
(CentOS 7) under OVMF (it happens with master, UDK2015 and UDK2014.SP1): 
if a driver allocates a couple of GB memory above 4GB, then the boot 
process hangs: e.g. on a VM with plenty of RAM (16GB):


EFI_PHYSICAL_ADDRESS addr = 0x18000;
gBS->AllocatePages(AllocateAddress, EfiBootServicesData, 0x8, &addr);

GRUB calls ExitBootServices, and at that point since the console goes 
away I don't know what happens - but Linux never boots.  Before loading 
GRUB the memory map looks fine, so I have no idea what's going wrong.


I don't know if it's a bug in OVMF or GRUB, so I've created the ticket 
in GRUB's bugtracker https://savannah.gnu.org/bugs/?47711 and thought it 
might also be worth posting here, too.


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

[edk2] OVMF build failure due to missing CommonMacros.inc

[Bruce Cran]

I just pulled the latest code from git master and the OVMF build is 
failing because ResetVector.nasmb tries to include CommonMacros.inc and 
can't find it.


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

Re: [edk2] [Patch] NetworkPkg: fix function comments in HttpBootDxe.

[Bruce Cran]

On 3/10/16 7:49 PM, Zhang, Lubo wrote:

Reviewed-by: Zhang, Lubo 

-Original Message-
From: Fu, Siyuan
Sent: Thursday, March 10, 2016 10:10 AM
To: edk2-devel@lists.01.org
Cc: Wu, Jiaxin ; Zhang, Lubo 
Subject: [Patch] NetworkPkg: fix function comments in HttpBootDxe.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
Cc: Wu Jiaxin 
Cc: Zhang Lubo 


It looks like your git configuration might be wrong: instead of your 
email address you seem to have some Exchange information in the changeset.


Authored:
Zhang, Lubo 
Tue, Mar 8, 11:20 PM
Committed:
Jiaxin WuThu, Mar 10, 8:55 PM

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

Re: [edk2] EDK2 Staging Repository

[Bruce Cran]

On 3/10/16 9:55 AM, Mangefeste, Tony wrote:

This is fantastic, because the other two things I would like for us all to 
consider is Gerrit+Jenkins support.


Why Gerrit?  Everyone I've seen talk about it hate its UI.

FWIW I seem to be leading a bit of a rebellion at $work, since I setup a 
demo Phabricator instance (for the repo browser and code review) and 
most people love it, to the extent that they're saying they wish we'd 
used it from the start and wondering if any engineers were involved in 
the decision to use the tool that we're supposed to be using.


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

Re: [edk2] EDK2 Staging Repository

[Bruce Cran]

On 3/9/16 2:59 PM, Jordan Justen wrote:


So far I have a setup that can test building BaseTools and OVMF on
Linux. The Windows setup is a little more complicated, but I don't
think it should be too difficult.


I guess that's Linux x86_64? Any solution we come up with should also be 
extendable to AARCH64.


--
Bruce

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

Re: [edk2] EDK2 Staging Repository

[Bruce Cran]

On 3/9/16 11:53 AM, Mangefeste, Tony wrote:

Below are the details of the proposal for a staging branch, please review and 
comment.



Problem statement
=
Need place on tianocore.org where new features that are not ready for product
integration can be checked in for evaluation by the EDK II community prior to
adding to the edk2 trunk.  This serves several purposes:

* Encourage source code to be shared earlier in the development process
* Allow source code to be shared that does not yet meet all edk2 required 
quality criteria
* Allow source code to be shared so the EDK II community can help finish and 
validate new features
* Provide a location to hold new features until they are deemed ready for 
product integration
* Provide a location to hold new features until there is a natural point in 
edk2 release cycle to fully validate the new feature.
* Not intended to be used for bug fixes.
* Not intended to be used for small, simple, or low risk features.


Possibly related but for future work, I played around with setting up a 
Jenkins server so people could build-test their patches on various 
platforms/architectures but it turned out to be too expensive for me to 
run on AWS so I took it down. I wonder if this is something we could 
consider setting up for the staging area at some point?


--
Bruce

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

[edk2] Unable to allocate more than 2GB memory on AMI-based UEFI implementations

[Bruce Cran]

I've been troubleshooting a problem recently on AMI-based systems where 
they won't allocate more than about 2GB memory using AllocatePool and 
AllocatePages(AllocateAnyAddress, ...) functions. I've just written a 
page about it (https://edk2.bluestop.org/w/allocatingmemoryabove2gb/) 
and was wondering if anyone else had come across it, and perhaps knew if 
there's a better workaround/fix than using 
AllocatePages(AllocateAddress, ...) after doing a lookup in the memory map?


The worst thing about it is that I appear to have broken 2 ASUS Z170 
motherboards from running into this problem!


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

Re: [edk2] Task: Issue Tracking System for Tianocore

[Bruce Cran]

On 2/10/16 5:57 PM, Jordan Justen wrote:

On 2016-02-10 16:21:33, Mangefeste, Tony wrote:

GitHub doesn't allow for data import/export or report generation as


They have an API that should allow for this:

https://developer.github.com/v3/issues/


much as I'd like to stick with the GitHub issue management, and
other limitations that will be pushed as we grow in GitHub usage.



What other limitations?


By the way, in case people haven't seen it Github replied to an open 
letter complaining about the Issues limitations: 
https://github.com/dear-github/dear-github


"Dear Open Source Maintainers,

We hear you and we're sorry. We've been slow to respond to your letter 
and slow to respond to your frustrations.


We're working hard to fix this. Over the next few weeks we'll begin 
releasing a number of improvements to Issues, many of which will address 
the specific concerns raised in the letter. But we're not going to stop 
there. We'll continue to focus on Issues moving forward by adding new 
features, responding to feedback, and iterating on the core experience. 
We've also got a few surprises in store.


Issues haven't gotten much attention from GitHub these past few years 
and that was a mistake, but we've never stopped thinking about or caring 
about you and your communities. However, we know we haven't communicated 
that. So in addition to improving Issues, we're also going to kick off a 
few initiatives that will help give you more insight into what's on our 
radar. We want to make sharing feedback with GitHub less of a black box 
experience and we want to hear your ideas and concerns regularly.


We'll be in touch next week. Sorry it's taken so long, and thank you for 
everything.


—GitHub"

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

Re: [edk2] Suggested wiki updates

[Bruce Cran]

On 2/15/16 4:31 AM, Laszlo Ersek wrote:


The trick is that github doesn't allow you to fork *only* a wiki. It can
only create a wiki for a project that exists already.

So, you should choose:

(1) Follow the instructions on this page, from start to finish:

http://www.tianocore.org/site/


Ah, thanks. I think I'll work on getting all this into Wordpress instead!

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

[edk2] Suggested wiki updates

[Bruce Cran]

Since I can't figure out how to submit changes to the wiki, I've noticed 
a few pages at least that should probably be updated:


https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues 
still mentions Trac and Sourceforge.


https://github.com/tianocore/tianocore.github.io/wiki/Source-Control 
needs updated.


https://github.com/tianocore/tianocore.github.io/wiki/2013-Subversion-Change 
can probably be deleted since it's obsolete.


https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-git-svn 
looks to be obsolete.


https://github.com/tianocore/tianocore.github.io/wiki/Test

https://github.com/tianocore/tianocore.github.io/wiki/test2

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

Re: [edk2] git history breakage [was: ShellPkg: ShellFileHandleReadLine must return UCS2 lines]

[Bruce Cran]

On 2/11/16 6:34 AM, Laszlo Ersek wrote:


I think we managed to reconstruct what happened here. I recommend that
you open the git history in gitk, so you can jump on the commits I'm
about to mention.


By the way, you can also see the divergence and merging in the branching 
view at https://edk2.bluestop.org/diffusion/EDK/history/master/ .


--
Bruce

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

Re: [edk2] Task: Issue Tracking System for Tianocore

[Bruce Cran]

On 2/10/16 7:08 PM, Mangefeste, Tony wrote:

BTW, I will start experimenting with it myself in the coming days setting up a 
virtual server, so I'll know better myself.


https://wiki.mozilla.org/Bugzilla seems to have lots of information 
about Bugzilla, including 
https://wiki.mozilla.org/Bugzilla:FAQ#How_much_time_does_it_take_to_install_and_maintain_Bugzilla.3F


"Someone with a lot of Bugzilla experience can get you up and running in 
a few hours, and your Bugzilla install can run untended for years. 
Less-experienced administrators sometimes need a few days to set up 
Bugzilla."


--
Bruce

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

Re: [edk2] Task: Issue Tracking System for Tianocore

[Bruce Cran]

On 2/10/16 5:58 PM, Mangefeste, Tony wrote:

Yes, the funding for a service (like Bugzilla) is not at present time a 
concern.  But we're still investigating and modeling out what it will take to 
use it, and of course if it turns out to be unjustifiable, we'll find something 
else (including using GitHub issue tracking).


Could an instance of bugzilla be hosted on tianocore.org if necessary? I 
presume tianocore.org is a dedicated Linux server somewhere that someone 
has root privileges on, and could probably be maintained by volunteers 
if we don't have sufficient sysadmins already?


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

Re: [edk2] Task: Issue Tracking System for Tianocore

[Bruce Cran]

On 2/10/16 4:08 PM, Laszlo Ersek wrote:


I am (was?) subscribed to a minimal set of CARDs only, in the first
system; I don't have any real experience with JIRA. Ard, Leif, can you
please share your thoughts?


We use JIRA at work, and I was the admin for a few years. It's big, 
complex, and not something I think we'd want to use with an open source 
project.  But then again the installation I was managing had around 100 
projects and 1000 users, so it might not be representative for a single, 
simpler project.


Bitbucket uses a simplified version of it, which can be seen at 
https://confluence.atlassian.com/bitbucket/use-the-issue-tracker-221449750.html 
.


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

Re: [edk2] Task: Issue Tracking System for Tianocore

[Bruce Cran]

On 2/10/16 3:59 PM, Mangefeste, Tony wrote:

I've gone down the track of using Bugzilla as well.  Aside from the massive 
list of pros listed below, gathering any other preference is welcomed.  I have 
used Bugzilla, but never been a maintainer on it.  We do have some resources 
lined up for management of Bugzilla, if needed, so that's not a barrier.  Of 
course, the devil's in the details.

So in short, Bugzilla is top of my mind right now.  I'm looking at other OSS 
projects and seeing what they use.  If anyone here sees one not listed below or 
has an opinion that they care to express please do so.  On the mobility view, 
I'll try to play around with that and see how it looks on my mobile devices.



I'm currently hosting a mirror of the edk2 repo at 
https://edk2.bluestop.org/diffusion/EDK/ - Phabricator has a bug/task 
tracker module Maniphest that looks rather capable - 
https://phacility.com/phabricator/maniphest/ .


I just think it's a shame we've lost so many bugs by telling people to 
report them to the mailing list for a couple of years, so any issue 
tracker is good at this point!


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

Re: [edk2] Transition to GitHub Update

[Bruce Cran]

On 1/15/16 2:14 PM, Jarlstrom, Laurie wrote:

To: EDK II Community

This message is an update on the transition from SourceForge to GitHub for EDK 
II development.  The schedule is currently targeting the last week of January 
or the first week of February to perform the transition.  The transition 
process should only take one to two days to complete.  A notification message 
will be sent the week prior to the actual dates that the repositories will be 
impacted.  This should provide adequate notification for the scheduled down 
time.
As part of this transition some documentation and process changes have been 
required.  The updated process as well as other GitHub specific information can 
be found on the tianocore Wiki at the link provided below.  Feedback on this 
documentation is welcome and needed to make sure the transition is as smooth as 
possible.

https://github.com/tianocore/tianocore.github.io/wiki/SourceForge-to-Github-Quick-Start

Please post any comments or questions related to this transition to the 
edk2-devel mailing list or reply to the email message.


It might be good to mention that people can use "git send-email" to send 
a patch to the mailing list.


--
Bruce

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

Re: [edk2] Git transition for EDK2

[Bruce Cran]

On 12/3/15 5:37 PM, Jordan Justen wrote:


I think some people want to investigate gerrit at some point, and I
don't know how that would be implemented. I hope it would not mean
that patches will be posted in gerrit, and no notice will appear on
the email list.


I hope not too, since everyone I've talked to has said that Gerrit's UI 
is rather ugly :)


--
BRuce

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

Re: [edk2] Vlv2TbltDevicePkg/GenBiosId binary

[Bruce Cran]

On 11/25/15 1:34 AM, Jordan Justen wrote:


Also, why is Vlv2TbltDevicePkg 14MB, and more than 65% of that is
binaries?

We moved a large chunk of binaries out of BaseTools/Bin a while back,
and this seems like a similar situation. I think these binaries don't
belong in the EDK II source code tree. Is there any way these items
could be overlayed into the tree from elsewhere if needed?


I thought the binaries had been deleted from the tree, but maybe that 
was only on the UDK2014.SP1 branch? At least on master, there's a 3.7MB 
file Vacant.bin:


muon% hd -C Vlv2TbltDevicePkg/Stitch/IFWIHeader/Vacant.bin
  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||
  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff 
||

*
003bf000

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

Re: [edk2] Vlv2TbltDevicePkg/GenBiosId binary

[Bruce Cran]

On 11/24/15 3:03 PM, Jordan Justen wrote:


I wonder why this binary exists in EDK II without source code.

I also notice that Vlv2TbltDevicePkg/GenBiosId is a 32-bit ELF
executable. What if someone wanted to build Vlv2TbltDevicePkg on X64
and they didn't have 32-bit userspace available?


I took a look at the output of GenBiosId a few months ago and seem to 
recall there wasn't anything that looked especially complex. If it came 
to it, I suspect the contents could easily be updated with a hex editor 
to be valid.


--
Bruce

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

Re: [edk2] edk2 Bug tracking - help fixing issues

[Bruce Cran]

On 11/7/15 7:22 AM, Rafael Machado wrote:


Is there any place where I can check the issues and try to help solving
them ?


Bugs are currently reported on this mailing list, so you'd need to look 
through the archive to find them.  Also the old mailing list archive at 
https://lists.sourceforge.net/lists/listinfo/edk2-devel .


There's also https://github.com/tianocore/edk2/issues but I'm not sure 
how active it is.


--
Bruce

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

Re: [edk2] C Coding Standards Specification disappeared

[Bruce Cran]

On 11/4/15 9:44 AM, Jarlstrom, Laurie wrote:

The Previous C Coding Standards Guide is currently being updated.  A new 
revision will be posted shortly.


Could someone post that information on the website please?

By 'website' I guess I mean both the sourceforge _and_ github wikis, 
since for some reason they're both active.



--
Bruce

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

Re: [edk2] C Coding Standards Specification disappeared

[Bruce Cran]

On 11/3/15 8:12 PM, Sheng, Cecil (HPS SW) wrote:


The "EDK II C Coding Standards Specification v2" listed on 
http://tianocore.sourceforge.net/wiki/EDK_II_User_Documentation cannot be found.  Is it 
moved to another place or ?


It may have been removed because it's fairly ancient (2008) and listed 
as a draft document - but if you still want to read it I managed to save 
a copy at 
http://www.bluestop.org/edk2/docs/specs/EDK2_C_Coding_Standards_Specification.pdf 
.


Other documents are available at http://www.bluestop.org/edk2/docs (and 
edk2 API documentation for UDK2014 SP1 is at 
http://www.bluestop.org/edk2/docs/UDK2014.SP1/ .


--
Bruce

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

Re: [edk2] [Patch] BaseTools: Allow decimal values in the EDK II meta-data file.

[Bruce Cran]

On 11/2/15 10:00 PM, Yonghong Zhu wrote:

Because the EDK II meta-data specifications already allow using decimal
values in the EDK II Meta-data file [Defines] section, this patch update
code to allow this usage.


By the way, "metadata" is a single word so no hyphen is needed.

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

Re: [edk2] [PATCH v3 01/52] UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU detected

[Bruce Cran]

On 10/20/15 7:14 PM, Kinney, Michael D wrote:


That looks like a new bug, and it is in the new code I added to force BSP to 
wait for all APs to enter sleeping state before StartupAllAPs() is called.

How did you reproduce this?


I'm running the following command to start OVMF (qemu-system-x86_64 was 
built a few weeks ago, from git master), and I hit the ASSERT about 50% 
of the time (the problem being that LockValue is a huge number like 
1234567890):


LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
/home/bcran/bin/qemu-system-x86_64 -name uefi -M q35 \
 -m size=16384 -smp 4 -cpu host \
 -drive 
unit=0,if=pflash,format=raw,file=/home/bcran/workspace/edk2/Build/OvmfX64/DEBUG_GCC49/FV/OVMF.fd 
\
  -drive 
file=/home/bcran/uefi.img,id=mydisk,aio=native,if=ide,media=disk,cache=none,format=raw 
\

  -nodefaults -realtime mlock=off \
  -enable-kvm -s -S -rtc base=utc -monitor stdio -vnc :0 -vga std \
  -chardev pty,id=debugcon -device 
isa-debugcon,chardev=debugcon,iobase=0x402 \
-device 
vfio-pci,host=02:00.0,id=mypcicard,romfile=/home/bcran/workspace/edk2/MyPciCardPkg/stage/DEBUG_GCC49/X64/my_pci_card.rom


The only change I make when building OVMF is to include 
DebugPkg/GdbSyms/GdbSyms.inf in OvmfPkgX64.dsc to allow me to use gdb.


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

Re: [edk2] [PATCH v3 01/52] UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU detected

[Bruce Cran]

On 10/14/15 4:25 PM, Laszlo Ersek wrote:

From: Michael Kinney 

When only 1 CPU is detected and the max CPUs is greater than 1,
an ASSERT() is generated because the pages associated with the
AP stack have already been freed.  Only do this FreePages() call
if there is more than 1 CPU detected.


Is the ASSERT() that was being triggered "LockValue == ((UINTN) 2) || 
LockValue == ((UINTN) 1)" in:


  AcquireSpinLockOrFail
  GetMpSpinLock
  TestCpuStatusFlag
  CheckAllAPsSleeping
  InitializeMpSupport
  InitializeCpu
  …

Or is this a separate bug?

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

Re: [edk2] Driver Health Protocol, UI interaction and Intel DQ77MK vs. OVMF

[Bruce Cran]

On 10/8/15 9:04 PM, Ni, Ruiyu wrote:


OVMF used the old IntelFrameworkModulePkg/BDS.
The new MdeModulePkg/BDS automatically invokes the reparation upon boot.
I did a draft patch
(http://article.gmane.org/gmane.comp.bios.edk2.devel/759) but do not
have time to edit it to follow the review comments.
I may not have time to do it in this year. If it's urgent to you, you
can try this draft patch. It will be great if you can help to edit the
patch and get it reviewed and checked in to the OVMF Pkg.


Ah, thanks!
So currently if a device is required to boot, I guess the driver would 
need to automatically initiate the repair operation during the load 
process?   The card I'm working with is unfortunately rather easy to get 
into a state where a repair is needed; so it sounds as though I might 
need to wait until UEFI 2.6 or so until it will be safe to assume that 
the platform will automatically initiate a repair?


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

[edk2] Driver Health Protocol, UI interaction and Intel DQ77MK vs. OVMF

[Bruce Cran]

I have a controller which implements the Driver Health Protocol. Under 
OVMF (built from latest edk2 master), when the controller isn't healthy 
I can go into the 'Device Manager' menu, click the 'Some drivers are not 
healthy' entry and on clicking the unhealthy controller it gets repaired.


I'm wondering if anyone knows if this is recent behavior or if a bug was 
fixed, since on my Intel DQ77MK system I have a similar menu, except 
labeled "TPV EFI Device Manager" - but when I click the "Some drivers 
are not healthy" item the screen just refreshes back to the same page 
and nothing happens.


I had also expected that if I selected a boot item that resides on the 
unhealthy controller, the repair operation would get invoked and upon it 
returning a healthy status the OS would boot. But that doesn't seem to 
be the case.


Can anyone tell me what I'm misunderstanding please?

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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Bruce Cran]

On 9/24/15 4:43 AM, Laszlo Ersek wrote:


First, I don't see why I should change my workflow (including CLI tools
I use interactively) that I've been using for almost five years now. I'm
using the most basic, most widely available tools: "raw" git commands,
and email.


I thought you'd also currently need to use svn too, since the repository 
is hosted on SF? Anyway, I don't think anyone's saying that existing 
workflows will have to change. Anyone who likes using current tools will 
still be able to, and since the ML is one of the best ways to archive 
discussions, I agree that if we introduce a web app it must send 
notifications to the list.


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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Bruce Cran]

On 9/24/15 1:38 AM, Laszlo Ersek wrote:


I can promise right now that I *will not* use Gerrit, or any other
web-based tool, to review or otherwise handle patches. Sorry.

Othes are welcome to do so, of course, but I only work with patches via
email and git fetch / git push. I'll only see others' reviews made in a
web-based tool if that tool posts the reviews (in a reasonable message
format) to the list.


So you wouldn't even use a command-line interface to a web-based tool 
that has commands to manage patches? For example "cr list" to show 
outstanding reviews, and "cr land" to push a review that has been 
approved to source control.


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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Bruce Cran]

On 9/23/15 8:26 PM, Jordan Justen wrote:


I think there is about a good chance that
https://github.com/tianocore/edk2 will become the primary upstream
location for EDK II by the end of the year.

I agree with you that we should just take the easy/obvious path and
use https://github.com/tianocore/edk2/issues for issues once we are
sure that we are moving to github hosting.


Great - thanks.

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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Bruce Cran]

On 9/14/15 11:15 PM, Bruce Cran wrote:

On 9/14/15 11:13 PM, Josh Triplett wrote:


Whether running a standalone system or a hosted service, I don't think
it makes sense to use one completely separate from code hosting.  If
you're using github for code, it makes sense to use github for issues;
if you were using Phabricator for code review and maintenance, then
using it for issues makes sense.


Agreed. For me, the nice thing about Phabricator is that it can either
host or mirror both Git and SVN repositories.

But if people would prefer to use Github then I'd be happy with that
too, just as long as there's *some* way to track bugs that isn't an
email archive!


Ping? Should we set up test systems of either/both and see which people 
prefer? Or do we need a "benevolent dictator" to just make a decision 
and have people implement it?


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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Bruce Cran]

On 9/14/15 11:13 PM, Josh Triplett wrote:


Whether running a standalone system or a hosted service, I don't think
it makes sense to use one completely separate from code hosting.  If
you're using github for code, it makes sense to use github for issues;
if you were using Phabricator for code review and maintenance, then
using it for issues makes sense.


Agreed. For me, the nice thing about Phabricator is that it can either 
host or mirror both Git and SVN repositories.


But if people would prefer to use Github then I'd be happy with that 
too, just as long as there's *some* way to track bugs that isn't an 
email archive!


--
Bruce

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

Re: [edk2] EDK II bug/issue tracking - was: OVMF/Xen, Debian wheezy can't boot with NX on stack

[Bruce Cran]

On 9/14/15 4:20 PM, Jordan Justen wrote:


If we wanted to run a dedicated server, it seems like bugzilla has a
longer track record.


Well volunteered!


But, personally, running a server for bugzilla seems like a hassle.
Let's assume we figure out a long term plan to pay for it. We still
have to handle all the admin issues of backing it up, dealing with
crashes, dealing with people trying to crack or crash the server,
etc...


Heh, to me it's just another service to run. I already deal with running 
a mail server (with all the stuff like greylisting, DKIM, SPF, spam 
filtering etc.) with secure submission, IMAP server, Jenkins and a 
standard web server. So, in comparison Phabricator/Bugzilla etc. seems 
fairly simple!


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