coreboot

Commit nb/intel/i945: Switch back from V4 to V3 resource allocator to fix hangs reverts devices with northbridge Intel 945 back to version 3 of the resource allocator.

The same happens with the SeaBIOS payload.

CBFS: Found @ offset 4cdc0 size 1124b
Checking segment from ROM address 0xffe4cff8
Checking segment from ROM address 0xffe4d014
Loading segment from ROM address 0xffe4cff8
  code (compression=1)
  New segment dstaddr 0x000df9e0 memsize 0x20620 srcaddr 0xffe4d030 filesize 0x11213
Loading Segment: addr: 0x000df9e0 memsz: 0x0000000000020620 filesz: 0x0000000000011213
using LZMA

build/util/cbfstool/cbfstool build/coreboot.rom print -r COREBOOT
FMAP REGION: COREBOOT
Name                           Offset     Type           Size   Comp
cbfs master header             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           49212 none
cpu_microcode_blob.bin         0xc140     microcode       86016 none
fallback/ramstage              0x211c0    stage           80126 none
config                         0x34b00    raw               338 none
revision                       0x34cc0    raw               675 none
fallback/dsdt.aml              0x34fc0    raw             12600 none
cmos_layout.bin                0x38140    cmos_layout      1664 none
pci1002,7149.rom               0x38800    optionrom       64512 none
fallback/postcar               0x48480    stage           18676 none
(empty)                        0x4cdc0    null          1748952 none
bootblock                      0x1f7dc0   bootblock       32768 none

Reverting commit 7cf96aeeb7 (northbridge/intel/i945: Mark legacy VGA memory as reserved) 1 seems to also help to get the payload executed. GRUB hangs due to some EHCI issue, which the commit in question fixed. SeaBIOS didn’t show issues.

I guess commit 7cf96aeeb7 (northbridge/intel/i945: Mark legacy VGA memory as reserved) 1 is tailored for devices with integrated Intel graphics devices. Devices with a dedicated/external graphics device need to be handled differently?

Paul Menzel wrote:

Reverting commit 7cf96aeeb7 (northbridge/intel/i945: Mark legacy VGA memory as reserved) seems to also help to get the payload executed. GRUB hangs due to some EHCI issue, which the commit in question fixed. SeaBIOS didn’t show issues.

I guess commit 7cf96aeeb7 (northbridge/intel/i945: Mark legacy VGA memory as reserved) is tailored for devices with integrated Intel graphics devices. Devices with a dedicated/external graphics device need to be handled differently?

Scratch that, I now got hangs too with just commit 7cf96aeeb7 (northbridge/intel/i945: Mark legacy VGA memory as reserved) reverted.

commit e2ef6a71ec0fbe8d5c9b5cc78549f68a792ab992
Author: Paul Menzel <pmenzel@molgen.mpg.de>
Date:   Sun Jul 19 20:22:25 2020 +0200

    device/cardbus: Add debug statements

    Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>

diff --git a/src/device/cardbus_device.c b/src/device/cardbus_device.c
index cbe0c724fb..34b43e5f3c 100644
--- a/src/device/cardbus_device.c
+++ b/src/device/cardbus_device.c
@@ -78,6 +78,7 @@ void cardbus_read_resources(struct device *dev)

        pci_get_resource(dev, PCI_BASE_ADDRESS_0);

+       printk(BIOS_DEBUG, "read_res: after pci_get_resource: bridge_ctrl %04x\n", dev->link_list->bridge_ctrl);
        compact_resources(dev);

        /* See which bridge I/O resources are implemented. */
@@ -132,6 +133,7 @@ void cardbus_read_resources(struct device *dev)
        cardbus_size_bridge_resource(dev, PCI_CB_MEMORY_BASE_1);

        compact_resources(dev);
+       printk(BIOS_DEBUG, "read_res: after compact_resources: bridge_ctrl %04x\n", dev->link_list->bridge_ctrl);
 }

 void cardbus_enable_resources(struct device *dev)
@@ -148,6 +150,7 @@ void cardbus_enable_resources(struct device *dev)
        ctrl |= (PCI_CB_BRIDGE_CTL_PARITY | PCI_CB_BRIDGE_CTL_SERR);
        printk(BIOS_DEBUG, "%s bridge ctrl <- %04x\n", dev_path(dev), ctrl);
        pci_write_config16(dev, PCI_CB_BRIDGE_CONTROL, ctrl);
+       printk(BIOS_DEBUG, "bridge_ctrl %04x\n", dev->link_list->bridge_ctrl);

        pci_dev_enable_resources(dev);
 }

Memtest86+ also passed the 3 GiB twice, but hung after 2:20 hours – maybe a thermal issue, or some problem in Memtest86+.

Anyway, RAM seems working.

My T60 does this as well.

While possibly unrelated...

What I do find curious to me after reading this that I do not recall having problems booting from hard drive in general until I swapped to 2x2GB of RAM which was never a problem before I swapped RAM -- while booting from USB or CD ROM works every time. Memtest doesn't seem to think anything is wrong with the RAM either. I do still have the (presumably) original RAM sticks that came with my T60. And this is from Coreboot built from a few days ago.

I won't have any time to test this for a few days, though. Stay tuned.