Re: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from IntelFrameworkModulePkg

[Ni, Ruiyu]

Jordan,
I see lots of comments raised from you. Can you list all of your concerns which 
may result changing the patch?
Because I do not have any idea what your intention is for the following words.
" Those existing drivers also have the IntelFrameworkModulePkg.dec
listed, so they can easily continue to use the OEMBadging protocol
until they are updated for the MdeModulePkg version."
" I never know the rules for MdePkg and MdeModulePkg. They seem to be
arbitrarily applied anyhow."


Thanks,
Ray

-Original Message-
From: Justen, Jordan L 
Sent: Tuesday, September 29, 2015 12:08 PM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Cc: Tian, Feng ; Fan, Jeff ; Kinney, 
Michael D ; Gao, Liming 
Subject: RE: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from 
IntelFrameworkModulePkg

On 2015-09-28 19:32:25, Ni, Ruiyu wrote:
> Jordan,
> I forgot to include the OEMBadging.h in the patch. But yes the file
> will be moved to MdeModulePkg/Include/Protocol/OEMBadging.h.

I think the patch should be resubmitted to correct this.

> I didn't change the name in order to maintain the best backward
> compatibililty.

Why is this required, or desirable?

This seems like an opportunity to clean it up.

> Those existing drivers which produce the protocol doesn't need to
> change. (most of them already have MdeModulePkg.dec dependency in
> the INF file).

Those existing drivers also have the IntelFrameworkModulePkg.dec
listed, so they can easily continue to use the OEMBadging protocol
until they are updated for the MdeModulePkg version.

> No it's not a spec defined protocol. so it's in MdeModulePkg. What's
> your concerns for this?

I never know the rules for MdePkg and MdeModulePkg. They seem to be
arbitrarily applied anyhow.

-Jordan

> -Original Message-
> From: Justen, Jordan L 
> Sent: Tuesday, September 29, 2015 2:01 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Tian, Feng ; Fan, 
> Jeff ; Kinney, Michael D ; 
> Gao, Liming 
> Subject: Re: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from 
> IntelFrameworkModulePkg
> 
> It doesn't look like you actually moved
> IntelFrameworkModulePkg/Include/Protocol/OEMBadging.h.
> 
> Is the name 'OEMBadging' appropriate?
> 
> For one, I think the code style would indicate OemBadging should be
> used instead.
> 
> Second, I don't think 'OEM' should be used in the name.
> 
> Third, I guess this doesn't have to be a spec'd protocol because it is
> in MdeModulePkg? (As opposed to MdePkg?)
> 
> -Jordan
> 
> On 2015-09-24 23:49:31, Ruiyu Ni wrote:
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni 
> > Cc: Feng Tian 
> > Cc: Jeff Fan 
> > ---
> >  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec | 4 
> >  MdeModulePkg/MdeModulePkg.dec   | 4 
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec 
> > b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > index 8bbde8e..3d6c46e 100644
> > --- a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > +++ b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > @@ -95,10 +95,6 @@
> >#  Include/Protocol/Ps2Policy.h
> >gEfiPs2PolicyProtocolGuid  = { 0x4DF19259, 0xDC71, 0x4D46, { 0xBE, 
> > 0xF1, 0x35, 0x7B, 0xB5, 0x78, 0xC4, 0x18 }}
> >  
> > -  ## OEM Badging Protocol defines the interface to get the OEM badging 
> > image with the dispaly attribute.
> > -  #  Include/Protocol/OEMBadging.h
> > -  gEfiOEMBadgingProtocolGuid = { 0x170E13C0, 0xBF1B, 0x4218, { 0x87, 
> > 0x1D, 0x2A, 0xBD, 0xC6, 0xF8, 0x87, 0xBC }}
> > -
> >## Include/Protocol/ExitPmAuth.h
> >gExitPmAuthProtocolGuid= { 0xd088a413, 0xa70, 0x4217, { 0xba, 
> > 0x55, 0x9a, 0x3c, 0xb6, 0x5c, 0x41, 0xb3 }}
> >  
> > diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> > index 3dfcd6a..862b993 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -449,6 +449,10 @@
> >## Include/Protocol/SmmReadyToBoot.h
> >gEdkiiSmmReadyToBootProtocolGuid = { 0x6e057ecf, 0xfa99, 0x4f39, { 0x95, 
> > 0xbc, 0x59, 0xf9, 0x92, 0x1d, 0x17, 0xe4 } }
> >  
> > +  ## OEM Badging Protocol defines the interface to get the OEM badging 
> > image with the dispaly attribute.
> > +  #  Include/Protocol/OEMBadging.h
> > +  gEfiOEMBadgingProtocolGuid = { 0x170E13C0, 0xBF1B, 0x4218, { 0x87, 
> > 0x1D, 0x2A, 0xBD, 0xC6, 0xF8, 0x87, 0xBC }}
> > +
> >  #
> >  # [Error.gEfiMdeModulePkgTokenSpaceGuid]
> >  #   0x8001 | Invalid value provided.
> > -- 
> > 1.9.5.msysgit.1
> > 
> > ___
> 

Re: [edk2] [Patch 2/5] MdeModulePkg: Add ImageDecoderLib to provide image decoding service.

[Jordan Justen]

