Re: [edk2] Is edk2 broken for linux GCC Compile ?

[Laszlo Ersek]

On 09/03/15 05:42, Shubha Ramani wrote:
> I grabbed the latest code from github, See below. But it seems like linux 
> stuff is missing. I see CYGWIN_NT-5.1-i686 and Darwin-i386 under 
> BaseTools/Bin. Is the gitrepo just not updated ? It seems really old and I 
> see nothing related to Linux.
> I'm trying to build EDK2 on Ubuntu 14.04.  I follow the instructions on the 
> web and they're just not working, mainly because "Linux" build is missing. 
> Please advise !

If your point is that Linux binaries are not tracked by SVN / git,
that's intentional; you have to build them first.

$ source edksetup.sh
$ make -C "$EDK_TOOLS_PATH"

Then you can use the "build" utility (it is on your PATH after sourcing
"edksetup.sh") to build various platforms.

Laszlo

> Thanks Shubha tianocore/edk2
> |   |
> |   |  |   |   |   |   |   |
> | tianocore/edk2edk2 - EDK II |
> |  |
> | View on github.com | Preview by Yahoo |
> |  |
> |   |
> 
> 
> Shubha D. ramanishubharam...@gmail.com
> shubharam...@yahoo.com
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

[edk2] "Using Python to investigate EFI and ACPI"

[Laszlo Ersek]

Hi Josh,

I just found the LWN.net article with the title in the subject:

  http://lwn.net/SubscriberLink/655992/04701db2bbb7e716/

("Thank you LWN", of course. :))

This got me kind of excited. In your presentation, according to the
article, you were using KVM and OVMF to showcase the ACPI features of
"BITS". Further, in

  http://biosbits.org/scripting/

you write, "You can also find arbitrary ACPI objects by path, and
evaluate arbitrary ACPI methods, with the return value decoded into a
Python object".

I'm excited because for virtualization we might have the reverse use
case: use BITS to test / debug / develop the ACPI generator of QEMU. :)

As you may now, QEMU generates almost all of its ACPI tables
dynamically, providing the guest with an "ACPI payload" that describes
the actual virtual hardware as accurately as possible.

Then this payload is passed to the guest firmware (SeaBIOS or OVMF) over
"fw_cfg" (which is a simple protocol, comprising, at this point, one
selector and one data register, which are IO ports or MMIO locations --
see "docs/specs/fw_cfg.txt" in QEMU and
"Documentation/devicetree/bindings/arm/fw-cfg.txt" in the kernel).

The guest firmware downloads the "ACPI payload" over fw_cfg, does some
generic processing on them (we call this the "ACPI linker/loader
script"), and ultimately installs the ACPI tables in a way that is
appropriate for the firmware in question.

To be more concrete, the tables you investigated in your presentation
with BITS were generated (very roughly) by the following files in QEMU:

  hw/acpi/aml-build.c
  hw/acpi/bios-linker-loader.c
  hw/acpi/...
  hw/i386/acpi-build.c

and processed and installed by the following source file in edk2:

  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c

With this background, you can probably see where I'm going with this. It
is not really easy to *test* the AML methods that QEMU generates
(piecing them together, with helper functions, from AML primitives),
without dedicated guest kernel drivers. I think the only method that I
know of is the following:

- in the Linux guest, dump the ACPI tables with acpidump, or save them
from sysfs directly (/sys/firmware/acpi/tables)
- pass the DSDT and the SSDTs (and any data tables referenced by them?)
to AcpiExec from the ACPICA suite
- work with AcpiExec

But, for simple testing, can we maybe run your tool within the guest,
before the runtime OS boots?

Although AcpiDump is being ported to edk2:

  http://thread.gmane.org/gmane.comp.bios.edk2.devel/1109

I'm unsure if it will be able to evaluate / execute AML methods. (If it
parallels the "acpidump" utility we have on GNU/Linux distros, it won't.)

Thus it would be awesome if we had some AcpiExec-like functionality
early on in the guest (for example in the form of a UEFI Shell
application, or as a python tool that runs within the edk2 Python port,
or even in grub).

For example, assume your runtime guest OS is Windows (with its picky,
closed-source ACPI interpreter); you make a change in QEMU's ACPI
generator, rebuild QEMU, reboot the guest, drop to the UEFI shell to
verify the change "by eye", exit the shell, and *then* continue booting
Windows. (Which will hopefully not BSOD at that point, after the
verification with BITS / AcpiExec etc.)

So, I have three questions:

(1) What is the relationship between the ACPI facility of BITS, and ACPICA?

(2) Is there a bit more comprehensive documentation about the ACPI
module of BITS? AcpiExec and the ACPICA Debugger have quite indulged me
with their incredible documentation (documents/acpica-reference.pdf). It
would be great if BITS' ACPI module had a list of commands, to see what
is there to play with.

(3) I should mention that QEMU generates ACPI also for arm/aarch64
virtual machines ("hw/arm/virt-acpi-build.c" in QEMU), and the same edk2
module as noted above (built for arm/aarch64) does the guest side
processing. Do you think it's possible to use BITS in arm/aarch64 VMs?

... I apologize if tools / documentation already exist for this kind of
development work; everyone please educate me then. I hope my questions
make at least some sense; I realize this email isn't well organized.

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

Re: [edk2] "Using Python to investigate EFI and ACPI"

[Laszlo Ersek]

Side point:

On 09/03/15 11:16, Laszlo Ersek wrote:
> 
> I just found the LWN.net article with the title in the subject:
> 
>   http://lwn.net/SubscriberLink/655992/04701db2bbb7e716/
> 
> ("Thank you LWN", of course. :))

I've just been advised in private, well-meaningly, that I shouldn't post
LWN Subscriber Links publicly.

I did that consciously. The notice on LWN's Subscriber Link generator
page is *not* lost on me; however, Jonathan Corbet has previously
publicly approved such *occasional* posting:

https://www.reddit.com/r/linux/comments/2lfhh8/kdbus_meets_linuxkernel_lwnnet/clumuze

I thought making this one article publicly readable "early" was (a)
basis for this discussion, (b) showcasing the value of LWN's journalism
(ie. "advertisment").

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

[edk2] UEFI requirements for 32-bit Windows 8.1?

[Laszlo Ersek]

Hi,

64-bit Windows 8.1 boots on QEMU + OVMF just fine. (The "pc" (i440fx)
machine type of QEMU has "always" worked, and we recently fixed "q35" too.)

However, 32-bit Windows 8.1 (ie. the installer of it) crashes with a
BSoD on the 32-bit build of OVMF *immediately*. This happens regardless
of the QEMU machine type. The error message I'm getting is:

http://people.redhat.com/~lersek/windows-on-ovmf32/win8-ovmf32.png

According to ,
the error code 0xc185 means "STATUS_IO_DEVICE_ERROR".

I also tried with Windows 10:

http://people.redhat.com/~lersek/windows-on-ovmf32/win10-ovmf32.png

Here I get 0xc00d, "STATUS_INVALID_PARAMETER".

The Windows ISOs I tried with were:
- en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso
- en_windows_10_enterprise_2015_ltsb_n_x86_dvd_6848317.iso

Can someone please help me debug this? The difference between x64 and
x86 is "inexplicable".

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

Re: [edk2] UEFI requirements for 32-bit Windows 8.1?

[Brian J. Johnson]

On 09/03/2015 05:08 AM, Laszlo Ersek wrote:

Hi,

64-bit Windows 8.1 boots on QEMU + OVMF just fine. (The "pc" (i440fx)
machine type of QEMU has "always" worked, and we recently fixed "q35" too.)

However, 32-bit Windows 8.1 (ie. the installer of it) crashes with a
BSoD on the 32-bit build of OVMF *immediately*. This happens regardless
of the QEMU machine type. The error message I'm getting is:

http://people.redhat.com/~lersek/windows-on-ovmf32/win8-ovmf32.png

According to ,
the error code 0xc185 means "STATUS_IO_DEVICE_ERROR".

I also tried with Windows 10:

http://people.redhat.com/~lersek/windows-on-ovmf32/win10-ovmf32.png

Here I get 0xc00d, "STATUS_INVALID_PARAMETER".

The Windows ISOs I tried with were:
- en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso
- en_windows_10_enterprise_2015_ltsb_n_x86_dvd_6848317.iso

Can someone please help me debug this? The difference between x64 and
x86 is "inexplicable".


I've worked through some firmware issues on older MS releases, but never 
Windows 8 or 10.  So this advice may be out of date.  Do you know if 
Windows got through the boot loader and is starting the kernel?  If so, 
you can turn on extra debug messages to show the drivers as they are 
loading.  That can give you some good clues.  If that's not enough, you 
can enable remote debugging and use MS's debuggers (eg. WinDbg) and 
symbol tables to get an idea of the call chain which is failing.  It's 
been a long time since I've done this, so I'm rusty on the specifics... 
searching on msdn.microsoft.com should get you going.


Historically, Windows has been extremely picky about ACPI tables, much 
more so than Linux.  Boot issues often have to do with ACPI details.  It 
has also had some quirks re. what it expects in the EFI memory map, 
although those have mostly related to really large systems (eg. PCIe 
segment layout.)


I see you CC'd some folks at Microsoft.  Hopefully they will be able to 
give you more specific advice.

--

Brian J. Johnson



  My statements are my own, are not authorized by SGI, and do not
  necessarily represent SGI’s positions.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] "Using Python to investigate EFI and ACPI"

[Laszlo Ersek]

