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

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 threa

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

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

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

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 C

[edk2] GenFv error 3000 building OvmfPkg X64 RELEASE

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

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

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 &#x

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

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 En

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

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

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] [PATCH] Add NOOPT build targets to OvmfPkg for source level debugging

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

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

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

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

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 DE

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

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

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

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) symbol

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

(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/OvmfP

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

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 f

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

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

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

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

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

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(0x30202C78SecCoreStartu

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

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 DEB

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

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 e

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

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

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:/

[edk2] Build traceback with new CLANG35 toolset

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

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

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

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

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?

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 archive

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

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

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

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

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

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

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 ___

Re: [edk2] code documentation generator?

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

Re: [edk2] Tianocore Bugzilla Server is now live

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.tiano

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

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.gman

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

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

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

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 ‘PxeBcC

[edk2] Problem building FDF with Capsule and FmpPayload sections

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.

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

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

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 wo

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

ec 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

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

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

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

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 ___

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

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 ___

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

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

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

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 #

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

o 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

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] [PATCH] ArmVirtPkg: Re-add the Driver Health Manager

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

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

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

[edk2] Driver Health HII menu missing in OVMF master

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

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

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 im

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

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

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

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,

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

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.

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 cl

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

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

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

ssage- 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 b

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

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

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

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

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

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

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

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

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 ?

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

r 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.0

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

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

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

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

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

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&#x

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

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

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

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

e 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] OVMF build failure due to missing CommonMacros.inc

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/ma

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

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: Ti

Re: [edk2] EDK2 Staging Repository

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

Re: [edk2] EDK2 Staging Repository

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 t

Re: [edk2] EDK2 Staging Repository

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

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

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 wonde

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

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 m

Re: [edk2] Suggested wiki updates

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, th

[edk2] Suggested wiki updates

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/Sour

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

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.b

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

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/Bugzil

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

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 usin

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

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 s

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

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 manag

Re: [edk2] Transition to GitHub Update

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 transitio

Re: [edk2] Git transition for EDK2

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'v

Re: [edk2] Vlv2TbltDevicePkg/GenBiosId binary

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

Re: [edk2] Vlv2TbltDevicePkg/GenBiosId binary

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

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

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.n

Re: [edk2] C Coding Standards Specification disappeared

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 som

Re: [edk2] C Coding Standards Specification disappeared

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 list

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

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 _

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

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_6

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

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. I

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

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

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

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

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

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 curren

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

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'

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

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/

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

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

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

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 revi

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

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

  1   2   >