On 2015-09-28 19:35:07, Ni, Ruiyu wrote:
> Jordan,
> The NULL class library which provides real image decoding capability
> should be able to detect the image format and decide to decode it or
> not.

I don't know that every format we'll ever want to support can be
autodetected. Why not add a parameter of EFI_BADGING_FORMAT? If
EfiBadgingFormatUnknown is provided, then the decode library can
optionally support auto-detecting the image type.

-Jordan

> And it can also work with LogoLib::EnableQuietBoot() which supports
> caller supply a PCD pointing to an image file.
> 
> Thanks,
> Ray
> 
> -Original Message-
> From: Justen, Jordan L 
> Sent: Tuesday, September 29, 2015 2:11 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Tian, Feng 
> Subject: Re: [edk2] [Patch 2/5] MdeModulePkg: Add ImageDecoderLib to provide 
> image decoding service.
> 
> On 2015-09-24 23:49:32, Ruiyu Ni wrote:
> > The library itself doesn't provide any image decoding capabilities but
> > manages the different image decoders.
> > 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni 
> > Cc: Feng Tian 
> > ---
> >  MdeModulePkg/Include/Library/ImageDecoderLib.h |  72 +
> >  .../Library/ImageDecoderLib/ImageDecoderLib.c  | 119 
> > +
> >  .../Library/ImageDecoderLib/ImageDecoderLib.inf|  42 
> >  MdeModulePkg/MdeModulePkg.dec  |   4 +
> >  MdeModulePkg/MdeModulePkg.dsc  |   2 +
> >  5 files changed, 239 insertions(+)
> >  create mode 100644 MdeModulePkg/Include/Library/ImageDecoderLib.h
> >  create mode 100644 MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.c
> >  create mode 100644 MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.inf
> > 
> > diff --git a/MdeModulePkg/Include/Library/ImageDecoderLib.h 
> > b/MdeModulePkg/Include/Library/ImageDecoderLib.h
> > new file mode 100644
> > index 000..522e3cf
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Library/ImageDecoderLib.h
> > @@ -0,0 +1,72 @@
> > +/** @file
> > +  This library provides image decoding service by managing the different
> > +  image decoding libraries.
> > +
> > +Copyright (c) 2015, Intel Corporation. All rights reserved.
> > +This program and the accompanying materials are licensed and made 
> > available under
> > +the terms and conditions of the BSD License that accompanies this 
> > distribution.
> > +The full text of the license may be found at
> > +http://opensource.org/licenses/bsd-license.php.
> > +
> > +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> > +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> > IMPLIED.
> > +
> > +**/
> > +#ifndef __IMAGE_DECODER_LIB_H__
> > +#define __IMAGE_DECODER_LIB_H__
> > +
> > +typedef
> > +EFI_STATUS
> > +(EFIAPI *DECODE_IMAGE)(
> > +  IN  UINT8 *Image,
> > +  IN  UINTN ImageSize,
> > +  OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL **GopBlt,
> > +  OUT UINTN *GopBltSize,
> > +  OUT UINTN *PixelWidth,
> > +  OUT UINTN *PixelHeight
> > +  );
> 
> Shouldn't the image format be an input?
> 
> > +/**
> > +  Convert a graphics image to a callee allocated GOP blt buffer.
> > +
> > +  @param  Image Pointer to image file
> > +  @param  ImageSize Number of bytes in Image
> > +  @param  GopBltBuffer containing GOP version of Image.
> > +  @param  GopBltSizeSize of GopBlt in bytes.
> > +  @param  PixelWidthWidth of GopBlt/Image in pixels.
> > +  @param  PixelHeight   Height of GopBlt/Image in pixels.
> > +
> > +  @retval EFI_SUCCESS   GopBlt and GopBltSize are returned.
> > +  @retval EFI_INVALID_PARAMETER GopBlt or GopBltSize is NULL.
> > +  @retval EFI_INVALID_PARAMETER Image is NULL or ImageSize is 0.
> > +  @retval EFI_UNSUPPORTED   Image is not supported.
> > +  @retval EFI_OUT_OF_RESOURCES  No enough buffer to allocate.
> > +
> > +**/
> > +EFI_STATUS
> > +EFIAPI
> > +DecodeImage (
> > +  IN  UINT8 *Image,
> > +  IN  UINTN ImageSize,
> > +  OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL **GopBlt,
> > +  OUT UINTN *GopBltSize,
> > +  OUT UINTN *PixelWidth,
> > +  OUT UINTN *PixelHeight
> > +  );
> 
> And here too.
> 
> -Jordan
> 
> > +/**
> > +  Register an image decoder.
> > +
> > +  @param Decoder  An image decoder.
> > +
> > +  @retval EFI_SUCCESS  The decoder was successfully registered.
> > +  @retval EFI_OUT_OF_RESOURCES No enough resource to register the decoder.
> > +
> > +**/
> > +EFI_STATUS
> > +EFIAPI
> > +RegisterImageDecoder (
> > +  IN  DECODE_IMAGE Decoder
> > +  );
> > +
> > +#endif
> > diff --git 

Re: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from IntelFrameworkModulePkg

[Jordan Justen]

On 2015-09-28 19:32:25, Ni, Ruiyu wrote:
> Jordan,
> I forgot to include the OEMBadging.h in the patch. But yes the file
> will be moved to MdeModulePkg/Include/Protocol/OEMBadging.h.

