I did try this (patch format) but it still didn't work. It adds correct pci_device_id and tries to enable it in devicetree.cb:
>From 3f60158b5b19400f2f705b41411cd9c88517328d Mon Sep 17 00:00:00 2001 From: AreYouLoco <[email protected]> Date: Thu, 9 Apr 2020 17:17:18 +0200 Subject: [PATCH] Initial changes to support Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller --- src/drivers/ricoh/rce822/rce822.c | 4 ++-- src/mainboard/lenovo/t420/devicetree.cb | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/drivers/ricoh/rce822/rce822.c b/src/drivers/ricoh/rce822/rce822.c index fb714c2406..44c8538094 100644 --- a/src/drivers/ricoh/rce822/rce822.c +++ b/src/drivers/ricoh/rce822/rce822.c @@ -50,7 +50,7 @@ static struct device_operations rce822_ops = { .ops_pci = &lops_pci, }; -static const unsigned short pci_device_ids[] = { 0xe822, 0xe823, 0 }; +static const unsigned short pci_device_ids[] = { 0xe822, 0xe823, 0xe832, 0 }; static const struct pci_driver rce822 __pci_driver = { .ops = &rce822_ops, @@ -59,5 +59,5 @@ static const struct pci_driver rce822 __pci_driver = { }; struct chip_operations drivers_ricoh_rce822_ops = { - CHIP_NAME("RICOH RCE822") + CHIP_NAME("RICOH RCE822s") }; diff --git a/src/mainboard/lenovo/t420/devicetree.cb b/src/mainboard/lenovo/t420/devicetree.cb index 5ac9cf5a96..7d256f9df7 100644 --- a/src/mainboard/lenovo/t420/devicetree.cb +++ b/src/mainboard/lenovo/t420/devicetree.cb @@ -86,7 +86,8 @@ chip northbridge/intel/sandybridge chip drivers/ricoh/rce822 register "sdwppol" = "1" register "disable_mask" = "0x87" - device pci 00.0 on end + device pci 00.0 on end # Ricoh Co Ltd MMC/SD Host Controller + device pci 00.3 on end # Ricoh Co Ltd PCIe IEEE 1394 Controller end end # PCIe Port #5 (Ricoh SD & FW) device pci 1c.5 off end # PCIe Port #6 Intel Gigabit Ethernet PHY (not PCIe) -- 2.20.1 On 08.04.2020 20:02, Peter Stuge wrote: > 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 > _______________________________________________ > coreboot mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- AreYouLoco? GPG 2717 7338 4742 E034 F65F 7C83 C757 3088 E8B7 DEDA _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
