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]