I think the patch should be resubmitted to correct this.

> I didn't change the name in order to maintain the best backward
> compatibililty.

Why is this required, or desirable?

This seems like an opportunity to clean it up.

> Those existing drivers which produce the protocol doesn't need to
> change. (most of them already have MdeModulePkg.dec dependency in
> the INF file).

Those existing drivers also have the IntelFrameworkModulePkg.dec
listed, so they can easily continue to use the OEMBadging protocol
until they are updated for the MdeModulePkg version.

> No it's not a spec defined protocol. so it's in MdeModulePkg. What's
> your concerns for this?

I never know the rules for MdePkg and MdeModulePkg. They seem to be
arbitrarily applied anyhow.

-Jordan

> -Original Message-
> From: Justen, Jordan L 
> Sent: Tuesday, September 29, 2015 2:01 AM
> To: Ni, Ruiyu ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Tian, Feng ; Fan, 
> Jeff ; Kinney, Michael D ; 
> Gao, Liming 
> Subject: Re: [edk2] [Patch 1/5] MdeModulePkg: Move OEMBadging protocol from 
> IntelFrameworkModulePkg
> 
> It doesn't look like you actually moved
> IntelFrameworkModulePkg/Include/Protocol/OEMBadging.h.
> 
> Is the name 'OEMBadging' appropriate?
> 
> For one, I think the code style would indicate OemBadging should be
> used instead.
> 
> Second, I don't think 'OEM' should be used in the name.
> 
> Third, I guess this doesn't have to be a spec'd protocol because it is
> in MdeModulePkg? (As opposed to MdePkg?)
> 
> -Jordan
> 
> On 2015-09-24 23:49:31, Ruiyu Ni wrote:
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Ruiyu Ni 
> > Cc: Feng Tian 
> > Cc: Jeff Fan 
> > ---
> >  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec | 4 
> >  MdeModulePkg/MdeModulePkg.dec   | 4 
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec 
> > b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > index 8bbde8e..3d6c46e 100644
> > --- a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > +++ b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> > @@ -95,10 +95,6 @@
> >#  Include/Protocol/Ps2Policy.h
> >gEfiPs2PolicyProtocolGuid  = { 0x4DF19259, 0xDC71, 0x4D46, { 0xBE, 
> > 0xF1, 0x35, 0x7B, 0xB5, 0x78, 0xC4, 0x18 }}
> >  
> > -  ## OEM Badging Protocol defines the interface to get the OEM badging 
> > image with the dispaly attribute.
> > -  #  Include/Protocol/OEMBadging.h
> > -  gEfiOEMBadgingProtocolGuid = { 0x170E13C0, 0xBF1B, 0x4218, { 0x87, 
> > 0x1D, 0x2A, 0xBD, 0xC6, 0xF8, 0x87, 0xBC }}
> > -
> >## Include/Protocol/ExitPmAuth.h
> >gExitPmAuthProtocolGuid= { 0xd088a413, 0xa70, 0x4217, { 0xba, 
> > 0x55, 0x9a, 0x3c, 0xb6, 0x5c, 0x41, 0xb3 }}
> >  
> > diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> > index 3dfcd6a..862b993 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -449,6 +449,10 @@
> >## Include/Protocol/SmmReadyToBoot.h
> >gEdkiiSmmReadyToBootProtocolGuid = { 0x6e057ecf, 0xfa99, 0x4f39, { 0x95, 
> > 0xbc, 0x59, 0xf9, 0x92, 0x1d, 0x17, 0xe4 } }
> >  
> > +  ## OEM Badging Protocol defines the interface to get the OEM badging 
> > image with the dispaly attribute.
> > +  #  Include/Protocol/OEMBadging.h
> > +  gEfiOEMBadgingProtocolGuid = { 0x170E13C0, 0xBF1B, 0x4218, { 0x87, 
> > 0x1D, 0x2A, 0xBD, 0xC6, 0xF8, 0x87, 0xBC }}
> > +
> >  #
> >  # [Error.gEfiMdeModulePkgTokenSpaceGuid]
> >  #   0x8001 | Invalid value provided.
> > -- 
> > 1.9.5.msysgit.1
> > 
> > ___
> > 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] PCI code is finding only Bus 0. I need Bus 1

[Laszlo Ersek]

On 09/26/15 02:49, Shubha Ramani wrote:
> Thank you again for your detailed email Lazslo.

The fun never stops; last time you wrote "Lazlo" and I mentioned that my
first name was L-A-S-Z-L-O. I also recommended that you try copy &
paste. I can see the attempt here (you added an "S" indeed), but that's
still not copy & paste, because the order of S and Z is in reverse.
Sigh. I guess I should change my name.

> I tried your tricks and
> unfortunately, no luck. 
> But I did find something out. Our internal specifications lied.

Who would have thought. :)

> The bus
> we're looking for is not 1 but
> rather 0xFE. And if I look at the boot logs the PCI registers I need are
> definitely being initialized and written
> to properly during boot-up on PCI bus 0xFE. 

What boot logs? Are they logged by some proprietary code, or by the PCI
bus driver of edk2?

> Is it a possibility that the "pci" command or the UEFI PCI Bus Driver
> has a bug in it to where it's not
> recognizing 0xFE ?

