Hi,
this is a fun one.
Alesandar Metodiev wrote:
AreYouLoco has already posted the output of `sudo lspci -vvxxx -s 0d:00.3` (when he was still running with the vendor firmware). Here it is. https://del.dog/raw/firewire_lspci
Comparing that with https://del.dog/raw/lspci_nntv shows that the chip presents itself differently on the very lowes level.
Factory BIOS: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823]
coreboot: Ricoh Co Ltd MMC/SD Host Controller [what:ids?]
If we look at the beginning of the config space dump in the coreboot case, we see:
00: 80 11 22 e8
These are little-endian vendor and device IDs, swap around to: [1180:e822]
The same chip seems to present itself differently depending on the firmware.
I've seen this before, and in fact I think it was the same kind of chip.
That time there was no coreboot involved, the ID seemed to change depending on whether the laptop was rebooted or actually powered off.
I guess that this device behaves differently depending on how and when it is initialized. I've also seen Atheros PCI devices come up as 0000:0000, which hints to a race condition where the PCI device just isn't ready when coreboot comes to speak to it.
Maybe try sprinkling random delays in the code. Or increase debug level. Or enable spkmodem. Something to make coreboot run slower. Then maybe that hardware works correctly.
//Peter