[coreboot] Re: ThinkPad T420 and FireWire chip on Linux

[AreYouLoco?]

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  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 <
> [e-mail]> 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  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 -- [e-mail]
> > > To unsubscribe send an email to [e-mail]