[if gte mso 9]>

Re: [edk2] PciIo Map() and UDK debug firmware

Subject: Re: [edk2] PciIo Map() and UDK debug firmware

From: "William Marone (wmarone)" <wmarone@micron.com>

To: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>

Date: 2013-05-02 04:25:59

Mike,

 

I understand what you’re saying, and after further digging I find that the code is passing a VOID** into Unmap() and not just the VOID*. Worse, it’s done inconsistently, some do it right and some do it wrong. Yet another item for cleanup to add to my list…

 

Thanks,

 

Will

 

From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]
Sent: Wednesday, May 01, 2013 10:32 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] PciIo Map() and UDK debug firmware

 

Will,

 

What do you mean “return nothing in the Mapping pointer”?

 

The caller’s requirement is to pass the Mapping value returned by Map() into UnMap().  The Mapping value which is type VOID * is implementation dependent and there are no requirements for it to be non-NULL.  The Map() function takes a VOID**, and it is not legal to pass into a Map() a Mapping parameter of NULL.

 

Mike

 

From: William Marone (wmarone) [mailto:wmarone@micron.com]
Sent: Tuesday, April 30, 2013 8:38 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] PciIo Map() and UDK debug firmware

 

Is it normal for EFI_PCI_IO_PROTOCOL.Map() to properly map a buffer (Status == EFI_SUCCESS, NumberOfBytes in == NumberOfBytes out, DeviceAddress is good) but return nothing in the Mapping pointer? I’m seeing otherwise normal operation, but with the UDK debug and srcdbug builds I get an ASSERT() when calling Unmap() because the Mappings are coming back zero.

 

ASSERT d:\uefisdv\MdeModulePkg\Core\Dxe\Mem\Page.c(695): NumberOfPages

 

On the release firmware and Dell 12G platforms the Map() is coming back zero as well but, as I noted above, nothing appears broken. Server 2008 R2 boots off the device readily. Maybe something subtle I am missing?

 

Will