The PCI bus driver recursively enumerates root bridges for which your
root bridge driver produces PciRootBridgeIo protocol instances, and
which PciRootBridgeIo instances the BDS policy tells the PCI bus driver
to connect. That's all I can say.

Did you try the "dh" command from my previous email? If there's only one
PciRootBridgeIo protocol instance in the system, (and bus 0xFE is not on
that (after enumeration)), then it's probably an issue with your PCI
host bridge / root bridge driver.

> Some people I know are suggesting the following approach to read PCI
> registers (the 0xCF8 approach):
> PCI - OSDev Wiki 

Sure, you can do that very easily in edk2 too, with the appropriate
PciLib library instance; see again (2) in

http://thread.gmane.org/gmane.comp.bios.edk2.devel/2491/focus=2492

But that is not the pedantic UEFI driver / app way -- direct PciLib use
is appropriate for code that is shipped with the platform (ie. where you
have ingrained knowledge about platform specifics -- DXE drivers, PEIMs,
etc), but UEFI modules (drivers and apps) are supposed to be independent
of the platform (like if PCI config space is memory mapped vs.
accessible through ioports 0xCF8/0xCFC), so in UEFI driver & app modules
you should use PciIo protocol instances.

(I don't claim that we comply with the above 100% in OvmfPkg.)

Thanks
Laszlo

>  
>  
>   
>  
>   
>  
>   
>  
>   
>  
> PCI - OSDev Wiki 
> Contents 1 The PCI Bus 2 Configuration Space 2.1 Configuration Space
> Access Mechanism #1 2.2 Configuration Space Access Mechanism #2 2.3
> Memory Mapped PCI Configuration Space Access
> View on wiki.osdev.org 
>   
> Preview by Yahoo
>  
> 
> 
> uint16_t pciConfigReadWord (uint8_t bus, uint8_t slot,
>  uint8_t func, uint8_t offset)
>  {
> uint32_t address;
> uint32_t lbus  = (uint32_t)bus;
> uint32_t lslot = (uint32_t)slot;
> uint32_t lfunc = (uint32_t)func;
> uint16_t tmp = 0;
>  
> /* create configuration address as per Figure 1 */
> address = (uint32_t)((lbus << 16) | (lslot << 11) |
>   (lfunc << 8) | (offset & 0xfc) | ((uint32_t)0x8000));
>  
> /* write out the address */
> sysOutLong (0xCF8, address);
> /* read in the data */
> /* (offset & 2) * 8) = 0 will choose the first word of the 32 bits
> register */
> tmp = (uint16_t)((sysInLong (0xCFC) >> ((offset & 2) * 8)) & 0x);
> return (tmp);
>  }
> 
> 
> Thanks,
> 
> Shubha
>  
> *
> Shubha D. Ramani
> shubharam...@gmail.com 
> shubharam...@yahoo.com *
> 
> 
> 
> On Friday, September 25, 2015 11:25 AM, Laszlo Ersek 
> wrote:
> 
> 
> On 09/25/15 00:59, Shubha Ramani wrote:
>> Hello Laszlo.
>>
>> All I see from the driver debug messages are the following type(just a
>> snippet printed). I assume the format is [B|F|D] and I'm not
>> seeing any with 01 for the B. So the PCI Bus Driver is not seeing Bus 1
>> it seems. Is my interpretation correct ?
>>
>> PciBus: Discovered PCI @ [00|00|00]
>>
>> PciBus: Discovered PCI @ [00|00|01]
>>
>> PciBus: Discovered PCI @ [00|00|04]
>>
>> PciBus: Discovered PCI @ [00|00|05]
>>
>> PciBus: Discovered PCI @ [00|00|06]
>>
>> PciBus: Discovered PCI @ [00|00|07]
>>
>> PciBus: Discovered PCI @ [00|01|04]
>>
>> PciBus: Discovered PCI @ [00|01|05]
>>
>> PciBus: Discovered PCI @ [00|01|06]
>>
>> PciBus: Discovered PCI @ [00|01|07]
>>
>> PciBus: Discovered PCI @ [00|02|04]
>>
>> PciBus: Discovered PCI @ [00|02|05]
>>
>> PciBus: Discovered PCI @ [00|02|06]
>>
>> PciBus: Discovered PCI @ [00|02|07]
>>
>> PciBus: Discovered PCI @ [00|05|00]
>>
>> PciBus: Discovered PCI @ [00|05|02]
>>
>> PciBus: Discovered PCI @ [00|05|03]
>>
>> PciBus: Discovered PCI @ [00|05|04]
>> 
>> blah
>> blah
>> blah
> 
> I think I've had the same idea as Bill described in his email. Here's
> what I thought:
> 
> Your 

Re: [edk2] BUG: UEFI won't recognize PCI busses which don't sit under a bridge

[Laszlo Ersek]

On 09/27/15 21:46, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Shubha Ramani had to 
> walk into mine at 15:45:52 on Saturday 26 September 2015 and say:
> 
>> Yes it's a bug but...
>> OK I'm a dumb-ass. What I'm asking for with 0xCF8/0xCFC doesn't make sense.
>> I just learned the basics of this 0xCF8/0xCFC stuff. 1) Output the I/O
>> Configuration ADDRESS to I/O port 0xCF8 using a 32-bit write command
>> ("point")2) Use a byte, word, or dword command to to access DATA from I/O
>> port 0xCFC-CFF ("shoot") The Configuration Address is obtained by step 1).
>> A signal is asserted to the device being accessed. I don't think the PCI
>> spec has changed in ages so these are still 32-bit commands.   Shubha D.
>> ramanishubharam...@gmail.com shubharam...@yahoo.com
> 
> Earlier I asked you for some information about your hardware and you insisted 
> you weren't allowed to say anything about it. You need to loosen up on this 
> just a little bit, because otherwise there's really no way we can help you.

