S32G3 PCIe Vendor ID is wrong

[minersrevolt]

I have a custom board with a S32G3 and am bringing up the PCIe0 (SERDES0) bus and in U-Boot I see an unexpected Vendor ID. On the evaluation board the VendorId belongs to NXP and on the custom board it belongs to Google (according to the online sources I found).

The custom board has the PCIe RC attached to a Micron SSD while the RDB3 board doesn't have anything attached to it. I don't think this is relevant but...?

I would like to know why the VendorId is different between the two.

In U-boot on the RDB3 evaluation board I see,

    PCIe:   BusDevFun       VendorId   DeviceId   Device Class       Sub-Class                                                                                        
    __________________________________________________________________________                                                                                        
    pcie@40400000 RootComplex                                                                                                                                         
    |   `-- 01:00.00        0x1957     0x4300     Bridge device           0x04

and on our board I see,

    PCIe:   BusDevFun       VendorId   DeviceId   Device Class       Sub-Class                                                                                        
    __________________________________________________________________________                                                                                        
    pcie@40400000 RootComplex                                                                                                                                         
    |   `-- 01:00.00        0x16c3     0x4300     Bridge device           0x04    

[chenyin_h]

Hi, @minersrevolt 

Glad to hear that the issue does not block your development, the vendor ID you mentioned is belong to Synopsys, not Google.

While the PCI driver applied, it is modified to the 0x1957, maybe in your cases, the driver is not applied correctly in uboot, but while booting the kernel, the kernel driver correctly set the vendor ID, it is the reason that in kernel you may find the correct value as shown in the log.

BR

Chenyin

[minersrevolt]

Hey @chenyin_h 

Yeah it is odd. In U-Boot using the md tool I see that the register matches 0x16c3 and when I boot into Linux using devmem I see it is updated to 0x1957. So it is being overwritten by Linux during initialization it seems. 

Either way I was able to use the PCIe bus appropriately so its not really blocking anything at the moment, just strange.

[chenyin_h]

Hello, @minersrevolt 

Sorry for the delay from our side, we were with limited bandwidth in recent days.

Well, yes, it is a little strange, would you please also try directly reading the registers from the u-boot to compare with the output? not sure if it is something wrong from pci command in u-boot.

BR

Chenyin

[minersrevolt]

When our board gets into Linux it reports back 0x1957. Odd.

$ lspci
00:00.0 Class 0604: 1957:4300