Re: [edk2] Unable to build a compressed ROM image via the .INF file

[Mahan, Patrick]

Zhu Yonghong,

That fixed it, how long until it gets checked in?  I may need to document this 
patch if it is going to be a few weeks.

Thanks,

Patrick


From: Zhu, Yonghong <yonghong@intel.com>
Sent: Wednesday, June 1, 2016 8:17 PM
To: Mahan, Patrick; 'edk2-devel@lists.01.org'
Cc: Zhu, Yonghong
Subject: RE: Unable to build a compressed ROM image via the .INF file

Hi Patrick,

I sent a patch to fix this bug.

[edk2] [Patch] BaseTools: fix the bug to build a compressed ROM image via .INF 
file


Best Regards,
Zhu Yonghong


-Original Message-
From: Zhu, Yonghong
Sent: Wednesday, June 01, 2016 4:24 PM
To: Mahan, Patrick <patrick.ma...@cavium.com>; edk2-devel@lists.01.org
Cc: Zhu, Yonghong <yonghong@intel.com>; Zhu, Yonghong 
<yonghong@intel.com>
Subject: RE: Unable to build a compressed ROM image via the .INF file

Hi Patrick,

Thanks for report it. I am in investigating this issue, I will give your result 
later.

Best Regards,
Zhu Yonghong

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Mahan, 
Patrick
Sent: Wednesday, June 1, 2016 12:16 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Unable to build a compressed ROM image via the .INF file

All,

I am attempting to generate an compressed ROM image for our NIC driver.

I have the following defined in my .INF file -

PCI_VENDOR_ID = 0x177D
PCI_DEVICE_ID = 0x9700
PCI_CLASS_CODE = 0x0200
PCI_REVISION  = 0x0003
PCI_COMPRESS  = TRUE

However, when I issue the build command -

  build -a X64 -p LioDescPkg/LioDxe.dsc -b RELEASE

The ROM is built with the following command -

EfiRom -i 0x9702 -f 0x177D -l 0x0200 -r 0x0003 -o 
/home/pmahan/src/EdkII/edk2/Build/LioDxe/RELEASE_GCC48/X64/LioDxe.rom -e 
/home/pmahan/src/EdkII/edk2/Build/LioDxe/RELEASE_GCC48/X64/LioDxePkg/LioDxe/LioDxe/DEBUG/LioDxe.efi


Notice that it is issuing the '-e' not '-ec' as I expected.

Is this a know issue?

Thanks,

Patrick
___
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] Unable to build a compressed ROM image via the .INF file

[Mahan, Patrick]

All,

I am attempting to generate an compressed ROM image for our NIC driver.

I have the following defined in my .INF file -

PCI_VENDOR_ID = 0x177D
PCI_DEVICE_ID = 0x9700
PCI_CLASS_CODE = 0x0200
PCI_REVISION  = 0x0003
PCI_COMPRESS  = TRUE

However, when I issue the build command -

  build -a X64 -p LioDescPkg/LioDxe.dsc -b RELEASE 

The ROM is built with the following command -

EfiRom -i 0x9702 -f 0x177D -l 0x0200 -r 0x0003 -o 
/home/pmahan/src/EdkII/edk2/Build/LioDxe/RELEASE_GCC48/X64/LioDxe.rom -e 
/home/pmahan/src/EdkII/edk2/Build/LioDxe/RELEASE_GCC48/X64/LioDxePkg/LioDxe/LioDxe/DEBUG/LioDxe.efi


Notice that it is issuing the '-e' not '-ec' as I expected.

Is this a know issue?

Thanks,

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

Re: [edk2] TCPIP Client for UEFI

[Mahan, Patrick]

Jim,

I think your only recourse is to contact the who provided the SOC board and ask 
about how to rebuild the UEFI bootloader image for that board.  Then look at 
those instructions to see how to enable the network stack.

Good luck,

Patrick


From: edk2-devel <edk2-devel-boun...@lists.01.org> on behalf of Jim Slaughter 
<jwslau...@yahoo.com>
Sent: Monday, April 11, 2016 4:29 PM
To: Mahan, Patrick
Cc: Edk2-devel
Subject: Re: [edk2] TCPIP Client for UEFI

Hello Patrick,Thank you.I do not have a setup screen with this BIOS/uEFI. Its n 
SOC on a board but not really a consumer PC type.I need to figure out a way to 
setup the NIC, find something already written or write it myself. I am not sure 
if a setup can be done after the actual uefi boot. think Setup on a computer is 
really before the boot process.All the ifconfig commands give the same protocol 
error.Any help?Jim S.


On Saturday, April 9, 2016 11:25 PM, "Mahan, Patrick" 
<patrick.ma...@caviumnetworks.com> wrote:


 Jim,

Okay, that’s better.

So now I would suggest looking at the BIOS/UEFI setup screens for any hints 
about enabling the network or
enabling network booting.

For example, I have a DELL 5810 Precision Tower that I am currently using for 
UEFI testing.  To enable the
network stack and PXE booting, I have to go to the config screen that shows the 
onboard NIC config and
enable the Network stack and PXE booting.  Not sure what the Insyde screens 
show, but a quick google-foo
seems to show that PXE is enabled on the ‘Boot’ config.  I would look for any 
manual you might have for
configuring the BIOS/UEFI.

Now here is the problem.  You can load the UNDI driver by copying it to your 
EFI directory on boot device.
For most Linux systems, this is /boot/efi/EFI/ (e.g. 
/boot/efi/EFI/ubuntu or /boot/efi/EFI/centos).

Then start the EFI shell, and in that shell use the ‘load’ command to load the 
UNDI driver, probably from
fs0:\EFI\\.efi, then exit the shell and back in the boot menu 
you should be able to add
the new NIC.  The assumption here is that when you exit the EFI shell you fall 
back into the boot menu,
which is not the case on the DELL I am using.

If this doesn’t work, then I suggest first contacting the AMD SOC support or 
the Insyde folks.

Good luck,

Patrick