+1

> There is just one question that I would like answering which I don't think 
> will result in the release of incredibly important proprietary info, and that 
> is: is the target system you're using an off-the-shelf machine, yes or no?
> 
> The reason I ask is that like I said earlier, if there's more than one PCI 
> segment on your system, the ACPI tables should say so, and I would expect the 
> UEFI firmware to figure it out since it relies on ACPI for system information 
> just like everyone else.

I'd like to express a *small* disagreement here.

(I assume that with the ACPI reference you imply the PNP0A03 devices in
the DSDT / SSDTs.)

I don't think the firmware keys off of AML. I think the AML *originates*
from (various parts of) the firmware. Parsing Definition Blocks (i.e.
AML) is a huge mess, so I'd think that that is left to the runtime OS
which is expected to have a full-blown ACPI interpreter.

Instead, the firmware is the source of information for *both* ACPI
tables and the PCI root bridges exposed. (On physical hw at least.)

So, I can only repeat myself: by now I'm fairly convinced that on
Shubha's "secret" system the PCI host bridge / root bridge driver is
broken, and it does not install a PciRootBridgeIo protocol instance for
the root bus on which (directly, or recursively, behind bridges) bus
0xFE is supposed to exist (with the special device).

Whether ACPI correctly reflects that (buggy) status is an independent
question (which, I believe, should only affect the runtime OS's view of
the system). Optimally, the firmware should expose all root buses to
platform BDS and the PCI root bus driver (by creating PciRootBridgeIo
protocol instances), *and* to the OS (via PNP0A03 devices in the DSDT /
SSDTs).

Obviously, I'm not denying that driver X in the firmware could
technically parse AML installed by driver Y in the firmware. I've seen
worse (driver X in the firmware hot-patching AML in the DSDT, installed
earlier by driver Y...)

I'm just saying it's unlikely, because parsing AML is hard, even with
EFI_ACPI_SDT_PROTOCOL. (The one driver that I saw was *very* determined
to do the wrong thing.)

> Sometimes though, the ACPI tables are wrong. I've got 
> an Intel production motherboard with a Pentium4 processor on it (D915GEV, or 
> something like that), that quite clearly has a COM1 serial port on it, but 
> the 
> ACPI device table doesn't list it. That said, you are more likely to see such 
> errors in prototype hardware as opposed to production hardware, especially 
> for 
> something like this, because if it's broken on a production board then not 
> even Windows will work correctly on it.
> 
> So, if this is a prototype board rather than an off-the-shelf production 
> board, then the problem might be that it has a bogus ACPI device table. It 
> might also have a faulty pre-release UEFI firmware build on it too.

Yes! I completely agree with that idea. The "broken PCI host bridge /
root bridge driver" that I keep parroting definitely falls in that category.

> If that's
> the case, you should be talking to whoever made the prototype board and 
> confirming that they got the ACPI tables right rather than making the blanket 
> statement that "there's a bug in UEFI."

Indeed.

The cool thing is that Shubha can actually verify both of these questions!

For the root bridge protocol instances, I recommended "dh -d -v -p
PciRootBridgeIo".

With regard to the ACPI tables, "acpidump" could be used from a runtime
OS, or even from the firmware environment directly.

> There may come a point in the investigation of a fault where you get to say 
> "if there's nothing wrong with me, maybe there's something wrong with the 
> universe." I don't think you've reached that point yet.

I agree.

> You could try temporarily booting FreeBSD or Linux on this hardware so that 
> you can dump and inspect the ACPI device table and confirm that there's more 
> than one PCI roots. (There 

Re: [edk2] BUG: UEFI won't recognize PCI busses which don't sit under a bridge

[Shubha Ramani]

Laszlo and Bill,
I appreciate where you're coming from. But I can't say anymore than I already 
have.It's OK. The "bug" where-ever it is probably won't get fixed as quickly as 
I need it. To get my job done I'm going the PciCf8Lib.h route. It will work 
fine I think.
Thanks for all of your help. 
I have used acpidump before. When I get a moment I will dump the acpidump 
tables andsee what I find. 
Shubha

 Shubha D. ramanishubharam...@gmail.com
shubharam...@yahoo.com 


 On Monday, September 28, 2015 8:19 AM, Laszlo Ersek  
wrote:
   

 On 09/27/15 21:46, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Shubha Ramani had to 
> walk into mine at 15:45:52 on Saturday 26 September 2015 and say:
> 
>> Yes it's a bug but...
>> OK I'm a dumb-ass. What I'm asking for with 0xCF8/0xCFC doesn't make sense.
>> I just learned the basics of this 0xCF8/0xCFC stuff. 1) Output the I/O
>> Configuration ADDRESS to I/O port 0xCF8 using a 32-bit write command
>> ("point")2) Use a byte, word, or dword command to to access DATA from I/O
>> port 0xCFC-CFF ("shoot") The Configuration Address is obtained by step 1).
>> A signal is asserted to the device being accessed. I don't think the PCI
>> spec has changed in ages so these are still 32-bit commands.  Shubha D.
>> ramanishubharam...@gmail.com shubharam...@yahoo.com
> 
> Earlier I asked you for some information about your hardware and you insisted 
> you weren't allowed to say anything about it. You need to loosen up on this 
> just a little bit, because otherwise there's really no way we can help you.