On 09/03/15 16:50, Josh Triplett wrote:
> On Thu, Sep 03, 2015 at 11:16:40AM +0200, Laszlo Ersek wrote:
>> Hi Josh,
>>
>> I just found the LWN.net article with the title in the subject:
>>
>>   http://lwn.net/SubscriberLink/655992/04701db2bbb7e716/
>>
>> ("Thank you LWN", of course. :))
>>
>> This got me kind of excited. In your presentation, according to the
>> article, you were using KVM and OVMF to showcase the ACPI features of
>> "BITS". Further, in
>>
>>   http://biosbits.org/scripting/
> 
> (Note: that page is badly out of date, by a couple of years, and we need
> to drop it in favor of the various more recent presentations.  All of
> that functionality still exists, but we have an interactive Python REPL
> now, and the ACPI methods have moved to the "acpi" module and become
> easier to use.)
> 
>> you write, "You can also find arbitrary ACPI objects by path, and
>> evaluate arbitrary ACPI methods, with the return value decoded into a
>> Python object".
> 
> Right.  In particular, you can call acpi.get_objpaths to list the ACPI
> tree, and acpi.evaluate to evaluate an arbitrary method.
> 
>> I'm excited because for virtualization we might have the reverse use
>> case: use BITS to test / debug / develop the ACPI generator of QEMU. :)
> 
> Awesome.  Unit testing and CI for QEMU sounds like an ideal use case for
> BITS.
> 
>> As you may now, QEMU generates almost all of its ACPI tables
>> dynamically, providing the guest with an "ACPI payload" that describes
>> the actual virtual hardware as accurately as possible.
> 
> Many BIOSes do that, since the hardware configuration may vary at
> runtime.
> 
>> Then this payload is passed to the guest firmware (SeaBIOS or OVMF) over
>> "fw_cfg" (which is a simple protocol, comprising, at this point, one
>> selector and one data register, which are IO ports or MMIO locations --
>> see "docs/specs/fw_cfg.txt" in QEMU and
>> "Documentation/devicetree/bindings/arm/fw-cfg.txt" in the kernel).
> 
> Interesting; I hadn't seen that protocol before.
> 
> Do you virtualize those I/O ports by CPU, to make them thread-safe, or
> does the last address written to 0x510 get saved system-wide, making it
> unsafe for concurrent access?

I think fw_cfg is not meant to be accessed by several CPUs concurrently.
The protocol is stateful (selected key, offset within blob associated
with selected key, etc), and "accessing CPU" is not part of that state.

> 
>> The guest firmware downloads the "ACPI payload" over fw_cfg, does some
>> generic processing on them (we call this the "ACPI linker/loader
>> script"), and ultimately installs the ACPI tables in a way that is
>> appropriate for the firmware in question.
>>
>> To be more concrete, the tables you investigated in your presentation
>> with BITS were generated (very roughly) by the following files in QEMU:
>>
>>   hw/acpi/aml-build.c
>>   hw/acpi/bios-linker-loader.c
>>   hw/acpi/...
>>   hw/i386/acpi-build.c
>>
>> and processed and installed by the following source file in edk2:
>>
>>   OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c
>>
>> With this background, you can probably see where I'm going with this. It
>> is not really easy to *test* the AML methods that QEMU generates
>> (piecing them together, with helper functions, from AML primitives),
>> without dedicated guest kernel drivers. I think the only method that I
>> know of is the following:
>>
>> - in the Linux guest, dump the ACPI tables with acpidump, or save them
>> from sysfs directly (/sys/firmware/acpi/tables)
>> - pass the DSDT and the SSDTs (and any data tables referenced by them?)
>> to AcpiExec from the ACPICA suite
>> - work with AcpiExec
>>
>> But, for simple testing, can we maybe run your tool within the guest,
>> before the runtime OS boots?
> 
> Yes, absolutely.  We have a batch-mode testing mechanism based on a
> config file; you'd probably want to make use of that.  With some
> extensions, it could dump results either to an emulated serial port or
> some other interface that you can read from outside qemu.  We also need
> to work on making the results more machine-parseable for automation.

While I certainly don't discount automation, my primary use case is
interactive development / testing. :) (Although, I can see myself
canning some commands in a script or config file, and invoking *that*
interactively. Which was your point, probably.)

> 
>> Although AcpiDump is being ported to edk2:
>>
>>   http://thread.gmane.org/gmane.comp.bios.edk2.devel/1109
>>
>> I'm unsure if it will be able to evaluate / execute AML methods. (If it
>> parallels the "acpidump" utility we have on GNU/Linux distros, it won't.)
> 
> Probably not.  And I haven't heard of any plans to port acpiexec to
> EDK2.
> 
>> Thus it would be awesome if we had some AcpiExec-like functionality
>> early on in the guest (for example in the form of a UEFI Shell
>> application, or as a python tool that runs within the edk2 Python port,
>> or even in grub).
>>
>> For example, assume your runtime guest OS is Win

Re: [edk2] "Using Python to investigate EFI and ACPI"

[Laszlo Ersek]

On 09/03/15 17:57, Moore, Robert wrote:
> 
> 
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, September 03, 2015 8:54 AM
>> To: Josh Triplett
>> Cc: edk2-devel-01; qemu devel list; Michael Tsirkin; Igor Mammedov; Marcel
>> Apfelbaum; Paolo Bonzini; Shannon Zhao; Moore, Robert; Smith, Jonathan D;
>> Jake Edge
>> Subject: Re: "Using Python to investigate EFI and ACPI"
>>
>> Another question: when you execute an AML method that does, say, IO port
>> access, does the AML interpreter of ACPICA actually *perform* that IO port
>> access? Because, the one that is embedded in Linux obviously does, and the
>> one that is embedded in the userspace ACPICA command line utility
>> "acpiexec" obviously doesn't.
> 
> We have recently integrated the ACPICA AML debugger with the Linux kernel,
> and we have a userspace utility that allows communication with the debugger.
> This allows the user to enter debugger commands such as "execute control 
> method",
> and the commands are carried out by the kernel code -- thus talking to the
> actual hardware.

... Was it merged in commit c91c5b276b? The series at
? Or is that "only" a followup
series to the main work?

Can you please provide a pointer to the userspace tool as well?

This thread is getting better and better. :)

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

Re: [edk2] [PATCH] ArmPlatformPkg: signal EndOfDxe event in PlatformBsdInit

[Leif Lindholm]

On Tue, Sep 01, 2015 at 04:26:07PM +0200, Ard Biesheuvel wrote:
> Like the ArmVirtPkg platforms up until SVN r17713, the ArmPlatformPkg
> platforms built with the Intel BDS fail to signal the end-of-DXE event
> 'gEfiEndOfDxeEventGroupGuid' when entering the BDS phase, which results
> in some loss of functionality, i.e., variable reclaim in the VariableDxe
> drivers, and the splitting of the memory regions that is part of the recently
> added UEFI 2.5 properties table feature.
> 
> As discussed on the edk2-devel mailing list here:
> 
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16109
> 
> it is up to the platform BDS to signal that event, since there may be
> platform specific ordering constraints with respect to the signalling
> of the event that are difficult to honor at the generic level.
> 
> So add the SignalEvent () call to PlatformBdsInit () of ArmPlatformPkg's
> PlatformBdsLib implementation for the Intel BDS.

Naïve, and perhaps silly question/comment:
ArmVirtPkg, and this patch, both call this from PlatformBdsInit(),
whereas OvmfPkg does it from PlatformBdsPolicyBehavior().

The difference is the following segment in
IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c
which gets executed before signalling EndOfDxeEvent in OvmfPkg, but
not for Arm*:
---
  //
  // Set up the device list based on EFI 1.1 variables
  // process Driver and Load the driver's in the
  // driver option list
  //
  BdsLibBuildOptionFromVar (&DriverOptionList, L"DriverOrder");
  if (!IsListEmpty (&DriverOptionList)) {
BdsLibLoadDrivers (&DriverOptionList);
  }
  //
  // Check if we have the boot next option
  //
  mBootNext = BdsLibGetVariableAndSize (
L"BootNext",
&gEfiGlobalVariableGuid,
&BootNextSize
);
---

and the code at the start of Ovmf's PlatformBdsPolicyBehavior():
---
  VisitAllInstancesOfProtocol (&gEfiPciRootBridgeIoProtocolGuid,
ConnectRootBridge, NULL);

  //
  // We can't signal End-of-Dxe earlier than this. Namely, End-of-Dxe triggers
  // the preparation of S3 system information. That logic has a hard dependency
  // on the presence of the FACS ACPI table. Since our ACPI tables are only
  // installed after PCI enumeration completes, we must not trigger the S3 save
  // earlier, hence we can't signal End-of-Dxe earlier.
  //
---