> On Apr 9, 2016, at 8:00 PM, Jim Slaughter <jwslau...@yahoo.com> wrote:
>
> I downloaded there binary as they do not have the source listed,
> UEFI UNDI Driver
> from  
> http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1=13=5=5=4=3=false
> We are using there chip on out board.
> If I do an "ifconfig" command (no arguments) I get the following:ifconfig: 
> "Locate protocol error - ip4Cofi Protocol"
> Something is missing I think? No ifconfig's work.
> Jim Slaughter
>
>
>    On Saturday, April 9, 2016 9:29 AM, "Mahan, Patrick" 
><patrick.ma...@caviumnetworks.com> wrote:
>
>
> Jim,
>
> What exactly did you download?  If I google ‘realtek refi’ I get the realtek 
> refi undo driver as a UEFI binary (*.efi) but
> no source code.
>
> So I am not sure what you have exactly.  If it is source code then it should 
> be a UEFI package which should contain
> all the files to build the NIC.
>
> If you haven’t already, you can take a look at how to get started developing 
> in UEFI at the following URL -
>
> https://github.com/tianocore/tianocore.github.io/wiki/Getting%20Started%20with%20EDK%20II
>
> (UEFI is based on EDK II)
>
> I personally have never gotten ‘ipconfig’ to work, I instead use ‘ifconfig’.  
> Do a ‘ifconfig -?’ for help.
>
> Patrick
>
>> On Apr 8, 2016, at 3:57 PM, Jim Slaughter <jwslau...@yahoo.com> wrote:
>>
>> Hello,
>> The platform is an AMD based SOC. The uEFI is from Insyde. Yes I do have a 
>> uEFI shell.
>> When I downloaded the C driver there were no instructions. I have not yet 
>> configured the card. I have not seen any instructions on how to configure. 
>> ipconfig does not work.
>> Jim S.
>>
>>
>>    On Friday, April 8, 2016 3:40 PM, "Mahan, Patrick" 
>><patrick.ma...@caviumnetworks.com> wrote:
>>
>>
>>
>> Jim,
>>
>> This depends on a number of factors:
>>
>> 1. What platform?  Who wrote the UEFI code for it?  Do you have access to a 
>> EFI or UEFI shell?
>>
>> 2. I'm not sure about the Realtek NIC, but did they have any instructions 
>> for using the driver?  UEFI supports
>>    having device specific directories that a Vendor may populate with their 
>>driver.  That might be the case for
>>    Realtek.
>>
>> 3. Go into your UEFI config (again this depends upon whose UEFI is running) 
>> and make sure you

Re: [edk2] TCPIP Client for UEFI

[Mahan, Patrick]

Jim,

Okay, that’s better.

So now I would suggest looking at the BIOS/UEFI setup screens for any hints 
about enabling the network or
enabling network booting.

For example, I have a DELL 5810 Precision Tower that I am currently using for 
UEFI testing.  To enable the
network stack and PXE booting, I have to go to the config screen that shows the 
onboard NIC config and
enable the Network stack and PXE booting.  Not sure what the Insyde screens 
show, but a quick google-foo
seems to show that PXE is enabled on the ‘Boot’ config.  I would look for any 
manual you might have for 
configuring the BIOS/UEFI.

Now here is the problem.  You can load the UNDI driver by copying it to your 
EFI directory on boot device.
For most Linux systems, this is /boot/efi/EFI/ (e.g. 
/boot/efi/EFI/ubuntu or /boot/efi/EFI/centos).

Then start the EFI shell, and in that shell use the ‘load’ command to load the 
UNDI driver, probably from
fs0:\EFI\\.efi, then exit the shell and back in the boot menu 
you should be able to add
the new NIC.  The assumption here is that when you exit the EFI shell you fall 
back into the boot menu,
which is not the case on the DELL I am using.

If this doesn’t work, then I suggest first contacting the AMD SOC support or 
the Insyde folks.

Good luck,

Patrick

> On Apr 9, 2016, at 8:00 PM, Jim Slaughter <jwslau...@yahoo.com> wrote:
> 
> I downloaded there binary as they do not have the source listed,
> UEFI UNDI Driver 
> from   
> http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1=13=5=5=4=3=false
> We are using there chip on out board.
> If I do an "ifconfig" command (no arguments) I get the following:ifconfig: 
> "Locate protocol error - ip4Cofi Protocol"
> Something is missing I think? No ifconfig's work.
> Jim Slaughter
> 
> 
>On Saturday, April 9, 2016 9:29 AM, "Mahan, Patrick" 
> <patrick.ma...@caviumnetworks.com> wrote:
> 
> 
> Jim,
> 
> What exactly did you download?  If I google ‘realtek refi’ I get the realtek 
> refi undo driver as a UEFI binary (*.efi) but 
> no source code.
> 
> So I am not sure what you have exactly.  If it is source code then it should 
> be a UEFI package which should contain
> all the files to build the NIC.
> 
> If you haven’t already, you can take a look at how to get started developing 
> in UEFI at the following URL -
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Getting%20Started%20with%20EDK%20II
> 
> (UEFI is based on EDK II)
> 
> I personally have never gotten ‘ipconfig’ to work, I instead use ‘ifconfig’.  
> Do a ‘ifconfig -?’ for help.
> 
> Patrick
> 
>> On Apr 8, 2016, at 3:57 PM, Jim Slaughter <jwslau...@yahoo.com> wrote:
>> 
>> Hello,
>> The platform is an AMD based SOC. The uEFI is from Insyde. Yes I do have a 
>> uEFI shell.
>> When I downloaded the C driver there were no instructions. I have not yet 
>> configured the card. I have not seen any instructions on how to configure. 
>> ipconfig does not work.
>> Jim S.
>> 
>> 
>> On Friday, April 8, 2016 3:40 PM, "Mahan, Patrick" 
>> <patrick.ma...@caviumnetworks.com> wrote:
>> 
>> 
>> 
>> Jim,
>> 
>> This depends on a number of factors:
>> 
>> 1. What platform?  Who wrote the UEFI code for it?  Do you have access to a 
>> EFI or UEFI shell?
>> 
>> 2. I'm not sure about the Realtek NIC, but did they have any instructions 
>> for using the driver?  UEFI supports
>> having device specific directories that a Vendor may populate with their 
>> driver.  That might be the case for
>> Realtek.
>> 
>> 3. Go into your UEFI config (again this depends upon whose UEFI is running) 
>> and make sure you have enabled
>> the network stack.
>> 
>> Always be specific in details, it makes it easier to provide you help,
>> 
>> Thanks,
>> 
>> Patrick
>> 
>> 
>> From: edk2-devel <edk2-devel-boun...@lists.01.org> on behalf of Jim 
>> Slaughter <jwslau...@yahoo.com>
>> Sent: Friday, April 8, 2016 3:27 PM
>> To: Edk2-devel
>> Subject: [edk2] TCPIP Client for UEFI
>> 
>> Hello,I downloaded and installed a NIC driver from Realtek for uEFI.I need a 
>> TCPIP client so I can do a dhcp.Where do I find this client?Do I need any 
>> other softwareJim Slaughter
>> 
>> ___
>> 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-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

