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