Does the above not apply for any ArmPlatformPkg platforms (or others
importing ArmPlatformPkg's PlatformIntelBdsLib)?
If so, is this also not applicable to virtio-pci in ArmVirtPkg?

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  | 36 
> 
>  ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h  |  1 +
>  ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf |  1 +
>  3 files changed, 38 insertions(+)
> 
> diff --git a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c 
> b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
> index 98d5b277a636..e27e6d66df91 100644
> --- a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
> +++ b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
> @@ -31,6 +31,24 @@ PlatformIntelBdsConstructor (
>return EFI_SUCCESS;
>  }
>  
> +/**
> +  An empty function to pass error checking of CreateEventEx ().
> +
> +  @param  Event Event whose notification function is being 
> invoked.
> +  @param  Context   Pointer to the notification function's 
> context,
> +which is implementation-dependent.
> +
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +EmptyCallbackFunction (
> +  IN EFI_EVENTEvent,
> +  IN VOID *Context
> +  )
> +{
> +}
> +
>  //
>  // BDS Platform Functions
>  //
> @@ -45,6 +63,24 @@ PlatformBdsInit (
>VOID
>)
>  {
> +  EFI_EVENT   EndOfDxeEvent;
> +  EFI_STATUS  Status;
> +
> +  //
> +  // Signal EndOfDxe PI Event
> +  //
> +  Status = gBS->CreateEventEx (
> +  EVT_NOTIFY_SIGNAL,
> +  TPL_CALLBACK,
> +  EmptyCallbackFunction,
> +  NULL,
> +  &gEfiEndOfDxeEventGroupGuid,
> +  &EndOfDxeEvent
> +  );
> +  if (!EFI_ERROR (Status)) {
> +gBS->SignalEvent (EndOfDxeEvent);
> +gBS->CloseEvent (EndOfDxeEvent);
> +  }
>  }
>  
>  STATIC
> diff --git a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h 
> b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h
> index 7122d58be7d7..da428288fb9f 100644
> --- a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h
> +++ b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h
> @@ -30,5 +30,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  #include 
>  
>  #include 
> +#include 
>  
>  #end

Re: [edk2] "Using Python to investigate EFI and ACPI"

[josh]

On Thu, Sep 03, 2015 at 05:53:45PM +0200, Laszlo Ersek wrote:
> On 09/03/15 16:50, Josh Triplett wrote:
> > On Thu, Sep 03, 2015 at 11:16:40AM +0200, Laszlo Ersek wrote:
> >> Then this payload is passed to the guest firmware (SeaBIOS or OVMF) over
> >> "fw_cfg" (which is a simple protocol, comprising, at this point, one
> >> selector and one data register, which are IO ports or MMIO locations --
> >> see "docs/specs/fw_cfg.txt" in QEMU and
> >> "Documentation/devicetree/bindings/arm/fw-cfg.txt" in the kernel).
> > 
> > Interesting; I hadn't seen that protocol before.
> > 
> > Do you virtualize those I/O ports by CPU, to make them thread-safe, or
> > does the last address written to 0x510 get saved system-wide, making it
> > unsafe for concurrent access?
> 
> I think fw_cfg is not meant to be accessed by several CPUs concurrently.
> The protocol is stateful (selected key, offset within blob associated
> with selected key, etc), and "accessing CPU" is not part of that state.

Not that hard to fix; just keep all the state in the accessing CPU
rather than the system.  Current processors do that for the PCI I/O port
pair, to avoid race conditions.  You could easily do that for the fw_cfg
I/O ports.  As a bonus, you then wouldn't need to take any kind of lock
around accesses to that state, because the CPU owns that state.

(That's the easy fix; the harder fix would be creating a new race-free
MMIO protocol and mapping all of the data structures into memory
directly, which would provide a performance benefit as well.  I'd love
to see a general version of such a protocol for a more efficient virtio
filesystem, though in the simpler case of fw_cfg you can just map all of
the structures into memory.)

> >> With this background, you can probably see where I'm going with this. It
> >> is not really easy to *test* the AML methods that QEMU generates
> >> (piecing them together, with helper functions, from AML primitives),
> >> without dedicated guest kernel drivers. I think the only method that I
> >> know of is the following:
> >>
> >> - in the Linux guest, dump the ACPI tables with acpidump, or save them
> >> from sysfs directly (/sys/firmware/acpi/tables)
> >> - pass the DSDT and the SSDTs (and any data tables referenced by them?)
> >> to AcpiExec from the ACPICA suite
> >> - work with AcpiExec
> >>
> >> But, for simple testing, can we maybe run your tool within the guest,
> >> before the runtime OS boots?
> > 
> > Yes, absolutely.  We have a batch-mode testing mechanism based on a
> > config file; you'd probably want to make use of that.  With some
> > extensions, it could dump results either to an emulated serial port or
> > some other interface that you can read from outside qemu.  We also need
> > to work on making the results more machine-parseable for automation.
> 
> While I certainly don't discount automation, my primary use case is
> interactive development / testing. :) (Although, I can see myself
> canning some commands in a script or config file, and invoking *that*
> interactively. Which was your point, probably.)

Interactive development and testing is even easier; you can do that
today.  And yes, if you find yourself doing the same thing repeatedly,
you should put it in a module you can run.  Turning the results into an
automated regression test would be even better. :)

> >> Thus it would be awesome if we had some AcpiExec-like functionality
> >> early on in the guest (for example in the form of a UEFI Shell
> >> application, or as a python tool that runs within the edk2 Python port,
> >> or even in grub).
> >>
> >> For example, assume your runtime guest OS is Windows (with its picky,
> >> closed-source ACPI interpreter); you make a change in QEMU's ACPI
> >> generator, rebuild QEMU, reboot the guest, drop to the UEFI shell to
> >> verify the change "by eye", exit the shell, and *then* continue booting
> >> Windows. (Which will hopefully not BSOD at that point, after the
> >> verification with BITS / AcpiExec etc.)
> >>
> >> So, I have three questions:
> >>
> >> (1) What is the relationship between the ACPI facility of BITS, and ACPICA?
> > 
> > BITS links in ACPICA and uses it to evaluate ACPI.  We pull in ACPICA as
> > a git submodule and build it as part of BITS.  acpi.evaluate uses the
> > ACPICA interpreter.
> 
> Awesome! :)
> 
> Another question: when you execute an AML method that does, say, IO port
> access, does the AML interpreter of ACPICA actually *perform* that IO
> port access? Because, the one that is embedded in Linux obviously does,
> and the one that is embedded in the userspace ACPICA command line
> utility "acpiexec" obviously doesn't.

You need to pass unsafe_io=True to evaluate, in which case it'll do I/O.
Otherwise, it'll ignore I/O.  (On our TODO list: ignoring but logging
I/O so we can look at the I/O accesses as part of the test.)

Actually, that reminds me: we should probably fix AcpiOsWriteMemory to
do the same thing.

> I assume (and very much hope) that the IO port acces

Re: [edk2] UEFI requirements for 32-bit Windows 8.1?

[Blibbet]

NT-centric post follows, slightly off-topic:

On 09/03/2015 08:51 AM, Brian J. Johnson wrote:
> On 09/03/2015 05:08 AM, Laszlo Ersek wrote:
...
> I see you CC'd some folks at Microsoft.  Hopefully they will be able
to give you more specific advice.

For low-level NT issues, I'd also recommend the ntdev mailing list,
hosted by OSR. Years ago, it was nt...@atria.com, then IBM bought Atria,
these decades OSR hosts the mailing list (and also has a newsgroup and
web forum UI).  OSR is a group of NT driver consultants, the main
consultants for file system drivers. Last time I checked, this list was
best place to go for NT kernel-mode issues (as an alternative to the
trad. tech support mechanisms). Unlike most other online forums, some
Microsoft driver developers participate on this list (and some of them
are good at forwarding relevant issues to appropriate Microsofties who
are not subscribed), as well as all of the NT driver consultants, so a
lot of smart NT people there. You'll need to subscribe to post.
http://www.osronline.com/page.cfm?name=ListServer
https://www.osronline.com/showlists.cfm?list=ntdev
http://www.osronline.com/cf.cfm?PageURL=showlists.cfm?list=NTDEV

Warning: not much pro-Linux tolerance there, thanks to a long-time
troll, so trim off as much non-NT issues as possible for best results.

In the past, not much UEFI-centric experience there, but it was growing,
as was NT's dependence on it, so I expect there is more now.
https://www.google.com/?gws_rd=ssl#q=EFI+ntdev+site:osronline.com

If you run Windows, after installing the Microsoft-acquired SysInternals
tools, OSR's freeware tools are the second batch of tools to install for
low-level diagnostics. Last time I checked, you need to register on
OSRonline.com to download, unfortunately.
http://www.osronline.com/section.cfm?section=27

OSR's NT Insider magazine is also a good place to keep up on driver and
kernel debugging technology changes:
http://www.osr.com/nt-insider/

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

Re: [edk2] [PATCH] ArmPlatformPkg: signal EndOfDxe event in PlatformBsdInit

[Laszlo Ersek]

On 09/03/15 18:39, Leif Lindholm wrote:
> On Tue, Sep 01, 2015 at 04:26:07PM +0200, Ard Biesheuvel wrote:
>> Like the ArmVirtPkg platforms up until SVN r17713, the ArmPlatformPkg
>> platforms built with the Intel BDS fail to signal the end-of-DXE event
>> 'gEfiEndOfDxeEventGroupGuid' when entering the BDS phase, which results
>> in some loss of functionality, i.e., variable reclaim in the VariableDxe
>> drivers, and the splitting of the memory regions that is part of the recently
>> added UEFI 2.5 properties table feature.
>>
>> As discussed on the edk2-devel mailing list here:
>>
>> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16109
>>
>> it is up to the platform BDS to signal that event, since there may be
>> platform specific ordering constraints with respect to the signalling
>> of the event that are difficult to honor at the generic level.
>>
>> So add the SignalEvent () call to PlatformBdsInit () of ArmPlatformPkg's
>> PlatformBdsLib implementation for the Intel BDS.
> 
> Naïve, and perhaps silly question/comment:
> ArmVirtPkg, and this patch, both call this from PlatformBdsInit(),
> whereas OvmfPkg does it from PlatformBdsPolicyBehavior().
> 
> The difference is the following segment in
> IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c
> which gets executed before signalling EndOfDxeEvent in OvmfPkg, but
> not for Arm*:
> ---
>   //
>   // Set up the device list based on EFI 1.1 variables
>   // process Driver and Load the driver's in the
>   // driver option list
>   //
>   BdsLibBuildOptionFromVar (&DriverOptionList, L"DriverOrder");
>   if (!IsListEmpty (&DriverOptionList)) {
> BdsLibLoadDrivers (&DriverOptionList);
>   }
>   //
>   // Check if we have the boot next option
>   //
>   mBootNext = BdsLibGetVariableAndSize (
> L"BootNext",
> &gEfiGlobalVariableGuid,
> &BootNextSize
> );
> ---
> 
> and the code at the start of Ovmf's PlatformBdsPolicyBehavior():
> ---
>   VisitAllInstancesOfProtocol (&gEfiPciRootBridgeIoProtocolGuid,
> ConnectRootBridge, NULL);
> 
>   //
>   // We can't signal End-of-Dxe earlier than this. Namely, End-of-Dxe triggers
>   // the preparation of S3 system information. That logic has a hard 
> dependency
>   // on the presence of the FACS ACPI table. Since our ACPI tables are only
>   // installed after PCI enumeration completes, we must not trigger the S3 
> save
>   // earlier, hence we can't signal End-of-Dxe earlier.
>   //
> ---
> 
> Does the above not apply for any ArmPlatformPkg platforms (or others
> importing ArmPlatformPkg's PlatformIntelBdsLib)?
> If so, is this also not applicable to virtio-pci in ArmVirtPkg?

I'm glad you asked; I had expected this question while writing the above
comment. :)

First, what ArmVirtPkg does is correct. And, what OvmfPkg does is not
correct, if we choose to be *extremely pedantic* anyway, because
EndOfDxe should be kicked *before* UEFI drivers (ie. third party
drivers, ie. untrusted, non-platform drivers) are dispatched.

However... You can see the justification in the OvmfPkg comment that you
quoted. This is a QEMU peculiarity that we just have to live with. Also,
as mitigating factor, we consider the UEFI drivers that our own selves
build into the firmware "trusted". (A related fact is that we don't
forbid PCD usage in our own UEFI drivers, although the EFI_PCD_PROTOCOL
is not part of the UEFI spec. We kinda consider our own UEFI drivers
part of the platform firmware.)

And, if someone is concerned about "external" UEFI drivers being
dispatched (eg. from some FAT partition) before we get to this part in
OVMF, then just enable Secure Boot, and then those drivers will either
not be dispatched, or (if they are signed appropriately) you should
trust them not to mess with stuff that is otherwise locked down by
EndOfDxe. This is not a perfect argument, but that's what we have to
live with.

Second, to your question why this doesn't apply to ArmVirtPkg even
though we do have virtio-pci there (ie. PCI enumeration that influences
QEMU's ACPI payload). The answer is: because there is no S3, and
therefore no related drivers, in ArmVirtPkg.

If you consider the dependency chain I described in the above comment,
it says

  the preparation of S3 system information [...] has a hard dependency
  on the presence of the FACS ACPI table

This is not true for ArmVirtPkg -- EndOfDxe doesn't trigger S3 stuff in
ArmVirtPkg, simply because S3 stuff *does not exist* there. So we can
kick EndOfDxe first, then do the PCI enumeration, then download the ACPI
tables (with the updated, PCI resource allocation-dependent contents) last.

Thanks
Laszlo



> 
> /
> Leif
> 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  | 36 
>> 
>>  ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h  |  1 +
>>  ArmPl

Re: [edk2] "Using Python to investigate EFI and ACPI"

[Laszlo Ersek]

On 09/03/15 18:41, j...@joshtriplett.org wrote:
> On Thu, Sep 03, 2015 at 05:53:45PM +0200, Laszlo Ersek wrote:
>> On 09/03/15 16:50, Josh Triplett wrote:

>>> Do you virtualize those I/O ports by CPU, to make them thread-safe, or
>>> does the last address written to 0x510 get saved system-wide, making it
>>> unsafe for concurrent access?
>>
>> I think fw_cfg is not meant to be accessed by several CPUs concurrently.
>> The protocol is stateful (selected key, offset within blob associated
>> with selected key, etc), and "accessing CPU" is not part of that state.
> 
> Not that hard to fix; just keep all the state in the accessing CPU
> rather than the system.  Current processors do that for the PCI I/O port
> pair, to avoid race conditions.  You could easily do that for the fw_cfg
> I/O ports.  As a bonus, you then wouldn't need to take any kind of lock
> around accesses to that state, because the CPU owns that state.
> 
> (That's the easy fix; the harder fix would be creating a new race-free
> MMIO protocol and mapping all of the data structures into memory
> directly, which would provide a performance benefit as well.  I'd love
> to see a general version of such a protocol for a more efficient virtio
> filesystem, though in the simpler case of fw_cfg you can just map all of
> the structures into memory.)

Well, first of all it should be justified why concurrent access to
fw_cfg would be necessary / useful :) But, I'm not arguing against it
per se; until very-very recently, the only client looking at fw_cfg has
been the firmware (it's called "firmware config" after all), and it's
quite natural to require that part of the firmware to be single-threaded.

Now, there's a fully independent discussion / development underway that
might want to expose fw_cfg to the kernel too. Let's not get into that
here, please talk to Gabriel for references :) (Cc'd).

... If you feel tempted to ask "why are then fw_cfg bindings for ARM
documented in the kernel?": because when we were extending fw_cfg from
x86 to ARM, advertizing the affected register block in the DT that QEMU
generated became a necessity, and Peter Maydell (QEMU maintainer and ARM
guru) proposed that I document the fw_cfg-related DT stuff *in the
kernel Documentation tree* -- simply because that was the largest, most
central registry of such DT bindings. This is my recollection of it anyway.

There's *yet another* development underway for speeding up fw_cfg
transfers; please talk to Marc Marí (Cc'd) about those :)

In any case, if what you need resembles a "general virtio filesystem",
then please just use that -- a virtio-block or virtio-scsi disk, with a
normal filesystem on it. The protocol is industry standard and the
performance of the QEMU (and kernel) implementation is splendid.

(For ad-hoc uses, even the "vfat" backend can be used, which practically
implements semihosting.)

fw_cfg was always meant as a set of small bits for the firmware to
consume. The fact that we squeeze kernel and initrd blobs through it is
just historical abuse that is now impossible to eradicate (and must be
sped up instead :(). Whereas other creative reasons that Gabriel could
tell you about why the kernel could be interested in fw_cfg, are just
that: creativity. Which might be better served by virtio too (this is
the subject of ongoing discussion).

>> Another question: when you execute an AML method that does, say, IO port
>> access, does the AML interpreter of ACPICA actually *perform* that IO
>> port access? Because, the one that is embedded in Linux obviously does,
>> and the one that is embedded in the userspace ACPICA command line
>> utility "acpiexec" obviously doesn't.
> 
> You need to pass unsafe_io=True to evaluate, in which case it'll do I/O.

Fantastic! :)

> Otherwise, it'll ignore I/O.  (On our TODO list: ignoring but logging
> I/O so we can look at the I/O accesses as part of the test.)
> 
> Actually, that reminds me: we should probably fix AcpiOsWriteMemory to
> do the same thing.
> 
>> I assume (and very much hope) that the IO port access *is* performed
>> from BITS, simply because you developed it for physical machines, and it
>> wouldn't make much sense to avoid actual hardware access that was
>> implemented by the BIOS vendor for that platform.
> 
> We want to default to not performing those accesses, but we definitely
> have the option to do so if you know you *want* to trigger real I/O.

Yes, me wants that, badly. :)

>> If that is the case, then this tool could become the killer ACPI tester
>> for QEMU developers -- the hardware accesses in the AML methods
>> generated by QEMU would actually poke QEMU devices! (Unlike the
>> userspace "acpiexec" utility.) It would completely detach Linux guest
>> driver development from host side / firmware development. \o/
> 
> That's exactly why we went with a pre-OS environment rather than an OS;
> you don't want to undermine the OS, and you don't want your tests
> affected by whatever the OS has done.

And, since you 

Re: [edk2] UEFI requirements for 32-bit Windows 8.1?

[Laszlo Ersek]

On 09/03/15 17:51, Brian J. Johnson wrote:
> On 09/03/2015 05:08 AM, Laszlo Ersek wrote:
>> Hi,
>>
>> 64-bit Windows 8.1 boots on QEMU + OVMF just fine. (The "pc" (i440fx)
>> machine type of QEMU has "always" worked, and we recently fixed "q35"
>> too.)
>>
>> However, 32-bit Windows 8.1 (ie. the installer of it) crashes with a
>> BSoD on the 32-bit build of OVMF *immediately*. This happens regardless
>> of the QEMU machine type. The error message I'm getting is:
>>
>> http://people.redhat.com/~lersek/windows-on-ovmf32/win8-ovmf32.png
>>
>> According to ,
>> the error code 0xc185 means "STATUS_IO_DEVICE_ERROR".
>>
>> I also tried with Windows 10:
>>
>> http://people.redhat.com/~lersek/windows-on-ovmf32/win10-ovmf32.png
>>
>> Here I get 0xc00d, "STATUS_INVALID_PARAMETER".
>>
>> The Windows ISOs I tried with were:
>> - en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso
>> - en_windows_10_enterprise_2015_ltsb_n_x86_dvd_6848317.iso
>>
>> Can someone please help me debug this? The difference between x64 and
>> x86 is "inexplicable".
> 
> I've worked through some firmware issues on older MS releases, but never
> Windows 8 or 10.  So this advice may be out of date.  Do you know if
> Windows got through the boot loader and is starting the kernel?

This is a good idea. So here's what I did:
- I built the FAT driver from source, as part of OVMF. Because, the FAT
  driver logs names of files being opened on EFI_D_INFO level, and I
  wanted to see those.
- I added a short log message to CoreExitBootServices() in
  "MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c".

This is the end of the OVMF debug log, before the BSOD hits (the log
excerpt has been filtered through my sed script that replaces GUIDs with
protocol names):

> Booting EFI SCSI Device
>  BlockSize : 2048
>  LastBlock : 15C05E
>  BlockSize : 2048
>  LastBlock : 7
> FatDiskIo: Cache Page OutBound occurred!
> FSOpen: Open '\EFI\BOOT\BOOTIA32.EFI' Success
> FSOpen: Open '\EFI\BOOT\BOOTIA32.EFI' Success
> InstallProtocolInterface: [EfiLoadedImageProtocol] 7F47DDE8
> Loading driver at 0x0001000 EntryPoint=0x00010005420 cdboot.efi
> InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 7F481F10

So, ExitBootServices() is not called, and the crash occurs before
cdboot.efi loads any other file.

> If so,
> you can turn on extra debug messages to show the drivers as they are
> loading.  That can give you some good clues.  If that's not enough, you
> can enable remote debugging and use MS's debuggers (eg. WinDbg) and
> symbol tables to get an idea of the call chain which is failing.  It's
> been a long time since I've done this, so I'm rusty on the specifics...
> searching on msdn.microsoft.com should get you going.
> 
> Historically, Windows has been extremely picky about ACPI tables, much
> more so than Linux.  Boot issues often have to do with ACPI details.  It
> has also had some quirks re. what it expects in the EFI memory map,
> although those have mostly related to really large systems (eg. PCIe
> segment layout.)
> 
> I see you CC'd some folks at Microsoft.  Hopefully they will be able to
> give you more specific advice.

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

Re: [edk2] UEFI requirements for 32-bit Windows 8.1?

[Laszlo Ersek]

First of all, thank you very much for responding!

On 09/03/15 19:08, Larry Cleeton wrote:
> The way I would debug this would be to modify the BCD store in the ISO to 
> turn on debugging in bootmgr,  winload, and the windows kernel.   
> 
> The BCD used by bootmgr on the ISO is efi\microsoft\boot\bcd.
>  
> Extract the ISO files to a writeable file system

Okay, I can do this.

> and then modify the BCD.  The following commands assume your current 
> directory is at the root of the extracted ISO files.
> 
> bcdedit /store efi\microsoft\boot\bcd /set {bootmgr} bootdebug on
> 
> bcdedit /store efi\microsoft\boot\bcd /set {default} bootdebug on
> 
> bcdedit /store efi\microsoft\boot\bcd /set {default} debug on

I can do this in a Windows VM.

> Recreate an ISO from the files.

Here I have a question. For the ISO image to be bootable under UEFI, it
needs an appropriate El Torito boot image. I've created such before,
with "genisoimage", but I'm unsure what I should pack back into it when
recreating the Windows installer ISO.

Hm... actually I could figure that out, simply by looking at the current
El Torito image on the original ISO, from the UEFI shell. Okay.

> Boot the ISO with a Windows debugger "connected" to the VM's COM1.
> I realize I'm leaving out a lot of details about this "connection"
> but I'm not familiar with how COM ports are plumbed on other
> virtualization hosts.

I think I've done this before. I can start another VM with WinDbg
running in it, and I can connect the virtual COM1 ports via a unix
domain socket. The *timing* of these virtual COM ports isn't very close
to the real thing (they're far enough to trip up the UDK debugger for
example!), but I *think* I've had some success with WinDbg.

Thank you!
Laszlo

> 
> Regards,
> Larry
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Thursday, September 03, 2015 3:08 AM
> To: edk2-devel-01 
> Cc: Larry Cleeton ; Kris Harper 
> 
> Subject: UEFI requirements for 32-bit Windows 8.1?
> 
> Hi,
> 
> 64-bit Windows 8.1 boots on QEMU + OVMF just fine. (The "pc" (i440fx) machine 
> type of QEMU has "always" worked, and we recently fixed "q35" too.)
> 
> However, 32-bit Windows 8.1 (ie. the installer of it) crashes with a BSoD on 
> the 32-bit build of OVMF *immediately*. This happens regardless of the QEMU 
> machine type. The error message I'm getting is:
> 
> http://people.redhat.com/~lersek/windows-on-ovmf32/win8-ovmf32.png
> 
> According to ,
> the error code 0xc185 means "STATUS_IO_DEVICE_ERROR".
> 
> I also tried with Windows 10:
> 
> http://people.redhat.com/~lersek/windows-on-ovmf32/win10-ovmf32.png
> 
> Here I get 0xc00d, "STATUS_INVALID_PARAMETER".
> 
> The Windows ISOs I tried with were:
> - en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso
> - en_windows_10_enterprise_2015_ltsb_n_x86_dvd_6848317.iso
> 
> Can someone please help me debug this? The difference between x64 and
> x86 is "inexplicable".
> 
> Thanks!
> Laszlo
> 

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

Re: [edk2] UEFI requirements for 32-bit Windows 8.1?

[Bill Paul]

Of all the gin joints in all the towns in all the world, Brian J. Johnson had 
to walk into mine at 08:51:20 on Thursday 03 September 2015 and say:

> On 09/03/2015 05:08 AM, Laszlo Ersek wrote:
> > Hi,
> > 
> > 64-bit Windows 8.1 boots on QEMU + OVMF just fine. (The "pc" (i440fx)
> > machine type of QEMU has "always" worked, and we recently fixed "q35"
> > too.)
> > 
> > However, 32-bit Windows 8.1 (ie. the installer of it) crashes with a
> > BSoD on the 32-bit build of OVMF *immediately*. This happens regardless
> > of the QEMU machine type. The error message I'm getting is:
> > 
> > http://people.redhat.com/~lersek/windows-on-ovmf32/win8-ovmf32.png
> > 
> > According to ,
> > the error code 0xc185 means "STATUS_IO_DEVICE_ERROR".
> > 
> > I also tried with Windows 10:
> > 
> > http://people.redhat.com/~lersek/windows-on-ovmf32/win10-ovmf32.png
> > 
> > Here I get 0xc00d, "STATUS_INVALID_PARAMETER".
> > 
> > The Windows ISOs I tried with were:
> > - en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso
> > - en_windows_10_enterprise_2015_ltsb_n_x86_dvd_6848317.iso
> > 
> > Can someone please help me debug this? The difference between x64 and
> > x86 is "inexplicable".
> 
> I've worked through some firmware issues on older MS releases, but never
> Windows 8 or 10.  So this advice may be out of date.  Do you know if
> Windows got through the boot loader and is starting the kernel?  If so,
> you can turn on extra debug messages to show the drivers as they are
> loading.  That can give you some good clues.  If that's not enough, you
> can enable remote debugging and use MS's debuggers (eg. WinDbg) and
> symbol tables to get an idea of the call chain which is failing.  It's
> been a long time since I've done this, so I'm rusty on the specifics...
> searching on msdn.microsoft.com should get you going.
> 
> Historically, Windows has been extremely picky about ACPI tables, much
> more so than Linux.

No: historically hardware vendors have been insufficiently picky about 
creating their ACPI tables, leading to what I have not-so-affectionately named 
the "If It Works With Windows, It Must Be Okay" syndrome.

I think Microsoft uses their own ACPI implementation in Windows rather than 
the Intel reference ACPI CA code. (At the very least I know they have their 
own ASL compiler.) Also, the majority of x86 hardware vendors, aside from 
Apple, only validate their systems with Windows because they perceive their 
target market as being comprised mainly of Windows users. Yes, even today. (Go 
count how many machines have Windows logo stickers on them. Now go count how 
many have little Linux or FreeBSD logo stickers on them. Big difference, isn't 
there.)

As a result, ACPI tables or AML code will often have little quirks that don't 
seem to bother Windows but which break everything else. In more egregious 
cases, the ASL might even be effectively written to say "if (OS == Windows) 
{work right} else {swallow own tongue}."

Given that ACPI is supposed to be an industry standard, you would think this 
wouldn't be a problem. But it's a _big_ and complicated standard, and as with 
any big and complicated standard, getting everyone to interpret it 100% 
unambiguously is hard. The same is true of UEFI.

Some of these issues would be avoided if the hardware manufacturers went to 
the trouble of testing their ACPI blobs with the Intel reference code and 
tools instead of just the Microsoft ones. But Microsoft has no incentive to 
compel logo program participants to do this, and there isn't "UEFI Forum" logo 
program (as far as I know). Even if there were, they might not feel obliged to 
comply with it anyway, because If It Works With Windows, It Must Be Okay.

I'm sorry I can't offer anything constructive to help you solve this 
particular problem though (other than be persistent and add lots of debug 
instrumentation), but I'm glad to see that at least someone is bothering to 
test the 32-bit build.

-Bill

> Boot issues often have to do with ACPI details.  It
> has also had some quirks re. what it expects in the EFI memory map,
> although those have mostly related to really large systems (eg. PCIe
> segment layout.)
> 
> I see you CC'd some folks at Microsoft.  Hopefully they will be able to
> give you more specific advice.

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] UEFI requirements for 32-bit Windows 8.1?

[Andrew Fish]

> On Sep 3, 2015, at 10:59 AM, Bill Paul  wrote:
> 
>> I've worked through some firmware issues on older MS releases, but never
>> Windows 8 or 10.  So this advice may be out of date.  Do you know if
>> Windows got through the boot loader and is starting the kernel?  If so,
>> you can turn on extra debug messages to show the drivers as they are
>> loading.  That can give you some good clues.  If that's not enough, you
>> can enable remote debugging and use MS's debuggers (eg. WinDbg) and
>> symbol tables to get an idea of the call chain which is failing.  It's
>> been a long time since I've done this, so I'm rusty on the specifics...
>> searching on msdn.microsoft.com  should get you 
>> going.
>> 
>> Historically, Windows has been extremely picky about ACPI tables, much
>> more so than Linux.
> 
> No: historically hardware vendors have been insufficiently picky about 
> creating their ACPI tables, leading to what I have not-so-affectionately 
> named 
> the "If It Works With Windows, It Must Be Okay" syndrome.

This issue even finds its way into hardware. I’ve seen USB device that violate 
the USB spec, but they work with the Windows driver, so ship it.

Thanks,

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

Re: [edk2] [PATCH] ArmPlatformPkg: signal EndOfDxe event in PlatformBsdInit

[Leif Lindholm]

On Thu, Sep 03, 2015 at 06:58:11PM +0200, Laszlo Ersek wrote:
> > and the code at the start of Ovmf's PlatformBdsPolicyBehavior():
> > ---
> >   VisitAllInstancesOfProtocol (&gEfiPciRootBridgeIoProtocolGuid,
> > ConnectRootBridge, NULL);
> > 
> >   //
> >   // We can't signal End-of-Dxe earlier than this. Namely, End-of-Dxe 
> > triggers
> >   // the preparation of S3 system information. That logic has a hard 
> > dependency
> >   // on the presence of the FACS ACPI table. Since our ACPI tables are only
> >   // installed after PCI enumeration completes, we must not trigger the S3 
> > save
> >   // earlier, hence we can't signal End-of-Dxe earlier.
> >   //
> > ---
> > 
> > Does the above not apply for any ArmPlatformPkg platforms (or others
> > importing ArmPlatformPkg's PlatformIntelBdsLib)?
> > If so, is this also not applicable to virtio-pci in ArmVirtPkg?
> 
> I'm glad you asked; I had expected this question while writing the above
> comment. :)

:)
 
> First, what ArmVirtPkg does is correct. And, what OvmfPkg does is not
> correct, if we choose to be *extremely pedantic* anyway, because
> EndOfDxe should be kicked *before* UEFI drivers (ie. third party
> drivers, ie. untrusted, non-platform drivers) are dispatched.

OK.
 
> However... You can see the justification in the OvmfPkg comment that you
> quoted. This is a QEMU peculiarity that we just have to live with. Also,
> as mitigating factor, we consider the UEFI drivers that our own selves
> build into the firmware "trusted". (A related fact is that we don't
> forbid PCD usage in our own UEFI drivers, although the EFI_PCD_PROTOCOL
> is not part of the UEFI spec. We kinda consider our own UEFI drivers
> part of the platform firmware.)

Sure, that makes sense.

> And, if someone is concerned about "external" UEFI drivers being
> dispatched (eg. from some FAT partition) before we get to this part in
> OVMF, then just enable Secure Boot, and then those drivers will either
> not be dispatched, or (if they are signed appropriately) you should
> trust them not to mess with stuff that is otherwise locked down by
> EndOfDxe. This is not a perfect argument, but that's what we have to
> live with.

:)
 
> Second, to your question why this doesn't apply to ArmVirtPkg even
> though we do have virtio-pci there (ie. PCI enumeration that influences
> QEMU's ACPI payload). The answer is: because there is no S3, and
> therefore no related drivers, in ArmVirtPkg.
> 
> If you consider the dependency chain I described in the above comment,
> it says
> 
>   the preparation of S3 system information [...] has a hard dependency
>   on the presence of the FACS ACPI table
> 
> This is not true for ArmVirtPkg -- EndOfDxe doesn't trigger S3 stuff in
> ArmVirtPkg, simply because S3 stuff *does not exist* there. So we can
> kick EndOfDxe first, then do the PCI enumeration, then download the ACPI
> tables (with the updated, PCI resource allocation-dependent contents) last.

OK.

Thanks for the detailed reply Laszlo!
Given that - Reviewed-by: Leif Lindholm 


> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>  ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c  | 36 
> >> 
> >>  ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.h  |  1 +
> >>  ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf |  1 +
> >>  3 files changed, 38 insertions(+)
> >>
> >> diff --git a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c 
> >> b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
> >> index 98d5b277a636..e27e6d66df91 100644
> >> --- a/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
> >> +++ b/ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
> >> @@ -31,6 +31,24 @@ PlatformIntelBdsConstructor (
> >>return EFI_SUCCESS;
> >>  }
> >>  
> >> +/**
> >> +  An empty function to pass error checking of CreateEventEx ().
> >> +
> >> +  @param  Event Event whose notification function is 
> >> being invoked.
> >> +  @param  Context   Pointer to the notification function's 
> >> context,
> >> +which is implementation-dependent.
> >> +
> >> +**/
> >> +STATIC
> >> +VOID
> >> +EFIAPI
> >> +EmptyCallbackFunction (
> >> +  IN EFI_EVENTEvent,
> >> +  IN VOID *Context
> >> +  )
> >> +{
> >> +}
> >> +
> >>  //
> >>  // BDS Platform Functions
> >>  //
> >> @@ -45,6 +63,24 @@ PlatformBdsInit (
> >>VOID
> >>)
> >>  {
> >> +  EFI_EVENT   EndOfDxeEvent;
> >> +  EFI_STATUS  Status;
> >> +
> >> +  //
> >> +  // Signal EndOfDxe PI Event
> >> +  //
> >> +  Status = gBS->CreateEventEx (
> >> +  EVT_NOTIFY_SIGNAL,
> >> +  TPL_CALLBACK,
> >> +  EmptyCallbackFunction,
> >> +  NULL,
> >> +  &gEfiEndOfDxeEventGroupGuid,
> >> +  &EndOfDx

Re: [edk2] GetTime - TimeZone

[Andrew Fish]

> On Sep 3, 2015, at 12:52 PM, Sivasakthivel Nainar  
> wrote:
> 
> Below both are different Real Time clock implementations in EDK II source. 
> 
> ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c 
> 
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
> 
> One is  adjusting the Time with Timezone value programmed and other one ( PC 
> code )  is not adjusting.  I think  UEFI spec does not  ask to adjust the 
> time to timezone. 
> 

The Spec, which probably is a little too PC centric, states that TimeZone, and 
Daylight come from values set via SetTime(). I would posit if the RTC stores 
the TimeZone and Daylight information, then it makes sense to return that info.

Thanks,

Andrew Fish

> ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c   
> implementation may need to be  reviewed. 
> 
> The information contained in this message may be confidential and proprietary 
> to American Megatrends, Inc.  This communication is intended to be read only 
> by the individual or entity to whom it is addressed or by their designee. If 
> the reader of this message is not the intended recipient, you are on notice 
> that any distribution of this message, in any form, is strictly prohibited.  
> Please promptly notify the sender by reply e-mail or by telephone at 
> 770-246-8600, and then delete or destroy all copies of the transmission.
> 
> --
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> https://urldefense.proofpoint.com/v2/url?u=http-3A__pubads.g.doubleclick.net_gampad_clk-3Fid-3D241902991-26iu-3D_4140&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Hism9nC6KlTfuPZYQLFLdUNQe5rjowHx5EmCA4_Wa_E&s=d7TY3q2cp-QF5SkUPEH_TjQt7IVQg2lp3gFMqFTJftw&e=
>  
> ___
> edk2-devel mailing list
> edk2-de...@lists.sourceforge.net
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Hism9nC6KlTfuPZYQLFLdUNQe5rjowHx5EmCA4_Wa_E&s=ECollaIBK78uEC6-NsVpsafMVhNvvO5fkFpeFWM7MJg&e=
>  

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

Re: [edk2] UEFI requirements for 32-bit Windows 8.1?

[Brian J. Johnson]

On 09/03/2015 12:59 PM, Bill Paul wrote:

Of all the gin joints in all the towns in all the world, Brian J. Johnson had
to walk into mine at 08:51:20 on Thursday 03 September 2015 and say:


On 09/03/2015 05:08 AM, Laszlo Ersek wrote:

Hi,

64-bit Windows 8.1 boots on QEMU + OVMF just fine. (The "pc" (i440fx)
machine type of QEMU has "always" worked, and we recently fixed "q35"
too.)

However, 32-bit Windows 8.1 (ie. the installer of it) crashes with a
BSoD on the 32-bit build of OVMF *immediately*. This happens regardless
of the QEMU machine type. The error message I'm getting is:

http://people.redhat.com/~lersek/windows-on-ovmf32/win8-ovmf32.png

According to ,
the error code 0xc185 means "STATUS_IO_DEVICE_ERROR".

I also tried with Windows 10:

http://people.redhat.com/~lersek/windows-on-ovmf32/win10-ovmf32.png

Here I get 0xc00d, "STATUS_INVALID_PARAMETER".

The Windows ISOs I tried with were:
- en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso
- en_windows_10_enterprise_2015_ltsb_n_x86_dvd_6848317.iso

Can someone please help me debug this? The difference between x64 and
x86 is "inexplicable".


I've worked through some firmware issues on older MS releases, but never
Windows 8 or 10.  So this advice may be out of date.  Do you know if
Windows got through the boot loader and is starting the kernel?  If so,
you can turn on extra debug messages to show the drivers as they are
loading.  That can give you some good clues.  If that's not enough, you
can enable remote debugging and use MS's debuggers (eg. WinDbg) and
symbol tables to get an idea of the call chain which is failing.  It's
been a long time since I've done this, so I'm rusty on the specifics...
searching on msdn.microsoft.com should get you going.

Historically, Windows has been extremely picky about ACPI tables, much
more so than Linux.


No: historically hardware vendors have been insufficiently picky about
creating their ACPI tables, leading to what I have not-so-affectionately named
the "If It Works With Windows, It Must Be Okay" syndrome.


It cuts all ways:  for vendors which do focus on Linux (such as SGI), 
Windows tends to get broken.  (And it's a lot harder to debug a broken 
Windows boot, as Laszlo is finding out.)  Both OSes have been guilty of 
making assumptions which violate the relevant specs (UEFI, ACPI, etc.) 
And yes, h/w vendors have had plenty of firmware bugs of their own.


Sigh... the world is messy.
--

Brian J. Johnson



  My statements are my own, are not authorized by SGI, and do not
  necessarily represent SGI’s positions.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] "Using Python to investigate EFI and ACPI"

[josh]

On Thu, Sep 03, 2015 at 07:19:40PM +0200, Laszlo Ersek wrote:
> On 09/03/15 18:41, j...@joshtriplett.org wrote:
> > On Thu, Sep 03, 2015 at 05:53:45PM +0200, Laszlo Ersek wrote:
> >> On 09/03/15 16:50, Josh Triplett wrote:
> 
> >>> Do you virtualize those I/O ports by CPU, to make them thread-safe, or
> >>> does the last address written to 0x510 get saved system-wide, making it
> >>> unsafe for concurrent access?
> >>
> >> I think fw_cfg is not meant to be accessed by several CPUs concurrently.
> >> The protocol is stateful (selected key, offset within blob associated
> >> with selected key, etc), and "accessing CPU" is not part of that state.
> > 
> > Not that hard to fix; just keep all the state in the accessing CPU
> > rather than the system.  Current processors do that for the PCI I/O port
> > pair, to avoid race conditions.  You could easily do that for the fw_cfg
> > I/O ports.  As a bonus, you then wouldn't need to take any kind of lock
> > around accesses to that state, because the CPU owns that state.
> > 
> > (That's the easy fix; the harder fix would be creating a new race-free
> > MMIO protocol and mapping all of the data structures into memory
> > directly, which would provide a performance benefit as well.  I'd love
> > to see a general version of such a protocol for a more efficient virtio
> > filesystem, though in the simpler case of fw_cfg you can just map all of
> > the structures into memory.)
> 
> Well, first of all it should be justified why concurrent access to
> fw_cfg would be necessary / useful :) But, I'm not arguing against it
> per se; until very-very recently, the only client looking at fw_cfg has
> been the firmware (it's called "firmware config" after all), and it's
> quite natural to require that part of the firmware to be single-threaded.

As systems get larger, it may start making sense to have multi-threaded
firmware and initialization.

> Now, there's a fully independent discussion / development underway that
> might want to expose fw_cfg to the kernel too. Let's not get into that
> here, please talk to Gabriel for references :) (Cc'd).

That's another reason to want a concurrency-safe protocol. :)

> There's *yet another* development underway for speeding up fw_cfg
> transfers; please talk to Marc Marí (Cc'd) about those :)
> 
> In any case, if what you need resembles a "general virtio filesystem",
> then please just use that -- a virtio-block or virtio-scsi disk, with a
> normal filesystem on it. The protocol is industry standard and the
> performance of the QEMU (and kernel) implementation is splendid.

Not at all what I'm looking for; I'm looking for a *filesystem*, like
virtio-9p, but with significantly better performance.  I agree that
starting from fw_cfg for that is probably a bad idea; it's more that if
a high-performance virtio filesystem existed, it might also work for
fw_cfg. :)

> (For ad-hoc uses, even the "vfat" backend can be used, which practically
> implements semihosting.)

Last time I'd looked at it, that backend didn't support writing, only
reading.  You also couldn't safely change the files with the VM running.
FAT also doesn't support any semblance of POSIX semantics.

I don't think a manufactured block device is the right interface here.

> fw_cfg was always meant as a set of small bits for the firmware to
> consume. The fact that we squeeze kernel and initrd blobs through it is
> just historical abuse that is now impossible to eradicate (and must be
> sped up instead :(). Whereas other creative reasons that Gabriel could
> tell you about why the kernel could be interested in fw_cfg, are just
> that: creativity. Which might be better served by virtio too (this is
> the subject of ongoing discussion).

Sure, any replacement protocol should probably go through virtio. :)

> >> If that is the case, then this tool could become the killer ACPI tester
> >> for QEMU developers -- the hardware accesses in the AML methods
> >> generated by QEMU would actually poke QEMU devices! (Unlike the
> >> userspace "acpiexec" utility.) It would completely detach Linux guest
> >> driver development from host side / firmware development. \o/
> > 
> > That's exactly why we went with a pre-OS environment rather than an OS;
> > you don't want to undermine the OS, and you don't want your tests
> > affected by whatever the OS has done.
> 
> And, since you implemented it as part of GRUB, it is not tied to either
> OVMF or SeaBIOS (speaking in virt terms for now) -- it's flexible.

Right, exactly.  We don't have any plans to make UEFI a hard
requirement, though some future features will likely only work on UEFI
(such as our current WIP support for TCP/IP networking).

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

Re: [edk2] "Using Python to investigate EFI and ACPI"

[Laszlo Ersek]

On 09/03/15 23:25, j...@joshtriplett.org wrote:
> On Thu, Sep 03, 2015 at 07:19:40PM +0200, Laszlo Ersek wrote:

>> In any case, if what you need resembles a "general virtio filesystem",
>> then please just use that -- a virtio-block or virtio-scsi disk, with a
>> normal filesystem on it. The protocol is industry standard and the
>> performance of the QEMU (and kernel) implementation is splendid.
> 
> Not at all what I'm looking for; I'm looking for a *filesystem*, like
> virtio-9p, but with significantly better performance.  I agree that
> starting from fw_cfg for that is probably a bad idea; it's more that if
> a high-performance virtio filesystem existed, it might also work for
> fw_cfg. :)

Thanks for mentioning "virtio-9p", now I remember what to point at
instead of it. I recommend Stefan's slides from this year's KVM forum.

https://kvmforum2015.sched.org/event/bca50b64e0fbea734b855498f25d0753
http://blog.vmsplice.net/2015/08/virtio-vsock-zero-configuration.html

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

[edk2] How do you add linker flags to EDK2 MdeModule\Library builds ?

[Shubha Ramani]

I need to add a linker option /largeaddressaware:no  but I don't know how to do 
it.
Thanks,
Shubha
Shubha D. ramanishubharam...@gmail.com
shubharam...@yahoo.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] UEFI requirements for 32-bit Windows 8.1?