Re: [edk2] TCPIP Client for UEFI

[Mahan, Patrick]

Jim,

What exactly did you download?  If I google ‘realtek refi’ I get the realtek 
refi undo driver as a UEFI binary (*.efi) but 
no source code.

So I am not sure what you have exactly.  If it is source code then it should be 
a UEFI package which should contain
all the files to build the NIC.

If you haven’t already, you can take a look at how to get started developing in 
UEFI at the following URL -

https://github.com/tianocore/tianocore.github.io/wiki/Getting%20Started%20with%20EDK%20II

(UEFI is based on EDK II)

I personally have never gotten ‘ipconfig’ to work, I instead use ‘ifconfig’.  
Do a ‘ifconfig -?’ for help.

Patrick
 
> On Apr 8, 2016, at 3:57 PM, Jim Slaughter <jwslau...@yahoo.com> wrote:
> 
> Hello,
> The platform is an AMD based SOC. The uEFI is from Insyde. Yes I do have a 
> uEFI shell.
> When I downloaded the C driver there were no instructions. I have not yet 
> configured the card. I have not seen any instructions on how to configure. 
> ipconfig does not work.
> Jim S.
> 
> 
>    On Friday, April 8, 2016 3:40 PM, "Mahan, Patrick" 
> <patrick.ma...@caviumnetworks.com> wrote:
> 
> 
> 
> Jim,
> 
> This depends on a number of factors:
> 
> 1. What platform?  Who wrote the UEFI code for it?  Do you have access to a 
> EFI or UEFI shell?
> 
> 2. I'm not sure about the Realtek NIC, but did they have any instructions for 
> using the driver?  UEFI supports
> having device specific directories that a Vendor may populate with their 
> driver.  That might be the case for
> Realtek.
> 
> 3. Go into your UEFI config (again this depends upon whose UEFI is running) 
> and make sure you have enabled
> the network stack.
> 
> Always be specific in details, it makes it easier to provide you help,
> 
> Thanks,
> 
> Patrick
> 
> 
> From: edk2-devel <edk2-devel-boun...@lists.01.org> on behalf of Jim Slaughter 
> <jwslau...@yahoo.com>
> Sent: Friday, April 8, 2016 3:27 PM
> To: Edk2-devel
> Subject: [edk2] TCPIP Client for UEFI
> 
> Hello,I downloaded and installed a NIC driver from Realtek for uEFI.I need a 
> TCPIP client so I can do a dhcp.Where do I find this client?Do I need any 
> other softwareJim Slaughter
> 
> ___
> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] TCPIP Client for UEFI

[Mahan, Patrick]

Jim,

This depends on a number of factors:

1. What platform?  Who wrote the UEFI code for it?  Do you have access to a EFI 
or UEFI shell?

2. I'm not sure about the Realtek NIC, but did they have any instructions for 
using the driver?  UEFI supports
 having device specific directories that a Vendor may populate with their 
driver.  That might be the case for
 Realtek.

3. Go into your UEFI config (again this depends upon whose UEFI is running) and 
make sure you have enabled
 the network stack.

Always be specific in details, it makes it easier to provide you help,

Thanks,

Patrick


From: edk2-devel  on behalf of Jim Slaughter 

Sent: Friday, April 8, 2016 3:27 PM
To: Edk2-devel
Subject: [edk2] TCPIP Client for UEFI

 Hello,I downloaded and installed a NIC driver from Realtek for uEFI.I need a 
TCPIP client so I can do a dhcp.Where do I find this client?Do I need any other 
softwareJim Slaughter

___
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

Re: [edk2] How to initiate a PXE boot from the UEFI shell

[Mahan, Patrick]

Just wanted to update the list that I managed to do  a PXE boot from the EFI 
Shell using the MdeModulePkg Application BootManagerMenuApp.  It required some 
defensive code in my drivers Start() routine and loading the driver in the 
shell but *not* connecting it.

The downside is that it trashes my NVRAM, but I can live with that as this is 
just needed for a 1 time demo to a
customer.

This is happening on a 
 DELL 5810 Tower
 AMI UEFI firmware based on EFI Spec 2.13, revision 5.9.
 Ubuntu 14.04.4 LTS

Moving forward, I believe I am going to follow the suggestions of Laszlo Ersek 
and try to use the suggested 
QEMU+KVM+VIRTIO enviornment for future testing.

Thanks,

Patrick

From: edk2-devel <edk2-devel-boun...@lists.01.org> on behalf of Mahan, Patrick 
<patrick.ma...@caviumnetworks.com>
Sent: Wednesday, March 30, 2016 1:35 PM
To: Andrew Fish
Cc: Carsey, Jaben; edk2-devel@lists.01.org
Subject: Re: [edk2] How to initiate a PXE boot from the UEFI shell

Andrew,

Thanks, I suspect that I might need to roll my own on this.