+1

> There is just one question that I would like answering which I don't think 
> will result in the release of incredibly important proprietary info, and that 
> is: is the target system you're using an off-the-shelf machine, yes or no?
> 
> The reason I ask is that like I said earlier, if there's more than one PCI 
> segment on your system, the ACPI tables should say so, and I would expect the 
> UEFI firmware to figure it out since it relies on ACPI for system information 
> just like everyone else.

I'd like to express a *small* disagreement here.

(I assume that with the ACPI reference you imply the PNP0A03 devices in
the DSDT / SSDTs.)

I don't think the firmware keys off of AML. I think the AML *originates*
from (various parts of) the firmware. Parsing Definition Blocks (i.e.
AML) is a huge mess, so I'd think that that is left to the runtime OS
which is expected to have a full-blown ACPI interpreter.

Instead, the firmware is the source of information for *both* ACPI
tables and the PCI root bridges exposed. (On physical hw at least.)

So, I can only repeat myself: by now I'm fairly convinced that on
Shubha's "secret" system the PCI host bridge / root bridge driver is
broken, and it does not install a PciRootBridgeIo protocol instance for
the root bus on which (directly, or recursively, behind bridges) bus
0xFE is supposed to exist (with the special device).

Whether ACPI correctly reflects that (buggy) status is an independent
question (which, I believe, should only affect the runtime OS's view of
the system). Optimally, the firmware should expose all root buses to
platform BDS and the PCI root bus driver (by creating PciRootBridgeIo
protocol instances), *and* to the OS (via PNP0A03 devices in the DSDT /
SSDTs).

Obviously, I'm not denying that driver X in the firmware could
technically parse AML installed by driver Y in the firmware. I've seen
worse (driver X in the firmware hot-patching AML in the DSDT, installed
earlier by driver Y...)

I'm just saying it's unlikely, because parsing AML is hard, even with
EFI_ACPI_SDT_PROTOCOL. (The one driver that I saw was *very* determined
to do the wrong thing.)

> Sometimes though, the ACPI tables are wrong. I've got 
> an Intel production motherboard with a Pentium4 processor on it (D915GEV, or 
> something like that), that quite clearly has a COM1 serial port on it, but 
> the 
> ACPI device table doesn't list it. That said, you are more likely to see such 
> errors in prototype hardware as opposed to production hardware, especially 
> for 
> something like this, because if it's broken on a production board then not 
> even Windows will work correctly on it.
> 
> So, if this is a prototype board rather than an off-the-shelf production 
> board, then the problem might be that it has a bogus ACPI device table. It 
> might also have a faulty pre-release UEFI firmware build on it too.

Yes! I completely agree with that idea. The "broken PCI host bridge /
root bridge driver" that I keep parroting definitely falls in that category.

> If that's
> the case, you should be talking to whoever made the prototype board and 
> confirming that they got the ACPI tables right rather than making the blanket 
> statement that "there's a bug in UEFI."

Indeed.

The cool thing is that Shubha can actually verify both of these questions!

For the root bridge protocol instances, I recommended "dh -d 

Re: [edk2] TFTP issue, Ping 1st packet reply missing

[Paolo Bonzini]

On 28/09/2015 12:24, Leekha Shaveta wrote:
> Hi Laszlo,
> 
> Please find the detailed "tcpdump" on my setup:

You still aren't following Laszlo's instructions: "your dump is missing
the DHCP packets that should be captured while the ifconfig program
(launched from the UEFI shell) brings up the interface on which you
later use TFTP"

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

Re: [edk2] TFTP issue, Ping 1st packet reply missing

[Leekha Shaveta]

Hi,

I am not using DHCP

I am setting IP statically using command:

Shell> ifconfig -s eth0 static 192.168.3.154 255.255.252.0 192.168.3.1
InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C DF5118B0
Shell> ping 192.168.3.221
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF5129E0
Ping 192.168.3.221 16 data bytes.
16 bytes from 192.168.3.221 : icmp_seq=1 ttl=0 time<0ms

1 packets transmitted, 1 received, 0% packet loss, time 0ms

Rtt(round trip time) min=0ms max=0ms avg=0ms
Shell>


Thanks and Regards,
Shaveta


-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini
Sent: Monday, September 28, 2015 4:57 PM
To: Leekha Shaveta-B20052 ; Laszlo Ersek 

Cc: edk2-devel@lists.01.org ; Gary Ching-Pang Lin 
; Fu, Siyuan ; Chris Cuthbert 

Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing



On 28/09/2015 12:24, Leekha Shaveta wrote:
> Hi Laszlo,
> 
> Please find the detailed "tcpdump" on my setup:

You still aren't following Laszlo's instructions: "your dump is missing the 
DHCP packets that should be captured while the ifconfig program (launched from 
the UEFI shell) brings up the interface on which you later use TFTP"

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

