On Aug 1, 2012, at 10:45 AM, Miri (Miriam) Shitrit wrote:

> Hi Andrew,
> 
> Thank you for your replay.
> 
> I used 32 width. 
> I am sure the BAR index I use is correct, as when the BIOS "above 4G" option 
> is disabled (the BAR base address high 32 bits are zero) my driver works fine.
> 
> - What could be the reason for the Mem.Read failure when the BAR base address 
> is 64 bit?
> 

A bug in platforms BIOS. 

> - What do you mean by the cache ability attributes for the BAR memory range? 
> Is it part of the setup chipset or should I set it using the BarSetAttributes 
> function?
> 

Cacheability from the CPU point of view, so your drivers software view of 
memory. 

> - What are the MTRR registers?
> 

CPU Registers that the BIOS uses to control cacheability of a given memory 
range. For X64 it can also be done with page table entries, but most BIOS 
implementations I've seen use the MTRRs (MTRR over ride page table cacheability 
attributes). So for example main memory is usually set to write-back, Memory 
Mapped IO ranges (like PCI Bars) are set to uncached. 

It sounds like from your symptom that the BAR range is set to write-back and 
the writes are hitting in the cache and not making it out on the system bus to 
the PCI device. This is just a wild guess based on the limited data available. 

http://en.wikipedia.org/wiki/Memory_type_range_register

> - Is it possible that the problem is in the chipset though on the same setup 
> when "above 4G" is disabled the driver works fine? 
> 

Yes, or in the code configuring the chipset. I've seen chipsets that have PCI 
device built in that don't function properly > 4GB, and the platform PCI code 
has to restrict the enumeration of these devices. 

> Thanks,
> Miri
> 
> 
> 
> On Aug 1, 2012, at 6:57 PM, "Andrew Fish" <[email protected]> wrote:
> 
>> 
>> On Aug 1, 2012, at 4:17 AM, Miri (Miriam) Shitrit wrote:
>> 
>>> Hi,
>>>  
>>> I have an EFI driver for a PCI device which works fine when BAR is 32-bit 
>>> (below 4G), but on a setup with 64-bit BAR (above 4G BIOS option enabled) 
>>> the Mem.Read and MEm.Write functions of EFI_PCI_IO_PROTOCOL fail with 
>>> INVALID_PARAMETER error.
>>>  
>> 
>> What width did you try? Are you sure you are using the correct BarIndex?
>> 
>>> I tried to replace these functions with CopyMem() from/to the BAR memory 
>>> address + offset, the read works fine but the write fails most of the times.
>>>  
>> 
>> It sounds like the cacheability attributes for the BAR memory range are not 
>> correct? 
>> 
>>> What should be replaced to support 64-bit BAR (above 4G)?
>> 
>> If you are passing correct arguments to PCI IO it is likely an issue with 
>> the PCI Root Bridge IO protocol, and that is chipset specific code. 
>> 
>>> Do I need to use the Map() and Unmap() functions?
>>>  
>> 
>> No these are only for DMA. For example on X64 the DMA into memory are cache 
>> coherent, but on ARM the DMA by hardware is not cache coherent so extra 
>> operations are required for the CPU to see the data that was DMA'ed. The 
>> point of the PCI IO protocol is to abstract coherency requirements from the 
>> driver. 
>> 
>>> I will appreciate any help or link to any reference.
>>>  
>> 
>> See PciIoMemRead() in 
>> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
>> 
>> If the platform has setup caching incorrectly it is likely that the MTRR 
>> registers are not programmed correctly. 
>> 
>> Also sounds like you should contact the vendor of the platform you are using 
>> and report a bug. 
>> 
>> Thanks,
>> 
>> Andrew
>> 
>>> Thanks,
>>> Miri
>>>  
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and 
>>> threat landscape has changed and how IT managers can respond. Discussions 
>>> will include endpoint security, mobile security and the latest in malware 
>>> threats. 
>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
>>> edk2-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> edk2-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. 
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to