WRT option rom, that is coming on the next revision of the NIC hardware, but I 
am currently having to make do on a NIC that does not have a working option 
rom.  That will be the next step, but I have been asked to do a demo, hence the 
looking for a method that can work via the Shell.

You specified the bcfg command which is only in the UEFI shell (ShellBinPkg).  
I have been currently using EFI shell (EdkShellBinPkg) because of a bug in the 
UEFI shell prevents me from using the shift key.  It does not look supported 
there.  However, thanks for the tip on gBS->LoadImage() and gBS->StartImage() 
so I can go attempt my own solution.

Again, thanks,

Patrick


From: af...@apple.com <af...@apple.com> on behalf of Andrew Fish 
<af...@apple.com>
Sent: Wednesday, March 30, 2016 12:44 PM
To: Mahan, Patrick
Cc: Carsey, Jaben; edk2-devel@lists.01.org
Subject: Re: [edk2] How to initiate a PXE boot from the UEFI shell

> On Mar 30, 2016, at 11:14 AM, Mahan, Patrick 
> <patrick.ma...@caviumnetworks.com> wrote:
>
> I'm trying to understand what the ipconfig -r command means, the help states 
> that it restarts the PXE base code and DHCP settings.
>
> There is also a '-c Instance' option that I am not sure about.  But this 
> looks like my best hope.
>

Patrick,

In UEFI the drivers (Option ROMs) don't support directly booting and they are 
not allowed to present a user interface. The boot policy is 100% controlled by 
the platform.

The method to control boot policy that is in the UEFI spec are the NVRAM 
variables. You can read about this in "Chapter 3 Boot Manager" in the UEFI 
specification.

I think you will find that ipconfig only allows configuring the networking 
stack, but in EFI the network stack does not boot. All the EFI Networking stack 
does is produce an EFI_LOAD_FILE_PROTOCOL.

If you want to simulate a PXE Boot from the shell you need to write some code 
and do a gBS->LoadImage(), gBS->StartImage(). You can read about that in "6.4 
Image Services" in the UEFI specification.

You might be able to use the shell `bcfg boot addh <handle#> "desc"` to set a 
PXE Boot option from the shell. The handle# would be the network handle that 
produces the Load File protocol.

Thanks,

Andrew Fish

> Patrick
>
> ____________
> From: Carsey, Jaben <jaben.car...@intel.com>
> Sent: Wednesday, March 30, 2016 10:15 AM
> To: Mahan, Patrick; edk2-devel@lists.01.org
> Cc: Carsey, Jaben
> Subject: RE: How to initiate a PXE boot from the UEFI shell
>
> If your BDS supports PXE booting, you should be able to "exit" the shell and 
> then use BDS to initiate a PXE boot..
>
> I think you're right that there is no built in command to initiate a PXE 
> boot.  There is no command to initiate any boot type.
>
> -Jaben
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Mahan, Patrick
>> Sent: Wednesday, March 30, 2016 9:25 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] How to initiate a PXE boot from the UEFI shell
>> Importance: High
>>
>> All,
>>
>> I am testing a the UEFI driver for our new NIC and can load it via the UEFI 
>> shell,
>> ifconfig it and ping across it.  However, I now need to somehow perform a PXE
>> boot but I don't see any instructions or shell commands for doing this.  I 
>> did
>> find some (old) references back to the 2.0.0.1 release, but that is about it.
>>
>> Any pointers are welcome.
>>
>> Thanks,
>>
>> Patrick
>> ___
>> edk2-devel mailing list
>&

Re: [edk2] Variable storage

[Mahan, Patrick]

Laszlo,

That definitely helps,

Thanks,

Patrick


From: Laszlo Ersek <ler...@redhat.com>
Sent: Sunday, April 3, 2016 1:31 AM
To: Mahan, Patrick
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] Variable storage

On 04/03/16 00:05, Mahan, Patrick wrote:
> In the UEFI 2.5 Specification, in Section 7.2 on Variable runtime
> services, it states: “Although the implementation of variable storage
> is not defined in this specification, …”  But does not talk about any
> document that describes this storage.
>
> When I issue a ‘dmpstore’ it shows a bunch of hex data, that I can
> somewhat parse, based on a set of slides titled “What They Never
> Taught You in UEFI 101” by Tim Lewis.  But I am still looking around
> for the format.  I am guessing from the UEFI documentation that this
> is platform specific?
>
> Any pointers would be appreciated.

The variable services are implemented by a stack of drivers (note that
below I'm not distinguishing (a) edk2 from (b) a UEFI system without PI
compatibility from (c) a UEFI system with PI compatibility):

- The flash driver (which is platform specific), producing
  EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL or
  EFI_FIRMWARE_VOLUME_BLOC2K_PROTOCOL. You can read about the latter in
  Vol3 of the Platform Init spec.

- The Fault Tolerant Write driver, producing
  EFI_FAULT_TOLERANT_WRITE_PROTOCOL. This protocol is not standard (it
  is edk2-specific), but the driver that provides it is platform-
  independent. It lives in
  "MdeModulePkg/Universal/FaultTolerantWriteDxe".

- The variable driver, producing EFI_VARIABLE_ARCH_PROTOCOL and
  EFI_VARIABLE_WRITE_ARCH_PROTOCOL. You can read about them in Vol2 of
  the Platform Init spec. The edk2 implementation is platform-
  independent and lives in "MdeModulePkg/Universal/Variable/RuntimeDxe".

You might also be interested in the Intel whitepaper

  A Tour Beyond BIOS
  Implementing UEFI Authenticated Variables in SMM with EDKII

(esp. "Part III - Variable".)


As far as I remember (and according to the UEFI Shell spec), the UEFI
Shell's DMPSTORE command hex-dumps the UEFI variable values -- it
consumes the UEFI variable services. So, if you'd like to understand
that output, you will have to look at the specs of the individual
variables (meaning one more abstraction on top of the last one above).

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

[edk2] Variable storage

[Mahan, Patrick]

