The FireWire functionality is hanfled by SD/MMC Ricoh chip. The small daughter board is just wired to MMC Controller and its a secondary function of that chip (from what I got from thinkpad forum and IRC channel).
On April 9, 2020 7:44:26 AM UTC, Alesandar Metodiev <alesandarmetod...@gmail.com> wrote: >By the way, since I have manually swapped the chip, I wanted to let you >know that it is not directly mounted to the motherboard. >It is attached to a smaller daughter board which might be the SD host >controller itself. > >On Thu, Apr 9, 2020 at 10:20 AM Alesandar Metodiev < >alesandarmetod...@gmail.com> wrote: > >> I have booted with spkmodem enabled, but nothing has changed. The >device >> is still not present. >> >> On Thu, Apr 9, 2020 at 3:04 AM Peter Stuge <pe...@stuge.se> wrote: >> >>> AreYouLoco? wrote: >>> > I was wrong it isn't detected as SD/MMC it doesn't get detected at >all. >>> > There is a separate device for SD/MMC present both on coreboot and >>> stock. >>> >>> Are you really sure? There is no such device in the vendor BIOS >logs. >>> >>> >>> Alesandar Metodiev wrote: >>> > I have tried to enable spkmodem, but now I can not boot at all. >>> > Maybe I did something wrong. No SeaBios, just a black screen. >>> >>> No - just wait really long, 10-20 minutes, depending on console >level. >>> IIRC it's 1200 bps, around 100 byte per second, so the 110860 byte >>> console log at https://del.dog/raw/cbmemlog would take 18 minutes. >>> Reduce the console level with spkmodem. >>> >>> >>> Nico Huber wrote: >>> > e822 vs. e823 smells like an upgrade to me. I suspect that we'd >need to >>> > load some firmware on the 0.0 device. Or at least to configure >something >>> > there so it switches 0.3 on. >>> >>> >>> Nico Huber wrote: >>> > https://del.dog/raw/nnvvvxxx_root >>> > https://del.dog/raw/xxxx_root >>> > https://del.dog/raw/lspci_tv >>> > >>> > Note, lspci calls it e823 even the DID register says e822, I have >no >>> > idea where it gets the number from. >>> >>> Also fun. lspci has an -A option to specify how it reads data. It >>> would be interesting to compare what the kernel has (the default is >>> one of the linux- methods) with the registers in the devices (the >>> intel-conf1 method). If there is a difference then maybe the device >>> still wasn't quite ready when the kernel booted. >>> >>> >>> > Peter, do you happen to know something about the Virtual Channel >>> > capability? >>> >>> I didn't, and I looked at the spec now but it seems uninteresting. >>> It's a mechanism for multiple channels over a single link, with each >>> VC possibly having different buffering and traffic class. >>> >>> >>> I found something that might be relevant in >https://del.dog/raw/cbmemlog >>> however, search it for Remap: >>> >>> --8<-- https://del.dog/raw/cbmemlog#149 >>> PCI: 00:1c.0: Disabling device >>> PCI: 00:1c.0: check set enabled >>> PCH: Remap PCIe function 1 to 0 >>> PCI: 00:1c.1 [8086/1c12] enabled >>> PCI: 00:1c.2: Disabling device >>> PCH: Remap PCIe function 3 to 0 >>> PCI: 00:1c.3 [8086/1c16] enabled >>> PCH: Remap PCIe function 4 to 0 >>> PCI: 00:1c.4 [8086/1c18] enabled >>> -->8-- >>> >>> It looks strange that fn 1, 3 and 4 are all supposedly remapped to >fn 0. >>> I looked in the code, to me it looks like this will cause a mess in >RPFN: >>> >>> --8<-- southbridge/intel/bd82x6x/pch.c#229 >>> /* Swap function numbers assigned to two PCIe Root Ports */ >>> static void pch_pcie_function_swap(u8 old_fn, u8 new_fn) >>> { >>> u32 old_rpfn = new_rpfn; >>> >>> printk(BIOS_DEBUG, "PCH: Remap PCIe function %d to %d\n", >>> old_fn, new_fn); >>> >>> new_rpfn &= ~(RPFN_FNMASK(old_fn) | RPFN_FNMASK(new_fn)); >>> >>> /* Old function set to new function and disabled */ >>> new_rpfn |= RPFN_FNSET(old_fn, RPFN_FNGET(old_rpfn, >new_fn)); >>> new_rpfn |= RPFN_FNSET(new_fn, RPFN_FNGET(old_rpfn, >old_fn)); >>> } >>> ... line 373: >>> int fn; >>> >>> /* >>> * Check if there is a lower disabled port to swap >with >>> this >>> * port in order to maintain linear order starting >at >>> zero. >>> */ >>> if (config->pcie_port_coalesce) { >>> for (fn=0; fn < >PCI_FUNC(dev->path.pci.devfn); >>> fn++) { >>> if (!(new_rpfn & RPFN_HIDE(fn))) >>> continue; >>> >>> /* Swap places with this function */ >>> pch_pcie_function_swap( >>> >PCI_FUNC(dev->path.pci.devfn), >>> fn); >>> break; >>> } >>> } >>> -->8-- >>> >>> But later in the log it doesn't look like RPFN has all functions on >>> top of each other, but it also doesn't look really good: >>> >>> >>> --8<-- https://del.dog/raw/cbmemlog#162 >>> PCH: PCIe map 1c.0 -> 1c.4 >>> PCH: PCIe map 1c.1 -> 1c.0 >>> PCH: PCIe map 1c.3 -> 1c.1 >>> PCH: PCIe map 1c.4 -> 1c.3 >>> -->8-- >>> >>> If the gaps are to be filled then I'd expect to see something like: >>> >>> 1c.1 -> 1c.0 >>> 1c.3 -> 1c.1 >>> 1c.4 -> 1c.2 >>> >>> The devicetree.cb seems not quite done, at least not for this >mainboard: >>> >>> --8<-- https://del.dog/raw/cbmemlog#175 >>> PCI: Leftover static devices: >>> PCI: 00:01.0 >>> PCI: 00:16.1 >>> PCI: 00:16.2 >>> PCI: 00:16.3 >>> PCI: 00:1c.4 >>> PCI: 00:1c.2 >>> PCI: 00:1c.5 >>> PCI: 00:1c.7 >>> PCI: Check your devicetree.cb. >>> -->8-- >>> >>> But scanning the busses, actually both the Renesas xHCI/USB3 and the >Ricoh >>> are visible: >>> >>> --8<-- https://del.dog/raw/cbmemlog#189 >>> PCI: pci_scan_bus for bus 02 >>> PCI: 02:00.0 [1912/0015] enabled >>> Enabling Common Clock Configuration >>> ASPM: Enabled L0s and L1 >>> PCIe: Max_Payload_Size adjusted to 128 >>> scan_bus: bus PCI: 00:1c.1 finished in 0 msecs >>> PCI: 00:1c.3 scanning... >>> PCI: pci_scan_bus for bus 03 >>> PCI: 03:00.0 [1180/e822] enabled >>> Enabling Common Clock Configuration >>> ASPM: Enabled L0s and L1 >>> PCIe: Max_Payload_Size adjusted to 128 >>> Failed to enable LTR for dev = PCI: 03:00.0 >>> scan_bus: bus PCI: 00:1c.3 finished in 0 msecs >>> -->8-- >>> >>> But the Ricoh has the wrong DID, and while looking at >>> https://del.dog/raw/sd-mmc-not-fw >>> >>> I notice that the device looks more like a PCI device than a PCI >Express >>> one, >>> with INTA routed to IRQ 16 instead of using MSI. >>> >>> >>> Sorry - I'm not able to suggest anything really concrete, but these >are >>> my observations. >>> >>> >>> //Peter >>> _______________________________________________ >>> coreboot mailing list -- coreboot@coreboot.org >>> To unsubscribe send an email to coreboot-le...@coreboot.org >>> >> _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