Re: [edk2] TFTP issue, Ping 1st packet reply missing

[Laszlo Ersek]

On 09/28/15 12:24, Leekha Shaveta wrote:
> Hi Laszlo,
> 
> Please find the detailed "tcpdump" on my setup:
> 
> test@boardfram-OptiPlex-790:/tftpboot$ sudo tcpdump -v -v -n -l -X -e -i eth0
> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 
> bytes
> 21:39:42.028524 68:05:ca:04:d5:6a > 18:03:73:15:7b:12, ethertype IPv4 
> (0x0800), length 63: (tos 0x0, ttl 64, id 54858, offset 0, flags [none], 
> proto UDP (17), length 49)
> 192.168.3.154.1051 > 192.168.3.221.69: [udp sum ok]  21 RRQ "test" octet 
> tsize 0
> 0x:  4500 0031 d64a  4011 1baa c0a8 039a  E..1.J..@...
> 0x0010:  c0a8 03dd 041b 0045 001d d2e6 0001 7465  ...E..te
> 0x0020:  7374 006f 6374 6574 0074 7369 7a65 0030  st.octet.tsize.0
> 0x0030:  00   .
> 21:39:42.030313 18:03:73:15:7b:12 > 68:05:ca:04:d5:6a, ethertype IPv4 
> (0x0800), length 65: (tos 0x0, ttl 64, id 7770, offset 0, flags [DF], proto 
> UDP (17), length 51)
> 192.168.3.221.40480 > 192.168.3.154.1051: [udp sum ok] UDP, length 23
> 0x:  4500 0033 1e5a 4000 4011 9398 c0a8 03dd  E..3.Z@.@...
> 0x0010:  c0a8 039a 9e20 041b 001f 169a 0003 0001  
> 0x0020:  6969 6969 6964 6863 626a 7364 6320 7364  idhcbjsdc.sd
> 0x0030:  6320 0a  c..
> 21:39:42.058922 68:05:ca:04:d5:6a > 18:03:73:15:7b:12, ethertype IPv4 
> (0x0800), length 68: (tos 0x0, ttl 64, id 54859, offset 0, flags [none], 
> proto UDP (17), length 54)
> 192.168.3.154.1051 > 192.168.3.221.40480: [udp sum ok] UDP, length 26
> 0x:  4500 0036 d64b  4011 1ba4 c0a8 039a  E..6.K..@...
> 0x0010:  c0a8 03dd 041b 9e20 0022 ed64 0005 0004  .".d
> 0x0020:  5573 6572 2061 626f 7274 6564 2064 6f77  User.aborted.dow
> 0x0030:  6e6c 6f61 6400   nload.
> ^C
> 3 packets captured
> 3 packets received by filter
> 0 packets dropped by kernel
> 
> 
> Command I had run for tftp was:
> 
> Shell> tftp 192.168.3.221 test t4
> unicast promiscuous.
> PacketType 4
> protocol 8
> Src MAC Address: 18  3 73 15 7B 12
> Dest MAC Address: 68  5 CA  4 D5 6A
> Failed to get the size of the file 'test' on 'eth0' - Protocol Error
> Shell> 
> 
> 
> 
> I have now compiled the code with latest ShellPkg and ran it.
> 
> Does this log give any pointer, why Token state is getting "ABORTED" in tftp?

The reason I recommended the -X (more precisely, -l -X) options is
because the packets often contain ASCII strings that the source code can
be grepped for. (Clearly the source code that is responsible for sending
out that packet.)

In this case, the 3rd packet (which is sent by edk2) contains "User
aborted download":

$ git grep 'User aborted download'

The one hit (restricting the results to IPv4) is in
"MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Rrq.c", function
Mtftp4RrqSaveBlock(). The documentation on that function is

  Deliver the received data block to the user, which can be saved in the
  user provide buffer or through the CheckPacket callback.

The textual error message is passed by Mtftp4RrqSaveBlock() to
Mtftp4SendError(), and this branch depends on the Token->CheckPacket()
callback *failing*. Thus, we can say that the Token->CheckPacket()
function call rejects the 2nd packet.

In addition, the Mtftp4RrqSaveBlock() function documents its own
EFI_ABORTED retval like this:

  The user tells to abort by return an error through CheckPacket

... As far as I can see in this directory, EfiMtftp4GetInfo() populates
the CheckPacket function pointer with the address of
Mtftp4GetInfoCheckPacket(). So let's see what Mtftp4GetInfoCheckPacket()
does:

Apparently, this function *always* returns EFI_ABORTED (which in turn
always triggers the above branch in Mtftp4RrqSaveBlock()). However,
remember that it's only EfiMtftp4GetInfo() that sets up the CheckPacket
callback pointer like this.

In addition, before returning EFI_ABORTED indiscriminately,
Mtftp4GetInfoCheckPacket() stores a status code in
((MTFTP4_GETINFO_STATE *)Token->Context)->Status.

Therefore, we can determine the following: when you use
Mtftp4RrqSaveBlock() as part of a "normal" download, the CheckPacket
callback ptr is NULL, and this doesn't happen. However, when you use the
same function as part of querying *metadata* of the remote file, ie.
initiated from EfiMtftp4GetInfo(), then the callback function is always
set to Mtftp4GetInfoCheckPacket(), which will (a) abort the transfer
invariably after the first packet -- which is valid, we only care about
the metadata in the first packet --, and (b) it will store a status code
too in the context, "for later", ie. for the actual download that is
supposed to take place after the metadata have been parsed on the edk2
side.