In the UEFI 2.5 Specification, in Section 7.2 on Variable runtime services, it 
states: “Although the implementation of variable storage is not defined in this 
specification, …”  But does not talk about any document that describes this 
storage.

When I issue a ‘dmpstore’ it shows a bunch of hex data, that I can somewhat 
parse, based on a set of slides titled “What They Never Taught You in UEFI 101” 
by Tim Lewis.  But I am still looking around for the format.  I am guessing 
from the UEFI documentation that this is platform specific?

Any pointers would be appreciated.

Thanks,

Patrick

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

Re: [edk2] Building the ShellPkg

[Mahan, Patrick]

Ard,

I thought of that, but was a bit nervous about symlinking stuff here.  But it 
is a good suggestion and I will
do this to avoid future issues.

Patrick


From: Ard Biesheuvel <ard.biesheu...@linaro.org>
Sent: Thursday, March 31, 2016 8:47 AM
To: Mahan, Patrick
Cc: David Van Arnem; edk2-devel@lists.01.org
Subject: Re: [edk2] Building the ShellPkg

On 31 March 2016 at 17:39, Mahan, Patrick
<patrick.ma...@caviumnetworks.com> wrote:
> David,
>
> Thanks, that is exactly what was needed.
>
> (Writing that one down in my tips and tricks for UEFI)
>

Hi Patrick,

If you are on Linux, the simplest way to work around this is to
symlink Conf/tools_def.txt to BaseTools/Conf/tools_def.template. That
way, you will always have the latest code.

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

Re: [edk2] Recommend platforms for doing Intel UEFI driver development

[Mahan, Patrick]

Laszlo,

What is FLR, I must admit my ignorance to that acronym.

I'm not fully up on using a VM as s development environment.  Does the NIC need 
to have it's linux driver loaded
on the linux hypervisor?  Or can the VM access the PCIe directly?

Can VirtualBox be used (I already have it for another on going project), but I 
can go to QEMU.  I am running Ubuntu 14.04.4 currently, though my kernel guy is 
telling me I need to switch to Redhat :-).

Thanks for the pointers,

Patrick


From: Laszlo Ersek <ler...@redhat.com>
Sent: Thursday, March 31, 2016 12:34 PM
To: Mahan, Patrick
Cc: edk2-devel@lists.01.org; Alex Williamson
Subject: Re: [edk2] Recommend platforms for doing Intel UEFI driver development

On 03/31/16 20:52, Mahan, Patrick wrote:
> I believe I have seen this mentioned here before, but I cannot find the 
> answer via google or gmane.  But
> there was a developer package that consisted of an Intel motherboard and 
> software that allowed you to
> do UEFI Driver development.  Not sure but I seem to recall it was some 
> third-party.
>
> What are the recommend platforms for doing Intel 32/64 UEFI driver 
> development.
>
> Note: I am currently working on a Dell 5810 running UEFI from AMI but I am 
> having some issues like controlling
> BDS, etc.

I don't expect the following to match your use case, but for
completeness's sake, I'll recommend it anyway:

If the device that you are writing a UEFI driver for is a discrete
PCI(e) card, then chances are it will work with virtualization and
device assignment on x86_64 hosts running a fresh Linux kernel (KVM &
VFIO) and QEMU.

This could allow you to develop and run your UEFI driver on top of OVMF,
in a QEMU/KVM virtual machine. The benefits should be the usual ones of
virtualization: if you crash or need to reboot for another reason, you
can simply destroy and relaunch the VM, without power-cycling a physical
box. (VFIO should handle the resetting of the assigned physical device
for you, assuming the device supports FLR.) No need to worry about a
physical machine's filesystem(s), and so on.

You could also hack OVMF's BDS (consisting of IntelFrameworkModulePkg's
BdsDxe and OvmfPkg's PlatformBdsLib) any way you like.

Once you were pleased with the UEFI driver, you could even boot Linux or
Windows in the guest, and test the OS-native drivers. In this case,
simply forcing off and restarting the VM (if there was trouble) wouldn't
do much good to your (virtual) Linux or Windows filesystems, but then
again, you could snapshot the virtual disk in a known good state (with
the VM not running), before you start experimenting. Then, if you have
to force off the VM for any reason, you can quickly restore the virtual
disk to the known-good snapshot.

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

[edk2] Recommend platforms for doing Intel UEFI driver development

[Mahan, Patrick]

I believe I have seen this mentioned here before, but I cannot find the answer 
via google or gmane.  But
there was a developer package that consisted of an Intel motherboard and 
software that allowed you to
do UEFI Driver development.  Not sure but I seem to recall it was some 
third-party.

What are the recommend platforms for doing Intel 32/64 UEFI driver development.

Note: I am currently working on a Dell 5810 running UEFI from AMI but I am 
having some issues like controlling
BDS, etc.

Thanks,

Patrick

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

Re: [edk2] Building the ShellPkg

[Mahan, Patrick]

David,

Thanks, that is exactly what was needed.

(Writing that one down in my tips and tricks for UEFI)

Thanks,

Patrick


From: edk2-devel <edk2-devel-boun...@lists.01.org> on behalf of David Van Arnem 
<dvanar...@cmlab.biz>
Sent: Wednesday, March 30, 2016 5:42 PM
To: edk2-devel@lists.01.org
Subject: Re: [edk2] Building the ShellPkg

