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 <ler...@redhat.com>
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 -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 may be an EFI utility for doing that too, but I
> don't know offhand. I usually just use FreeBSD's acpidump tool.)
Agree fully.
Re EFI utility, booting the system with "bits-2005.iso" from
<http://biosbits.org/downloads/bits-2005.zip> allows for quite flexible
experimentation with ACPI from within the firmware environment.
Thanks
Laszlo
>
> -Bill
>
>>
>> On Saturday, September 26, 2015 6:05 AM, Shubha Ramani
>> <shubharam...@yahoo.com> wrote:
>>
>>
>> It's a bug. That's the problem I've been having. Can someone fix it
>> ?Apparently the stuff I need is on busses 0xFF and 0xFE and they don't
>> situnder a PCI bridge. If it doesn't get fixed ASAP I will use the
>> 0xCFC/0xCF8 approach described here:
>> http://faculty.chemeketa.edu/csekafet/ELT256/Adv_Chipset_AGp_DVO_PCI_CFG.p
>> df
>>
>> Also there's a 32-bit-support version of EDK2 0xCF8 already. But I need
>> 64-bit support.Also who knows ? I may need 0xCFC. If someone can add all
>> this stuff ASAP I'd begrateful.
>> C:\edk2\MyWorkSpace\MdePkg\Include\Library\PciCf8Lib.h C:\edk2\MyWorkSpace
>> \MdePkg\Library\BasePciCf8Lib\PciCf8Lib.c Shubha D.
>> ramanishubharam...@gmail.com shubharam...@yahoo.com
>>
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