And, in your case, this "actual" download doesn't seem to be happening.
Why?

Well, in your UEFI shell log, I see "Protocol Error" -- in

Re: [edk2] BUG: UEFI won't recognize PCI busses which don't sit under a bridge

[Ni, Ruiyu]

Shubha,
PciBus only scan in a depth-first-search algorithm from the bus reported by 
PciHostBridgeResourceAllocation->StartBusEnumeration (RootBridgeHandle).
Normally the bus reported out is 0, so all devices behind the bridges in BUS 0 
are found and reported, so we can get the PciIo instances for them.
But for your 0xFE BUS, it actually is in the same level as BUS 0. A platform 
can either report this BUS out by creating a new PciRootBridgeIo handle so we 
can get the PciIo instance for it, or don't report this BUS out, so we can only 
access them using PciLib.

Thanks,
Ray

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Shubha 
Ramani
Sent: Monday, September 28, 2015 11:46 PM
To: Laszlo Ersek ; Bill Paul ; 
edk2-de...@ml01.01.org
Subject: Re: [edk2] BUG: UEFI won't recognize PCI busses which don't sit under 
a bridge

Laszlo and Bill,
I appreciate where you're coming from. But I can't say anymore than I already 
have.It's OK. The "bug" where-ever it is probably won't get fixed as quickly as 
I need it. To get my job done I'm going the PciCf8Lib.h route. It will work 
fine I think.
Thanks for all of your help. 
I have used acpidump before. When I get a moment I will dump the acpidump 
tables andsee what I find. 
Shubha

 Shubha D. ramanishubharam...@gmail.com
shubharam...@yahoo.com 


 On Monday, September 28, 2015 8:19 AM, Laszlo Ersek  
wrote:
   

 On 09/27/15 21:46, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Shubha Ramani had to 
> walk into mine at 15:45:52 on Saturday 26 September 2015 and say:
> 
>> Yes it's a bug but...
>> OK I'm a dumb-ass. What I'm asking for with 0xCF8/0xCFC doesn't make sense.
>> I just learned the basics of this 0xCF8/0xCFC stuff. 1) Output the I/O
>> Configuration ADDRESS to I/O port 0xCF8 using a 32-bit write command
>> ("point")2) Use a byte, word, or dword command to to access DATA from I/O
>> port 0xCFC-CFF ("shoot") The Configuration Address is obtained by step 1).
>> A signal is asserted to the device being accessed. I don't think the PCI
>> spec has changed in ages so these are still 32-bit commands.  Shubha D.
>> ramanishubharam...@gmail.com shubharam...@yahoo.com
> 
> Earlier I asked you for some information about your hardware and you insisted 
> you weren't allowed to say anything about it. You need to loosen up on this 
> just a little bit, because otherwise there's really no way we can help you.

+1

> There is just one question that I would like answering which I don't think 
> will result in the release of incredibly important proprietary info, and that 
> is: is the target system you're using an off-the-shelf machine, yes or no?
> 
> The reason I ask is that like I said earlier, if there's more than one PCI 
> segment on your system, the ACPI tables should say so, and I would expect the 
> UEFI firmware to figure it out since it relies on ACPI for system information 
> just like everyone else.

I'd like to express a *small* disagreement here.

(I assume that with the ACPI reference you imply the PNP0A03 devices in
the DSDT / SSDTs.)

I don't think the firmware keys off of AML. I think the AML *originates*
from (various parts of) the firmware. Parsing Definition Blocks (i.e.
AML) is a huge mess, so I'd think that that is left to the runtime OS
which is expected to have a full-blown ACPI interpreter.

Instead, the firmware is the source of information for *both* ACPI
tables and the PCI root bridges exposed. (On physical hw at least.)

So, I can only repeat myself: by now I'm fairly convinced that on
Shubha's "secret" system the PCI host bridge / root bridge driver is
broken, and it does not install a PciRootBridgeIo protocol instance for
the root bus on which (directly, or recursively, behind bridges) bus
0xFE is supposed to exist (with the special device).

Whether ACPI correctly reflects that (buggy) status is an independent
question (which, I believe, should only affect the runtime OS's view of
the system). Optimally, the firmware should expose all root buses to
platform BDS and the PCI root bus driver (by creating PciRootBridgeIo
protocol instances), *and* to the OS (via PNP0A03 devices in the DSDT /
SSDTs).

Obviously, I'm not denying that driver X in the firmware could
technically parse AML installed by driver Y in the firmware. I've seen
worse (driver X in the firmware hot-patching AML in the DSDT, installed
earlier by driver Y...)

I'm just saying it's unlikely, because parsing AML is hard, even with
EFI_ACPI_SDT_PROTOCOL. (The one driver that I saw was *very* determined
to do the wrong thing.)

> Sometimes though, the ACPI tables are wrong. I've got 
> an Intel production motherboard with a Pentium4 processor on it (D915GEV, or 
> something like that), that quite clearly has a COM1 serial port on it, but 
> the 
> ACPI device table doesn't list it. That said, you are more likely to see such 
> errors in