linux-kernel - Re: PCIe can not rescan for new PCIe device ( FPGA board )

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Oct 2011 09:22:47 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Abdelghani Ouchabane <abdelghani@...no.com>
Cc:	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: PCIe can not rescan for new PCIe device ( FPGA board )

On Tue, Oct 11, 2011 at 2:10 AM, Abdelghani Ouchabane
<abdelghani@...no.com> wrote:
>
>>>>> * But our software returns : 0xFFFFFFFF
>>
>> This is reading from your device's memory region.  It looks like the
>> device is configured correctly (BAR values are reasonable and memory
>> decoding is enabled) and I assume the bridges leading to it are
>> configured correctly (if you posted the complete dmesg log we could
>> tell for sure).  After that point, Linux is out of the way and it's
>> just a question of whether your device responds correctly to the
>> memory access.
>> Are you sure the device is supposed to return something other than
>> 0xFFFFFFFF?
>
> Hi Bjorn,
>
> Yes, the device should return something similar to :
> resource file = /sys/bus/pci/devices/0000:02:00.0/resource
> base address  = 0xFDFFE000
>        0xFDFFE000      0x00000000      0x00000000      0x00000000
>        0xFDFFE008      0x00000008      0x00000000      0x00000000
>        0xFDFFE010      0x00000010      0x00000001      0x00020000
>        0xFDFFE018      0x00000018      0x00000000      0x00000000
>        0xFDFFE020      0x00000020      0x00000000      0x00000000
>        0xFDFFE028      0x00000028      0x00000000      0x00000000
>        0xFDFFE030      0x00000030      0x00000000      0x00000000
>        0xFDFFE038      0x00000038      0x00000000      0x00000000
>        0xFDFFE040      0x00000040      0x30012009      0x00101449
>        0xFDFFE048      0x00000048      0x00000000      0x00000781
>        0xFDFFE050      0x00000050      0x00000000      0x00000300
>        0xFDFFE058      0x00000058      0xCAFEBABE      0xDEADBEEF

How did you get this read to work?  Is this in a different system?
Maybe the difference between this working scenario and the broken
scenario will have a clue.

>> If it's memory, can you write to it and read the new
>> value back?  Can you use a PCIe analyzer and see if the device is
>> responding correctly on the bus?
>
> I have tried to write to the FPGA registers but I was always getting
> 0xFFFFFFFF
>>
>> Other than the possible pciehp rescan problem, this just looks like a
>> problem with your FPGA.
>
> Can it have a relation with the BIOS?
> I attached to you the whole dmesg log.

I don't think it's likely to be a BIOS problem.  Here's what looks
relevant from your dmesg log:

    ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
    pci_root PNP0A08:00: host bridge window [mem 0x40000000-0xffffffff]

    pci 0000:00:05.0: PCI bridge to [bus 02-02]
    pci 0000:00:05.0:   bridge window [mem 0x40000000-0x401fffff]
    pci 0000:00:05.0:   bridge window [mem 0x40200000-0x403fffff 64bit pref]

    pci 0000:02:00.0: BAR 2: assigned [mem 0x40200000-0x4023ffff 64bit pref]
    pci 0000:02:00.0: BAR 0: assigned [mem 0x40240000-0x40240fff 64bit pref]
    pci 0000:02:00.0: BAR 4: assigned [mem 0x40241000-0x40241fff 64bit pref]

The BIOS left the bridge to bus 02 with all windows disabled, but
Linux allocated and enabled the windows as above, and we assigned BARs
of device 02:00.0 inside those windows.  As far as I can tell,
everything leading to the FPGA is set up correctly.

Can you try another, known-working (not your FPGA), card in that slot?
 It still looks to me like a problem with your FPGA.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/