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]
