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 < [email protected]> 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 <[email protected]> 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