On 03/30/2016 05:35 PM, Mahan, Patrick wrote:
>
> Build environment:
>
> Ubuntun 14.04 LTS
> GCC v4.8
> Edk2, SVN revision 20433
> Dell 5810
>
> I am attempting to build the UEFI shell from sources so that I can debug an 
> keyboard issue (SHIFT key acts like a ).
>
> However, the ShellPkg fails during the ld, here is a snippet of the output -
>
> "ld" -o 
> /home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll
>  -nostdlib -n -q --gc-sections -z common-page-size=0x20 --entry 
> _ModuleEntryPoint -u _ModuleEntryPoint -Map 
> /home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.map
>  -melf_x86_64 --oformat=elf64-x86-64 --start-group  
> @/home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/OUTPUT/static_library_files.lst
>  --end-group --defsym=PECOFF_HEADER_SIZE=0x228 
> --script=/home/pmahan/src/EdkII/edk2/BaseTools/Scripts/GccBase.lds
> `gEfiShellProtocol' referenced in section `.text.UefiMain' of 
> /home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/OUTPUT/Shell.lib(Shell.obj):
>  defined in discarded section `COMMON' of 
> /home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Library/UefiShellLib/UefiShellLib/OUTPUT/UefiShellLib.lib(UefiShellLib.obj)
> `gEfiShellProtocol' referenced in section `.text.UefiMain' of 
> /home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/OUTPUT/Shell.lib(Shell.obj):
>  defined in discarded section `COMMON' of 
> /home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Library/UefiShellLib/UefiShellLib/OUTPUT/UefiShellLib.lib(UefiShellLib.obj)
> `gEfiShellParametersProtocol' referenced in section 
> `.text.ProcessCommandLine' of 
> /home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/OUTPUT/Shell.lib(Shell.obj):
>  defined in discarded section `COMMON' of 
> /home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Library/UefiShellLib/UefiShellLib/OUTPUT/UefiShellLib.lib(UefiShellLib.obj)
>

Hi Patrick,

This looks a lot like a problem I was having recently as well, which
occurred when I merged the UDK2015 to my local master branch which
hadn't been update for a few months.  I followed these instructions from
Ard and it fixed the problem:

"You should verify whether your Conf/tools_def.txt file is up to date.
If you don't have any local changes, you can simply remove it and
re-run 'source edksetup.sh', and it will be regenerated based on
BaseTools/Conf/tools_def.template.

Please refer to commit 214a3b79417f64bf2faae74af42c1b9d23f50dc8 for more
details "

The referenced commit describes the issue in more detail.

David

> There is a lot more, but it is basically the same message.  Googling for it 
> indicates that I may need add a __attribute__((used)) to all of these 
> elements to get the gcc to avoid "garbage-collecting".
>
> But this is the latest source (I updated today) so I am a bit surprised that 
> this is occuring.  Is it possible I am missing some detail in building?
>
> Thanks,
>
> Patrick
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>


--
Thanks,
David Van Arnem
___
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] Building the ShellPkg

[Mahan, Patrick]

Build environment:

Ubuntun 14.04 LTS
GCC v4.8
Edk2, SVN revision 20433
Dell 5810 

I am attempting to build the UEFI shell from sources so that I can debug an 
keyboard issue (SHIFT key acts like a ).

However, the ShellPkg fails during the ld, here is a snippet of the output -

"ld" -o 
/home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll
 -nostdlib -n -q --gc-sections -z common-page-size=0x20 --entry 
_ModuleEntryPoint -u _ModuleEntryPoint -Map 
/home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.map
 -melf_x86_64 --oformat=elf64-x86-64 --start-group  
@/home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/OUTPUT/static_library_files.lst
 --end-group --defsym=PECOFF_HEADER_SIZE=0x228 
--script=/home/pmahan/src/EdkII/edk2/BaseTools/Scripts/GccBase.lds
`gEfiShellProtocol' referenced in section `.text.UefiMain' of 
/home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/OUTPUT/Shell.lib(Shell.obj):
 defined in discarded section `COMMON' of 
/home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Library/UefiShellLib/UefiShellLib/OUTPUT/UefiShellLib.lib(UefiShellLib.obj)
`gEfiShellProtocol' referenced in section `.text.UefiMain' of 
/home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/OUTPUT/Shell.lib(Shell.obj):
 defined in discarded section `COMMON' of 
/home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Library/UefiShellLib/UefiShellLib/OUTPUT/UefiShellLib.lib(UefiShellLib.obj)
`gEfiShellParametersProtocol' referenced in section `.text.ProcessCommandLine' 
of 
/home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Application/Shell/Shell/OUTPUT/Shell.lib(Shell.obj):
 defined in discarded section `COMMON' of 
/home/pmahan/src/EdkII/edk2/Build/Shell/RELEASE_GCC48/X64/ShellPkg/Library/UefiShellLib/UefiShellLib/OUTPUT/UefiShellLib.lib(UefiShellLib.obj)

There is a lot more, but it is basically the same message.  Googling for it 
indicates that I may need add a __attribute__((used)) to all of these elements 
to get the gcc to avoid "garbage-collecting".

But this is the latest source (I updated today) so I am a bit surprised that 
this is occuring.  Is it possible I am missing some detail in building?

Thanks,

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

Re: [edk2] How to initiate a PXE boot from the UEFI shell

[Mahan, Patrick]

Andrew,

Thanks, I suspect that I might need to roll my own on this. 

WRT option rom, that is coming on the next revision of the NIC hardware, but I 
am currently having to make do on a NIC that does not have a working option 
rom.  That will be the next step, but I have been asked to do a demo, hence the 
looking for a method that can work via the Shell.

You specified the bcfg command which is only in the UEFI shell (ShellBinPkg).  
I have been currently using EFI shell (EdkShellBinPkg) because of a bug in the 
UEFI shell prevents me from using the shift key.  It does not look supported 
there.  However, thanks for the tip on gBS->LoadImage() and gBS->StartImage() 
so I can go attempt my own solution.

Again, thanks,

Patrick


From: af...@apple.com <af...@apple.com> on behalf of Andrew Fish 
<af...@apple.com>
Sent: Wednesday, March 30, 2016 12:44 PM
To: Mahan, Patrick
Cc: Carsey, Jaben; edk2-devel@lists.01.org
Subject: Re: [edk2] How to initiate a PXE boot from the UEFI shell

> On Mar 30, 2016, at 11:14 AM, Mahan, Patrick 
> <patrick.ma...@caviumnetworks.com> wrote:
>
> I'm trying to understand what the ipconfig -r command means, the help states 
> that it restarts the PXE base code and DHCP settings.
>
> There is also a '-c Instance' option that I am not sure about.  But this 
> looks like my best hope.
>

Patrick,

In UEFI the drivers (Option ROMs) don't support directly booting and they are 
not allowed to present a user interface. The boot policy is 100% controlled by 
the platform.

The method to control boot policy that is in the UEFI spec are the NVRAM 
variables. You can read about this in "Chapter 3 Boot Manager" in the UEFI 
specification.

I think you will find that ipconfig only allows configuring the networking 
stack, but in EFI the network stack does not boot. All the EFI Networking stack 
does is produce an EFI_LOAD_FILE_PROTOCOL.

If you want to simulate a PXE Boot from the shell you need to write some code 
and do a gBS->LoadImage(), gBS->StartImage(). You can read about that in "6.4 
Image Services" in the UEFI specification.

You might be able to use the shell `bcfg boot addh <handle#> "desc"` to set a 
PXE Boot option from the shell. The handle# would be the network handle that 
produces the Load File protocol.

