Re: [edk2] [RFC PATCH 0/4] unify GCC command line options

On 8/12/15 11:47 PM, Gao, Liming wrote: Add -std=gnu89 to the CC flags. This is the default for gcc 4.x, so it doesn't change anything for those tool chains (other than making the command line slightly longer). GCC5 however, defaults to -std=gnu11. By adding -std=gnu89, gcc5 will behave

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

On 8/18/2015 10:26 AM, Ard Biesheuvel wrote: Ultimately, it would be useful to have a subset of platforms/toolchains that need to pass before a patch is accepted, but I am aware that we are still far away from anything like that. For internal use, I have set up some infrastructure that we can

Re: [edk2] [PATCH] Vlv2DeviceRefCodePkg: don't redefine struct typedefs

On 7/27/2015 11:39 PM, He, Tim wrote: Yes, these 2 typedefs is being defined twice, we need to remove the second definition, I will check in the code patch. Thanks. Just to check, how long is there normally between accepting the patch and committing it? I don't see any of my recent

[edk2] OVMF: iasl Control Method should be made Serialized

With iasl version 20150410-64 building OvmfX64 (using OvmfPkg/build.sh -a X64 -t GCC49 -b RELEASE) results in a couple of warnings about methods that should be serialized: iasl -p/home/bcran/workspace/edk2/Build/OvmfX64/RELEASE_GCC49/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.aml

Re: [edk2] TianoCore Subversion down?

On 7/22/2015 4:18 AM, Laszlo Ersek wrote: How about someone creates a temporary branch off the github master branch, and applies all new patches from the list that have been reviewed thus far? Then once SVN is back up, the patches from that git branch could be committed to SVN by a single

Re: [edk2] [PATCH] Vlv2DeviceRefCodePkg: don't redefine struct typedefs

On 7/16/15 8:39 AM, Bruce Cran wrote: I'm guessing this is because TortoiseGit uses MinGW, which from my experience has quite a few bugs like this. At least on my system running the same command in the Git Bash shell from https://git-scm.com/downloads works. Could you try that please? Hi Tim

Re: [edk2] Intel ITP-XDP with Tunnel Mountain and EDK2?

On 7/25/15 11:47 AM, Gray, Zachary C wrote: Tunnel Mountain is OK but it is a bit old (by Intel standards) If you are looking for a small target for UEFI research purposes I *strongly* recommend the MinnowBoard Max. This target has a freely available firmware that is mostly public, you can

Re: [edk2] TianoCore Subversion down?

On 7/24/15 5:40 PM, Jordan Justen wrote: Unfortunately, it looks like they are going to manage to get svn back up and running. ;) It looks like it's back: http://sourceforge.net/blog/sourceforge-subversion-svn-service-online/ SourceForge-hosted Allura-backed Subversion (SVN) repositories

Re: [edk2] TianoCore Subversion down?

On 7/19/15 4:01 AM, Ard Biesheuvel wrote: I'd suggest that we just promote the GitHub repository to primary repository, and deprecate the public SVN right away. I am happy to help out handling any of the fallout that may result, although I should mention I will be off from work this Tuesday.

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] 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

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

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

[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] [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

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

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

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

On 9/14/15 1:39 PM, Laszlo Ersek wrote: I never used the Issues pages (as anything other than a non-logged in lurker). But, if it resembles their code view etc pages, I think I'll be in trouble. Hotkeys in a browser... Brrr. It's just too heavy-weight for a browser. I can't say I'm much of a

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

On 9/14/15 1:19 PM, Jordan Justen wrote: I think the bug tracker on sf got shut down when sf stopped supporting their 'hosted services'. (Ie, for example, when they shut down the hosted mediawiki service.) It got broken when SF changed their URLs. I asked about it back then but nobody seemed

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

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

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

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

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] [PATCH] [Vlv2TbltDevicePkg] Update the core version string to UEFI 2.50.

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 <tim...@intel.com>; Wei, David <david@intel.com> Subject: Re: [edk2] [PATCH] [Vlv2TbltDevicePkg] Update the core version string to

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

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

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] 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

[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

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

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

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

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,

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

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

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

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] [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]

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

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

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

[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 <bruce.c...@gmail.com> Date: Wed, 18 May 2016 13:22:46 -0600 Subject: [PATCH] [Vlv2TbltDevicePkg] Update

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 ?

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

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

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

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.

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

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

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

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

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

[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/mailman

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 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.gmane.org

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 <bruce.c...@gmail.com> Teste

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

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

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] 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

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

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

From: Bruce Cran <bruce.c...@gmail.com> Change-Id: I7549947ccb78aa316ff9082f336a3ad32769a0c6 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bruce Cran <bruce.c...@gmail.com> --- OvmfPkg/OvmfPkgIa32.dsc| 1 + OvmfPkg/OvmfPkgIa32.fdf| 1 + OvmfPkg/OvmfPk

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

Change-Id: I2973d251e18583531bf4579ba8dfa8101bea0939 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bruce Cran <br...@cran.org.uk> --- ArmVirtPkg/ArmVirtQemu.dsc | 1 + ArmVirtPkg/ArmVirtQemu.fdf | 1 + ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 + ArmV

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

ust 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-de

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] [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

[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] 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

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

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] 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

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

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] 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

[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] [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

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

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

hu <yonghong@intel.com> Reviewed-by: Bruce Cran <bruce.c...@gmail.com> Tested-by: Bruce Cran <bruce.c...@gmail.com> 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 wit

[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

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

[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

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] [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)

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

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

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

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

[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] 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

[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

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

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

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 'h') at /home

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

Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu <yonghong@intel.com> Tested-by: Bruce Cran <bruce.c...@sandisk.com> Tested with GCC49 and GCC5 toolchain builds and verified neither causes gdb single-stepping to jump around. -- Bruce ___

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

From ef7b3dfe26bb7748d838974af57cd73e40e24c94 Mon Sep 17 00:00:00 2001 From: Bruce Cran <bruce.c...@sandisk.com> 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