[Laszlo Ersek]

So this was extremely painful...

On 09/03/15 19:44, Laszlo Ersek wrote:
> First of all, thank you very much for responding!
>
> On 09/03/15 19:08, Larry Cleeton wrote:
>> The way I would debug this would be to modify the BCD store in the
>> ISO to turn on debugging in bootmgr,  winload, and the windows
>> kernel.
>>
>> The BCD used by bootmgr on the ISO is efi\microsoft\boot\bcd.
>>
>> Extract the ISO files to a writeable file system
>
> Okay, I can do this.

Right, I managed it.

>
>> and then modify the BCD.  The following commands assume your current
>> directory is at the root of the extracted ISO files.
>>
>> bcdedit /store efi\microsoft\boot\bcd /set {bootmgr} bootdebug on
>>
>> bcdedit /store efi\microsoft\boot\bcd /set {default} bootdebug on
>>
>> bcdedit /store efi\microsoft\boot\bcd /set {default} debug on
>
> I can do this in a Windows VM.

First roadblock. These commands don't work from PowerShell. Dunno why.
They just don't. I googled the error message and (obviously)
StackOverflow pointed out that I needed to use cmd.exe. Then the
commands worked. :)

(As a precaution against "jitter" I set a baud rate of 38400.)

>> Recreate an ISO from the files.
>
> Here I have a question. For the ISO image to be bootable under UEFI,
> it needs an appropriate El Torito boot image. I've created such
> before, with "genisoimage", but I'm unsure what I should pack back
> into it when recreating the Windows installer ISO.
>
> Hm... actually I could figure that out, simply by looking at the
> current El Torito image on the original ISO, from the UEFI shell.
> Okay.