Thanks,

Andrew Fish

> Patrick
>
> ____
> From: Carsey, Jaben <jaben.car...@intel.com>
> Sent: Wednesday, March 30, 2016 10:15 AM
> To: Mahan, Patrick; edk2-devel@lists.01.org
> Cc: Carsey, Jaben
> Subject: RE: How to initiate a PXE boot from the UEFI shell
>
> If your BDS supports PXE booting, you should be able to "exit" the shell and 
> then use BDS to initiate a PXE boot..
>
> I think you're right that there is no built in command to initiate a PXE 
> boot.  There is no command to initiate any boot type.
>
> -Jaben
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Mahan, Patrick
>> Sent: Wednesday, March 30, 2016 9:25 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] How to initiate a PXE boot from the UEFI shell
>> Importance: High
>>
>> All,
>>
>> I am testing a the UEFI driver for our new NIC and can load it via the UEFI 
>> shell,
>> ifconfig it and ping across it.  However, I now need to somehow perform a PXE
>> boot but I don't see any instructions or shell commands for doing this.  I 
>> did
>> find some (old) references back to the 2.0.0.1 release, but that is about it.
>>
>> Any pointers are welcome.
>>
>> Thanks,
>>
>> Patrick
>> ___
>> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] How to initiate a PXE boot from the UEFI shell

[Mahan, Patrick]

I'm trying to understand what the ipconfig -r command means, the help states 
that it restarts the PXE base code and DHCP settings.

There is also a '-c Instance' option that I am not sure about.  But this looks 
like my best hope.

Patrick


From: Carsey, Jaben <jaben.car...@intel.com>
Sent: Wednesday, March 30, 2016 10:15 AM
To: Mahan, Patrick; edk2-devel@lists.01.org
Cc: Carsey, Jaben
Subject: RE: How to initiate a PXE boot from the UEFI shell

If your BDS supports PXE booting, you should be able to "exit" the shell and 
then use BDS to initiate a PXE boot..

I think you're right that there is no built in command to initiate a PXE boot.  
There is no command to initiate any boot type.

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Mahan, Patrick
> Sent: Wednesday, March 30, 2016 9:25 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] How to initiate a PXE boot from the UEFI shell
> Importance: High
>
> All,
>
> I am testing a the UEFI driver for our new NIC and can load it via the UEFI 
> shell,
> ifconfig it and ping across it.  However, I now need to somehow perform a PXE
> boot but I don't see any instructions or shell commands for doing this.  I did
> find some (old) references back to the 2.0.0.1 release, but that is about it.
>
> Any pointers are welcome.
>
> Thanks,
>
> Patrick
> ___
> 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] How to initiate a PXE boot from the UEFI shell

[Mahan, Patrick]

All,

I am testing a the UEFI driver for our new NIC and can load it via the UEFI 
shell, ifconfig it and ping across it.  However, I now need to somehow perform 
a PXE boot but I don't see any instructions or shell commands for doing this.  
I did find some (old) references back to the 2.0.0.1 release, but that is about 
it.

Any pointers are welcome.

Thanks,

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

[edk2] Help in testing PCIe driver from UEFI shell

[Mahan, Patrick]

All,

I am looking for information on how to test our PCIe DXE driver for our NIC on 
Intel.  I am building from the latest EDK2
sources using gcc v4.8 on Ubuntu.

The 'ver' command from the UEFI shell gives -

EFI Specification Revision : 2.10
EFI Vendor  : Dell
EFI Revision: 520.1

I have created a EDK2 package as per the instuctions in section 30 of the UEFI 
Driver Writer's Guide and have created
a .efi file that I then copy to the FAT-32 partition used for EFI 
(/boot/efi/EFI/ubuntu).

I can load the driver successfully, print statements embedded show the driver's 
entry point is properly called.

However, when attempting to connect it is showing 0 for the PCI device which 
looks very suspicious to me.

Also, the shell 'pci' command does not show the NIC card, but if I boot into 
Ubuntu, lspci shows the card just fine
which leads me to suspect that the PCI bus is not being scanned.

I've been googling around for a day now and cannot find any tutorials, examples 
or notes by anyone on how to
address this issue, so I anyone has some pointers to give, I would appreciate 
it greatly (with your favorite beverage
if you wish :-) ).

Most of our initial work was done on our company's AARCH64 platform for which I 
simply included the driver's .inf
into the platform .dsc and .fdf files and it is working there.  I would like to 
move over to the Intel platform and test
there for further validation.

Thanks for any pointers,

Patrick Mahan
Cavium, Inc.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is detected

[Mahan, Patrick]

Mike,

If the option ROM is disabled, would you agree that degrading the BARs from 
64-bit to 32-bit should be skipped?

Also, if the driver is not coming from the option ROM, should the BARs still be 
degraded?

Thanks,

Patrick

From: Michael Brown <mc...@ipxe.org>
Sent: Wednesday, December 16, 2015 9:53 AM
To: El-Haj-Mahmoud, Samer; Mahan, Patrick; edk2-devel@lists.01.org
Subject: Re: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is 
detected

