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

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

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 (, L"DriverOrder");
  if (!IsListEmpty ()) {
BdsLibLoadDrivers ();
  }
  //
  // Check if we have the boot next option
  //
  mBootNext = BdsLibGetVariableAndSize (
L"BootNext",
,

);
---

and the code at the start of Ovmf's PlatformBdsPolicyBehavior():
---
  VisitAllInstancesOfProtocol (,
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,
> +  ,
> +  
> +  );
> +  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 
>  
>  #endif // _INTEL_BDS_PLATFORM_H
> diff --git 
> a/ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf 
> 

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] 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=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=Hism9nC6KlTfuPZYQLFLdUNQe5rjowHx5EmCA4_Wa_E=d7TY3q2cp-QF5SkUPEH_TjQt7IVQg2lp3gFMqFTJftw=
>  
> ___
> 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=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=Hism9nC6KlTfuPZYQLFLdUNQe5rjowHx5EmCA4_Wa_E=ECollaIBK78uEC6-NsVpsafMVhNvvO5fkFpeFWM7MJg=
>  

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

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?

[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

[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

[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