Not okay. :( This did not work *at all*. I recreated the ISO with
genisoimage, best I could. It didn't boot; the boot loader complained
about not finding the BCD file. It was there.

Anyway... I located the start offset of 256KB original BCD file:

  efi/microsoft/boot/bcd

in the ISO image:

  en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso

I got lucky because the 128 UDF sectors constituting the BCD file were
consecutive. So I modified the BCD file in a Windows VM, then poked it
directly back into a copy of the original ISO, with

  dd \
if=modified_bcd \
of=new.iso \
bs=2048 \
count=128 \
seek=1359975 \
conv=notrunc

Then I mounted both the original and the modified ISO, and recursively
diffed them. The filesystem was okay on the modified ISO too, and the
only differences were in efi/microsoft/boot/bcd.

>> Boot the ISO with a Windows debugger "connected" to the VM's COM1.
>> I realize I'm leaving out a lot of details about this "connection"
>> but I'm not familiar with how COM ports are plumbed on other
>> virtualization hosts.
>
> I think I've done this before. I can start another VM with WinDbg
> running in it, and I can connect the virtual COM1 ports via a unix
> domain socket. The *timing* of these virtual COM ports isn't very
> close to the real thing (they're far enough to trip up the UDK
> debugger for example!), but I *think* I've had some success with
> WinDbg.

... Then it was only a matter of hours to download & install & configure
WinDbg, connect the virtual machines' COM1 ports via a unix domain
socket (through the libvirt domain XMLs), realize that libvirt insists
on associating COM1 with the primary console of each VM, hence redo the
entire BCD thing for COM2, and finally end up with a working setup.

Which left me with the following debug output:

> Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64
> Copyright (c) Microsoft Corporation. All rights reserved.
>
> Opened \\.\com2
> Waiting to reconnect...
> BD: Boot Debugger Initialized
> Connected to Windows Boot Debugger 9600 x86 compatible target at (Fri Sep  4 
> 01:11:18.801 2015 (UTC + 2:00)), ptr64 FALSE
> Kernel Debugger connection established.
>
> * Symbol Path validation summary **
> Response Time (ms) Location
> Deferred   
> SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
> Symbol search path is: 
> SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
> Executable search path is:
> Windows Boot Debugger Kernel Version 9600 UP Free x86 compatible
> Machine Name:
> Primary image base = 0x005ab000 Loaded module list = 0x00725ee8
> System Uptime: not available
>
> * Symbol Path validation summary **
> Response Time (ms) Location
> Deferred   
> SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
>
> The boot selection failed because a required device is inaccessible 
> (c185).
>
> *** Fatal Error 0x0001 :
> (0x0005, 0xC185, 0x, 0x)
>
> Break instruction exception - code 8003 (first chance)
> bootmgr!BlStatusError+0x29:
> 005fd405 cc  int 3
> kd> k
> ChildEBP RetAddr
> 00136c9c 005cd406 bootmgr!BlStatusError+0x29
> 00136ed4 005c8222 bootmgr!BmFatalErrorEx+0x33d
> 00136f10 

Re: [edk2] How do you add linker flags to EDK2 MdeModule\Library builds ?

[Laszlo Ersek]

On 09/04/15 01:26, Shubha Ramani wrote:
> I need to add a linker option /largeaddressaware:no  but I don't know how to 
> do it.

You can see a [BuildOptions] example in
"CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf". Which also showcases
how to add different flags for different compiler families.

You can use "=" or "==" to append or override build options. I won't
tell you which does which, because you should read the EDK2 file format
specs anyway.

http://tianocore.sourceforge.net/wiki/EDK_II_Specifications

(Your question is answered in the INF file spec.)

Laszlo

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

Re: [edk2] UEFI requirements for 32-bit Windows 8.1?

[Larry Cleeton]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, September 03, 2015 4:48 PM
> To: Larry Cleeton 
> Cc: edk2-devel-01 ; Kris Harper
> 
> Subject: Re: UEFI requirements for 32-bit Windows 8.1?
> 
> So this was extremely painful...
> 
> On 09/03/15 19:44, Laszlo Ersek wrote:
> > First of all, thank you very much for responding!
> >
> > On 09/03/15 19:08, Larry Cleeton wrote:
> >> The way I would debug this would be to modify the BCD store in the
> >> ISO to turn on debugging in bootmgr,  winload, and the windows
> >> kernel.
> >>
> >> The BCD used by bootmgr on the ISO is efi\microsoft\boot\bcd.
> >>
> >> Extract the ISO files to a writeable file system
> >
> > Okay, I can do this.
> 
> Right, I managed it.
> 
> >
> >> and then modify the BCD.  The following commands assume your current
> >> directory is at the root of the extracted ISO files.
> >>
> >> bcdedit /store efi\microsoft\boot\bcd /set {bootmgr} bootdebug on
> >>
> >> bcdedit /store efi\microsoft\boot\bcd /set {default} bootdebug on
> >>
> >> bcdedit /store efi\microsoft\boot\bcd /set {default} debug on
> >
> > I can do this in a Windows VM.
> 
> First roadblock. These commands don't work from PowerShell. Dunno why.
> They just don't. I googled the error message and (obviously) StackOverflow
> pointed out that I needed to use cmd.exe. Then the commands worked. :)
> 
> (As a precaution against "jitter" I set a baud rate of 38400.)
> 
> >> Recreate an ISO from the files.
> >
> > Here I have a question. For the ISO image to be bootable under UEFI,
> > it needs an appropriate El Torito boot image. I've created such
> > before, with "genisoimage", but I'm unsure what I should pack back
> > into it when recreating the Windows installer ISO.
> >
> > Hm... actually I could figure that out, simply by looking at the
> > current El Torito image on the original ISO, from the UEFI shell.
> > Okay.
> 
> Not okay. :( This did not work *at all*. I recreated the ISO with genisoimage,
> best I could. It didn't boot; the boot loader complained about not finding the
> BCD file. It was there.
> 
> Anyway... I located the start offset of 256KB original BCD file:
> 
>   efi/microsoft/boot/bcd
> 
> in the ISO image:
> 
>   en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso
> 
> I got lucky because the 128 UDF sectors constituting the BCD file were
> consecutive. So I modified the BCD file in a Windows VM, then poked it
> directly back into a copy of the original ISO, with
> 
>   dd \
> if=modified_bcd \
> of=new.iso \
> bs=2048 \
> count=128 \
> seek=1359975 \
> conv=notrunc
> 
> Then I mounted both the original and the modified ISO, and recursively
> diffed them. The filesystem was okay on the modified ISO too, and the only
> differences were in efi/microsoft/boot/bcd.
> 
> >> Boot the ISO with a Windows debugger "connected" to the VM's COM1.
> >> I realize I'm leaving out a lot of details about this "connection"
> >> but I'm not familiar with how COM ports are plumbed on other
> >> virtualization hosts.
> >
> > I think I've done this before. I can start another VM with WinDbg
> > running in it, and I can connect the virtual COM1 ports via a unix
> > domain socket. The *timing* of these virtual COM ports isn't very
> > close to the real thing (they're far enough to trip up the UDK
> > debugger for example!), but I *think* I've had some success with
> > WinDbg.
> 
> ... Then it was only a matter of hours to download & install & configure
> WinDbg, connect the virtual machines' COM1 ports via a unix domain socket
> (through the libvirt domain XMLs), realize that libvirt insists on associating
> COM1 with the primary console of each VM, hence redo the entire BCD thing
> for COM2, and finally end up with a working setup.
> 
> Which left me with the following debug output:
> 
> > Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64 Copyright
> > (c) Microsoft Corporation. All rights reserved.
> >
> > Opened \\.\com2
> > Waiting to reconnect...
> > BD: Boot Debugger Initialized
> > Connected to Windows Boot Debugger 9600 x86 compatible target at (Fri
> > Sep  4 01:11:18.801 2015 (UTC + 2:00)), ptr64 FALSE Kernel Debugger
> connection established.
> >
> > * Symbol Path validation summary **
> > Response Time (ms) Location
> > Deferred
> SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
> > Symbol search path is:
> > SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
> > Executable search path is:
> > Windows Boot Debugger Kernel Version 9600 UP Free x86 compatible
> > Machine Name:
> > Primary image base = 0x005ab000 Loaded module list = 0x00725ee8 System
> > Uptime: not available
> >
> > * Symbol Path validation summary **
> > Response Time (ms) Location
> > Deferred
> SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
> >
> > The boot selection failed because a required de

Re: [edk2] How do you add linker flags to EDK2 MdeModule\Library builds ?

[Bruce Cran]

On 9/3/15 6:06 PM, Laszlo Ersek wrote:


http://tianocore.sourceforge.net/wiki/EDK_II_Specifications

(Your question is answered in the INF file spec.)


The INF spec hasn't, but some of the other EDK2 specs have been updated 
to rev 1.25, which I've mirrored to 
http://edk2.bluestop.org/edk2/docs/specs/ .


--
Bruce

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

[edk2] Confused about OVMF and qemu debugging

[Shubha Ramani]

Using this link I was able to get qemu installed on my Ubuntu virtual machine. 
UEFI/OVMF - Ubuntu Wiki

|   |
|   |   |   |   |   |
| UEFI/OVMF - Ubuntu WikiOVMF is a port of Intel's tianocore firmware to the 
qemu virtual machine. This allows easy debugging and experimentation with UEFI 
firmware;  |
|  |
| View on wiki.ubuntu.com | Preview by Yahoo |
|  |
|   |

Also it referred me to this link to get a sample bios 
image:http://people.canonical.com/~jk/ovmf/

1) Is this the appropriate bios image to use to test out UEFI apps before 
moving to real hardware ?
2) Can I connect gdb and debug efi applications - say by using gdbserver on 
Ubuntu ? If so, what are the steps to do this ?
I will never need to boot beyond the UEFI. I only develop EDK2 apps which run 
in UEFI.  The issueis that it's cumbersome to debug complex apps on buggy 
bios/hardware. It's better to get theapps debugged on a stable simulator like 
qemu, then move onto the UEFI/hardware under development.
Please advise - 
thanks,
Shubha
Shubha D. ramanishubharam...@gmail.com
shubharam...@yahoo.com
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPlatformPkg: signal EndOfDxe event in PlatformBsdInit