On 14/12/15 23:35, El-Haj-Mahmoud, Samer wrote:
> We ran into the same issue of automatic demoation simply because of the 
> presence of an OptionROM. We believe this is an overly aggressive policy. In 
> fact, I have a patch that I am about to submit that adds a platform PCD to 
> enable/disable this policy.
>
> Would like feedback on the idea as well as the patch.

 From the legacy option ROM perspective:

We currently cannot operate the NIC if the memory BAR is assigned above
4GB.  There is some potential work to run in long mode (rather than
32-bit protected mode), which would allow us to access runtime BARs
above 4GB, which would remove this limitation.

The second and harder problem comes when we need to access the contents
of the expansion ROM BAR at runtime.  This requires there to be _some_
usable address below 4GB that we can temporarily assign to the BAR (e.g.
by stealing it from another BAR on the same device, or from a BAR on
another device under the same bridge).  Note that expansion ROM BARs are
32-bit only, so even if the code is capable of running in long mode
there is still no way to assign an address over 4GB to an expansion ROM BAR.

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

Re: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is detected

[Mahan, Patrick]

Greetings Samer,

I would like to see this patch implemented.  Part of the issue I am wrestling 
with on our AARCH64 platform is how our PCIe's are supported.  In our current 
architecture, we can have up to 6 PCIe's connected through two Switch Logic 
Interfaces (SLI) that must be programmed correctly.  Part of this is the BAR 
address that is in use which depends heavily on the BAR type.  What we are 
seeing is that the BAR type
is being demoted to 32-bit which causes us to program the SLI for 32-bit 
access.  But the PCIe device is 64-bit and attempts to use 64-bit addressing 
which fails.  

A PCD that can be configured to disable the demotion based on the presence of 
an option ROM would be greatly appreciated.  Then the code in DegradeResource() 
could simply check to see if it needed to enforce this demotion or not.

I can understand if this were a legacy BIOS image as this currently seems (to 
me) to limit option ROM drivers to be 32-bit only.

As I stated below, I currently have it commented out and this is allowing our 
SLI's to be programmed correctly.

I'll be glad to review the patch when you have it ready.

Thanks,

Patrick


From: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>
Sent: Monday, December 14, 2015 3:35 PM
To: Mahan, Patrick; edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer
Subject: RE: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is 
detected

Hello Patrick,

We ran into the same issue of automatic demoation simply because of the 
presence of an OptionROM. We believe this is an overly aggressive policy. In 
fact, I have a patch that I am about to submit that adds a platform PCD to 
enable/disable this policy.

Would like feedback on the idea as well as the patch.

Thanks,
--Samer


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Mahan, 
Patrick
Sent: Monday, December 14, 2015 4:13 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Regarding the demotion of 64-bit BARs when an option ROM is 
detected

All,

I am working on writing the UEFI driver for our LiquidIO line of NICs and have 
run into an issue with the PCI layer that may or may not be contributing.

I am working with our AARCH64 platform, ThunderX and in the handling of the 
PCIe detection.  The code that handles the PCI configuration on ThunderX 
requires knowing the resource type of a BAR (IO16, IO32, MEM32/PMEM32, 
MEM64/PMEM64).

There is an automatic demotion of BAR types from 64-bit to 32-bit if an option 
ROM is detected.  I am trying to understand the logic behind this as I do not 
see anything in the PCIe Firmware specification (Section 5) nor the UEFI 
Specification (Section 13.4.2).  However, after inserting some debugging code 
into the PCI code under MdeModulePkg/Bus/Pci/PciBusDxe I see that my device's 
BAR goes from a
PMEM64 to a MEM32 after calling DegradeResource().

As a result, the BAR type has changed from MEM64/PMEM64 to MEM32/PMEM32 and 
this is causing some problems with properly configuring the PCI layer to handle 
devices using 64-bit PCI BARs.  I have put a PCIe Analyzer on it and I can see 
that the memory requests to the PCI device have the incorrect BAR address 
resulting in the PCI device unable to read from the host.

If I modify the call to DegradeResource() to avoid degrading the 64-bit bar to 
32-bit bar when an option ROM is detected, then 64-bit devices work correctly.

I can see if the option ROM contained a legacy image, but if it does not, or 
the option ROM is empty or disabled, then why degrade the BAR resource?

Thanks for any help understanding this,

Patrick Mahan
Cavium, Inc.
___
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] Regarding the demotion of 64-bit BARs when an option ROM is detected

[Mahan, Patrick]

All,

I am working on writing the UEFI driver for our LiquidIO line of NICs and have 
run into an issue with
the PCI layer that may or may not be contributing.

I am working with our AARCH64 platform, ThunderX and in the handling of the 
PCIe detection.  The
code that handles the PCI configuration on ThunderX requires knowing the 
resource type of a BAR
(IO16, IO32, MEM32/PMEM32, MEM64/PMEM64).

There is an automatic demotion of BAR types from 64-bit to 32-bit if an option 
ROM is detected.  I am
trying to understand the logic behind this as I do not see anything in the PCIe 
Firmware specification
(Section 5) nor the UEFI Specification (Section 13.4.2).  However, after 
inserting some debugging code
into the PCI code under MdeModulePkg/Bus/Pci/PciBusDxe I see that my device's 
BAR goes from a 
PMEM64 to a MEM32 after calling DegradeResource().

As a result, the BAR type has changed from MEM64/PMEM64 to MEM32/PMEM32 and 
this is causing
some problems with properly configuring the PCI layer to handle devices using 
64-bit PCI BARs.  I have
put a PCIe Analyzer on it and I can see that the memory requests to the PCI 
device have the incorrect
BAR address resulting in the PCI device unable to read from the host.

If I modify the call to DegradeResource() to avoid degrading the 64-bit bar to 
32-bit bar when an option
ROM is detected, then 64-bit devices work correctly.

I can see if the option ROM contained a legacy image, but if it does not, or 
the option ROM is empty or
disabled, then why degrade the BAR resource?

Thanks for any help understanding this,

Patrick Mahan
Cavium, Inc.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel