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 <peter@stuge.se> 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 -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org