[Ard Biesheuvel]

On 3 September 2015 at 22:14, Leif Lindholm  wrote:
> On Thu, Sep 03, 2015 at 06:58:11PM +0200, Laszlo Ersek wrote:
>> > and the code at the start of Ovmf's PlatformBdsPolicyBehavior():
>> > ---
>> >   VisitAllInstancesOfProtocol (&gEfiPciRootBridgeIoProtocolGuid,
>> > ConnectRootBridge, NULL);
>> >
>> >   //
>> >   // We can't signal End-of-Dxe earlier than this. Namely, End-of-Dxe 
>> > triggers
>> >   // the preparation of S3 system information. That logic has a hard 
>> > dependency
>> >   // on the presence of the FACS ACPI table. Since our ACPI tables are only
>> >   // installed after PCI enumeration completes, we must not trigger the S3 
>> > save
>> >   // earlier, hence we can't signal End-of-Dxe earlier.
>> >   //
>> > ---
>> >
>> > Does the above not apply for any ArmPlatformPkg platforms (or others
>> > importing ArmPlatformPkg's PlatformIntelBdsLib)?
>> > If so, is this also not applicable to virtio-pci in ArmVirtPkg?
>>
>> I'm glad you asked; I had expected this question while writing the above
>> comment. :)
>
> :)
>
[...]
> Thanks for the detailed reply Laszlo!
> Given that - Reviewed-by: Leif Lindholm 
>

Thanks guys. Commited as SVN r18394

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