Hi,
I did some small changes in Config.lb and Options.lb and then I compiled the H8dmr_fam10 board to flash it in a H8qme-2+ board. And of course the booting fails :(:
(split)40K table at =dfff0000 0: mmio_basek=00380000, basek=00400000, limitk=00000000 1: mmio_basek=00380000, basek=00480000, limitk=00000000 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 ? VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device
and here it stucks and doesn't continues.
I attached several lspci outputs for the h8qme-2+ board and a complete log of the boot process.
Has someone an idea what is failing?
thanks in advanced, Knut Kujat.
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3) 00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2) 00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control 00:19.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration 00:19.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map 00:19.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller 00:19.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control 00:19.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control 00:1a.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration 00:1a.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map 00:1a.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller 00:1a.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control 00:1a.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control 00:1b.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration 00:1b.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map 00:1b.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller 00:1b.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control 00:1b.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control 01:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) 08:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8132 PCI-X Bridge (rev 12) 08:01.1 PIC: Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC (rev 12) 08:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8132 PCI-X Bridge (rev 12) 08:02.1 PIC: Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC (rev 12) 0a:03.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03) 0a:03.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03)
-+-[0000:08]-+-01.0-[09]-- | +-01.1 Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC [1022:7459] | +-02.0-[0a]--+-03.0 Intel Corporation 82546GB Gigabit Ethernet Controller [8086:1079] | | -03.1 Intel Corporation 82546GB Gigabit Ethernet Controller [8086:1079] | -02.1 Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC [1022:7459] -[0000:00]-+-00.0 nVidia Corporation MCP55 Memory Controller [10de:0369] +-01.0 nVidia Corporation MCP55 LPC Bridge [10de:0364] +-01.1 nVidia Corporation MCP55 SMBus [10de:0368] +-02.0 nVidia Corporation MCP55 USB Controller [10de:036c] +-02.1 nVidia Corporation MCP55 USB Controller [10de:036d] +-04.0 nVidia Corporation MCP55 IDE [10de:036e] +-05.0 nVidia Corporation MCP55 SATA Controller [10de:037f] +-05.1 nVidia Corporation MCP55 SATA Controller [10de:037f] +-05.2 nVidia Corporation MCP55 SATA Controller [10de:037f] +-06.0-[01]----01.0 ATI Technologies Inc ES1000 [1002:515e] +-0a.0-[02]-- +-0b.0-[03]-- +-0c.0-[04]-- +-0d.0-[05]-- +-0e.0-[06]-- +-0f.0-[07]-- +-18.0 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200] +-18.1 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map [1022:1201] +-18.2 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202] +-18.3 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203] +-18.4 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control [1022:1204] +-19.0 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200] +-19.1 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map [1022:1201] +-19.2 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202] +-19.3 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203] +-19.4 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control [1022:1204] +-1a.0 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200] +-1a.1 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map [1022:1201] +-1a.2 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202] +-1a.3 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203] +-1a.4 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control [1022:1204] +-1b.0 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200] +-1b.1 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map [1022:1201] +-1b.2 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202] +-1b.3 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203] -1b.4 Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control [1022:1204]
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) Subsystem: Super Micro Computer Inc Device 1311 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Capabilities: <access denied>
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3) Subsystem: Super Micro Computer Inc Device 1311 Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3) Subsystem: Super Micro Computer Inc Device 1311 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 5 Region 0: I/O ports at cc00 [size=64] Region 4: I/O ports at 2d00 [size=64] Region 5: I/O ports at 2e00 [size=64] Capabilities: <access denied> Kernel driver in use: nForce2_smbus
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) (prog-if 10 [OHCI]) Subsystem: Super Micro Computer Inc Device 1311 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 22 Region 0: Memory at dfebf000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: ohci_hcd
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) (prog-if 20 [EHCI]) Subsystem: Super Micro Computer Inc Device 1311 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 (750ns min, 250ns max) Interrupt: pin B routed to IRQ 23 Region 0: Memory at dfebec00 (32-bit, non-prefetchable) [size=256] Capabilities: <access denied> Kernel driver in use: ehci_hcd
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) (prog-if 8a [Master SecP PriP]) Subsystem: Super Micro Computer Inc Device 1311 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 (750ns min, 250ns max) Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8] Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1] Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8] Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1] Region 4: I/O ports at ffa0 [size=16] Capabilities: <access denied> Kernel driver in use: pata_amd
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) (prog-if 85 [Master SecO PriO]) Subsystem: Super Micro Computer Inc Device 1311 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 (750ns min, 250ns max) Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at c480 [size=8] Region 1: I/O ports at c400 [size=4] Region 2: I/O ports at c080 [size=8] Region 3: I/O ports at c000 [size=4] Region 4: I/O ports at bc00 [size=16] Region 5: Memory at dfebd000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: sata_nv
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) (prog-if 85 [Master SecO PriO]) Subsystem: Super Micro Computer Inc Device 1311 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 (750ns min, 250ns max) Interrupt: pin B routed to IRQ 20 Region 0: I/O ports at b880 [size=8] Region 1: I/O ports at b800 [size=4] Region 2: I/O ports at b480 [size=8] Region 3: I/O ports at b400 [size=4] Region 4: I/O ports at b080 [size=16] Region 5: Memory at dfebc000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: sata_nv
00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) (prog-if 85 [Master SecO PriO]) Subsystem: Super Micro Computer Inc Device 1311 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 (750ns min, 250ns max) Interrupt: pin C routed to IRQ 23 Region 0: I/O ports at b000 [size=8] Region 1: I/O ports at ac00 [size=4] Region 2: I/O ports at a880 [size=8] Region 3: I/O ports at a800 [size=4] Region 4: I/O ports at a480 [size=16] Region 5: Memory at dfebb000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: sata_nv
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2) (prog-if 01 [Subtractive decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: dff00000-dfffffff Prefetchable memory behind bridge: d0000000-d7ffffff Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr+ DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied>
00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fff00000-000fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport-driver
00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fff00000-000fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport-driver
00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fff00000-000fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport-driver
00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fff00000-000fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport-driver
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=06, subordinate=06, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fff00000-000fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport-driver
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=07, subordinate=07, sec-latency=0 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fff00000-000fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport-driver
00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Capabilities: <access denied>
00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Capabilities: <access denied>
00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:19.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Capabilities: <access denied>
00:19.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:19.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:19.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Capabilities: <access denied>
00:19.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:1a.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Capabilities: <access denied>
00:1a.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:1a.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:1a.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Capabilities: <access denied>
00:1a.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:1b.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Capabilities: <access denied>
00:1b.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:1b.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:1b.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Capabilities: <access denied>
00:1b.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
01:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) (prog-if 00 [VGA controller]) Subsystem: Super Micro Computer Inc Device 1311 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (2000ns min), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at d000 [size=256] Region 2: Memory at dfff0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at dff00000 [disabled] [size=128K] Capabilities: <access denied>
08:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8132 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 64 bytes Bus: primary=08, secondary=09, subordinate=09, sec-latency=64 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fff00000-000fffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied>
08:01.1 PIC: Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC (rev 12) (prog-if 10 [IO-APIC]) Subsystem: Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at cfeff000 (64-bit, non-prefetchable) [size=4K]
08:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8132 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 64 bytes Bus: primary=08, secondary=0a, subordinate=0a, sec-latency=64 I/O behind bridge: 0000e000-0000efff Memory behind bridge: cff00000-cfffffff Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied>
08:02.1 PIC: Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC (rev 12) (prog-if 10 [IO-APIC]) Subsystem: Advanced Micro Devices [AMD] AMD-8132 PCI-X IOAPIC Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at cfefe000 (64-bit, non-prefetchable) [size=4K]
0a:03.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03) Subsystem: Super Micro Computer Inc Device 117a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (63750ns min), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 47 Region 0: Memory at cffe0000 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at ec00 [size=64] Capabilities: <access denied> Kernel driver in use: e1000
0a:03.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet Controller (rev 03) Subsystem: Super Micro Computer Inc Device 117a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (63750ns min), Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 48 Region 0: Memory at cffa0000 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at e880 [size=64] Capabilities: <access denied> Kernel driver in use: e1000
On Thu, Dec 17, 2009 at 7:03 AM, Knut Kujat knuku@gap.upv.es wrote:
Hi,
I did some small changes in Config.lb and Options.lb and then I compiled the H8dmr_fam10 board to flash it in a H8qme-2+ board. And of course the booting fails :(:
(split)40K table at =dfff0000 0: mmio_basek=00380000, basek=00400000, limitk=00000000 1: mmio_basek=00380000, basek=00480000, limitk=00000000 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 ? VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device
and here it stucks and doesn't continues.
I'm not sure what the problem is, but your IO resources aren't getting set properly. Could you apply this patch and send the output?
I'm wondering if there's an error in the constraint code, a memory corruption problem, or an invalid resource declared.
Thanks, Myles
Myles Watson escribió:
On Thu, Dec 17, 2009 at 7:03 AM, Knut Kujat <knuku@gap.upv.es mailto:knuku@gap.upv.es> wrote:
Hi, I did some small changes in Config.lb and Options.lb and then I compiled the H8dmr_fam10 board to flash it in a H8qme-2+ board. And of course the booting fails :(: (split)40K table at =dfff0000 0: mmio_basek=00380000, basek=00400000, limitk=00000000 1: mmio_basek=00380000, basek=00480000, limitk=00000000 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 ? VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device and here it stucks and doesn't continues.I'm not sure what the problem is, but your IO resources aren't getting set properly. Could you apply this patch and send the output?
Yes, of course. Please find the new coreboot.log attached.
I'm wondering if there's an error in the constraint code, a memory corruption problem, or an invalid resource declared.
Thanks, Myles
As you can see I added some more printks and it got stuck in "set_io_addr_reg" for the first node?? Another thing very strange is that at "stage: loading fallback/coreboot_ram @ 0x200000 (1048576 bytes), entry @ 0x200000" it halts for about 2 minutes, a long time to load 1048576 bytes isn't it?
Thanks for all your help! Knut Kujat.
On Thu, Dec 17, 2009 at 10:27 AM, Knut Kujat knuku@gap.upv.es wrote:
Myles Watson escribió:
On Thu, Dec 17, 2009 at 7:03 AM, Knut Kujat <knuku@gap.upv.es mailto:knuku@gap.upv.es> wrote:
Hi, I did some small changes in Config.lb and Options.lb and then I compiled the H8dmr_fam10 board to flash it in a H8qme-2+ board. And of course the booting fails :(: (split)40K table at =dfff0000 0: mmio_basek=00380000, basek=00400000, limitk=00000000 1: mmio_basek=00380000, basek=00480000, limitk=00000000 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 ? VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device and here it stucks and doesn't continues.I'm not sure what the problem is, but your IO resources aren't getting set properly. Could you apply this patch and send the output?
Yes, of course. Please find the new coreboot.log attached.
avoid_fixed_resources: PCI_DOMAIN: 0000 avoid_fixed_resources:@PCI_DOMAIN: 0000 10000000 limit 000007ff avoid_fixed_resources:@PCI_DOMAIN: 0000 10000100 limit ffffffff
It turns out that the problem is before the print statements I inserted. For some reason, your domain's IO resource is only giving you 0x7ff of IO space. That's not enough. I can't see anywhere in the code where that would be coming from, so I'm assuming memory corruption. At this point the limit should still be 0000ffff.
Could you try increasing the stack and heap sizes? If that doesn't work we'll have to find where the limit is getting changed, since it's correct the first time that the resources are printed.
PCI_DOMAIN: 0000 links 1 child on link 0 PCI: 00:18.0 PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags 40040100 index 10000000 PCI_DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff flags 40040200 index 10000100
As you can see I added some more printks and it got stuck in "set_io_addr_reg" for the first node??
With invalid addresses, it's not too surprising that something breaks later.
Another thing very strange is that at "stage: loading fallback/coreboot_ram @ 0x200000 (1048576 bytes), entry @ 0x200000" it halts for about 2 minutes, a long time to load 1048576 bytes isn't it?
Fam10 seems to have problems with the MTRR settings. I'm not sure what they are, but yes it needs to be fixed. Ward has reported similar long load times.
Thanks, Myles
It turns out that the problem is before the print statements I inserted. For some reason, your domain's IO resource is only giving you 0x7ff of IO space. That's not enough. I can't see anywhere in the code where that would be coming from, so I'm assuming memory corruption. At this point the limit should still be 0000ffff.
Could you try increasing the stack and heap sizes? If that doesn't work we'll have to find where the limit is getting changed, since it's correct the first time that the resources are printed.
PNP: 002e.b resource base 290 size 8 align 3 gran 3 limit fff flags c0000100 index 60 PNP: 002e.b resource base 5 size 1 align 0 gran 0 limit 0 flags c0000400 index 70
PNP: 002e.3 links 0 child on link 0 NULL PNP: 002e.3 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100 index 60 PNP: 002e.3 resource base 0 size 1 align 0 gran 0 limit 0 flags 400 index 70 ... PCI: 00:06.2 20 * [0x1cf0 - 0x1cff] io PNP: 002e.3 60 * [0x2000 - 0x2007] io
Never mind about the memory corruption. PNP: 002e.3 has some resources that aren't "fixed", so the allocator is trying to allocate them. In the SuperIO code where those resources are declared, set the flags to match the other resources.
Thanks, Myles
Myles Watson escribió:
It turns out that the problem is before the print statements I inserted. For some reason, your domain's IO resource is only giving you 0x7ff of IO space. That's not enough. I can't see anywhere in the code where that would be coming from, so I'm assuming memory corruption. At this point the limit should still be 0000ffff. Could you try increasing the stack and heap sizes? If that doesn't work we'll have to find where the limit is getting changed, since it's correct the first time that the resources are printed. PNP: 002e.b resource base 290 size 8 align 3 gran 3 limit fffflags c0000100 index 60 PNP: 002e.b resource base 5 size 1 align 0 gran 0 limit 0 flags c0000400 index 70
PNP: 002e.3 links 0 child on link 0 NULL PNP: 002e.3 resource base 0 size 8 align 3 gran 3 limit 7ff flags100 index 60 PNP: 002e.3 resource base 0 size 1 align 0 gran 0 limit 0 flags 400 index 70 ... PCI: 00:06.2 20 * [0x1cf0 - 0x1cff] io PNP: 002e.3 60 * [0x2000 - 0x2007] io
Never mind about the memory corruption. PNP: 002e.3 has some resources that aren't "fixed", so the allocator is trying to allocate them. In the SuperIO code where those resources are declared, set the flags to match the other resources.
Problem solved I killed it :) means I disabled it in the device tree. The H9DMR board has two serials and my board H8QME has only one.
Now, I've got till the MTRR initialization and here is my reward:
POST: 0x93 Setting up local apic... apic_id: 0x0a done. POST: 0x9b CPU model: Quad-Core AMD Opteron(tm) Processor 8350 siblings = 03, CPU #10 initialized All AP CPUs stopped PCI: 00:18.0 init PCI: 00:02.0 init Unexpected Exception: 6 @ 10:00207ff1 - Halting Code: 0 eflags: 00010046 eax: 00000000 ebx: 00226358 ecx: 0021ea74 edx: 00000001 edi: 0021ea74 esi: 00000001 ebp: 0023fff4 esp: 0023ff50 POST: 0xff
the strange thing is that it seems to work for like 11 other cores. And this log is from my last try but before it always starts rebooting with SOFT RESET after: MTRR check Fixed MTRRs : Enabled
Attached there is the whole log its getting bigger but still not till the end :(
THX, Knut Kujat.
On Fri, Dec 18, 2009 at 8:41 AM, Knut Kujat knuku@gap.upv.es wrote:
Never mind about the memory corruption. PNP: 002e.3 has some resources that aren't "fixed", so the allocator is trying to allocate them. In the SuperIO code where those resources are declared, set the flags to match the other resources.
Problem solved I killed it :) means I disabled it in the device tree. The H9DMR board has two serials and my board H8QME has only one.
Great.
Now, I've got till the MTRR initialization and here is my reward:
POST: 0x93 Setting up local apic... apic_id: 0x0a done. POST: 0x9b CPU model: Quad-Core AMD Opteron(tm) Processor 8350 siblings = 03, CPU #10 initialized All AP CPUs stopped PCI: 00:18.0 init PCI: 00:02.0 init Unexpected Exception: 6 @ 10:00207ff1 - Halting Code: 0 eflags: 00010046 eax: 00000000 ebx: 00226358 ecx: 0021ea74 edx: 00000001 edi: 0021ea74 esi: 00000001 ebp: 0023fff4 esp: 0023ff50 POST: 0xff
the strange thing is that it seems to work for like 11 other cores. And this log is from my last try but before it always starts rebooting with SOFT RESET after:
Somebody else will probably know how to help you better. The first thing I would do is disable siblings (LOGICAL_PROCESSORS=0) and see if you can get past it or not.
Thanks, Myles
Myles Watson escribió:
On Fri, Dec 18, 2009 at 8:41 AM, Knut Kujat <knuku@gap.upv.es mailto:knuku@gap.upv.es> wrote:
Never mind about the memory corruption. PNP: 002e.3 has some resources that aren't "fixed", so the allocator is trying to allocate them. In the SuperIO code where those resources are declared, set the flags to match the other resources.Problem solved I killed it :) means I disabled it in the device tree. The H9DMR board has two serials and my board H8QME has only one.Great.
Now, I've got till the MTRR initialization and here is my reward: POST: 0x93 Setting up local apic... apic_id: 0x0a done. POST: 0x9b CPU model: Quad-Core AMD Opteron(tm) Processor 8350 siblings = 03, CPU #10 initialized All AP CPUs stopped PCI: 00:18.0 init PCI: 00:02.0 init Unexpected Exception: 6 @ 10:00207ff1 - Halting Code: 0 eflags: 00010046 eax: 00000000 ebx: 00226358 ecx: 0021ea74 edx: 00000001 edi: 0021ea74 esi: 00000001 ebp: 0023fff4 esp: 0023ff50 POST: 0xff the strange thing is that it seems to work for like 11 other cores. And this log is from my last try but before it always starts rebooting with SOFT RESET after:Somebody else will probably know how to help you better. The first thing I would do is disable siblings (LOGICAL_PROCESSORS=0) and see if you can get past it or not.
Thanks, Myles
Hello,
I now getting this: Setting fixed MTRRs(0-88) type: UC After Startup. Initializing CPU #0 DONE fixed MTRRs C
INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} ---
Issuing SOFT_RESET...
coreboot-2.0.0-r_Fallback lun dic 21 11:02:38 CET 2009 starting...
BSP Family_Model: 00100f22 *sysinfo range: [000cc000,000cdfa0] bsp_apicid = 00 cpu_init_detectedx = 00000000 microcode: equivalent rev id = 0x1022, current patch id = 0x00000000 microcode: rev id (1062) does not match this patch. microcode: Not updated! Fix microcode_updates[] cpuSetAMDMSR done ...blablabla
but I haven't changed anything but inserting some printk_spew into "void dev_initialize(void)" to see where exactly jumps the exception out.
I'm confused :(.
THX, Knut Kujat.
On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat knuku@gap.upv.es wrote:
but I haven't changed anything but inserting some printk_spew into "void dev_initialize(void)" to see where exactly jumps the exception out.
Did you try increasing the stack size? When you inserted the printk statements, were there any warnings about format strings not matching the number of arguments? Have you tried disabling the siblings yet?
Thanks, Myles
Myles Watson escribió:
On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat <knuku@gap.upv.es mailto:knuku@gap.upv.es> wrote:
but I haven't changed anything but inserting some printk_spew into "void dev_initialize(void)" to see where exactly jumps the exception out.Did you try increasing the stack size? When you inserted the printk statements, were there any warnings about format strings not matching the number of arguments? Have you tried disabling the siblings yet?
Thanks, Myles
Hello,
yes increasing stack size helped with the printks. And yes I tried to disable siblings by adding uses CONFIG_LOGICAL_PROCESSORS and default CONFIG_LOGICAL_PROCESSORS=0 to the Options.lb file but it complains at building time that this options is unkown so I uses LOGICAL_CPUS instead (is it the same?) without results.
CPU model: Quad-Core AMD Opteron(tm) Processor 8350 Setting up local apic...siblings = 03, apic_id: 0x09 done. CPU #14 initialized CPU model: Quad-Core AMD Opteron(tm) Processor 8350 Waiting for 1 CPUS to stop siblings = 03, CPU #9 initialized All AP CPUs stopped *** Debug: After init(dev); PCI: 00:18.0 init *** Debug: After init(dev); PCI: 00:02.0 init Unexpected Exception: 6 @ 10:00207fbd - Halting Code: 0 eflags: 00010013 eax: 00226358 ebx: 00226358 ecx: 0021ea74 edx: 00000001 edi: 0021ea74 esi: 00000001 ebp: 0023fff4 esp: 0023ff50
Now I know that the the exception comes up in the corresponding init(dev) for the PCI: 00:02.0 device. So I disabled PCI 2.0 in the device tree and it just doesn't has any effect even it tells me that PCI 2.0 enabled 0 at boot times, it stucks at the same place.
Thanks, Knut Kujat
On Mon, Dec 21, 2009 at 9:15 AM, Knut Kujat knuku@gap.upv.es wrote:
Myles Watson escribió:
On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat knuku@gap.upv.es wrote:
but I haven't changed anything but inserting some printk_spew into "void dev_initialize(void)" to see where exactly jumps the exception out.
Did you try increasing the stack size? When you inserted the printk statements, were there any warnings about format strings not matching the number of arguments? Have you tried disabling the siblings yet?
Thanks, Myles
Hello,
yes increasing stack size helped with the printks.
How big did you make it? Try making it bigger until it doesn't make a difference any more.
And yes I tried to disable siblings by adding uses CONFIG_LOGICAL_PROCESSORS and default CONFIG_LOGICAL_PROCESSORS=0 to the Options.lb file but it complains at building time that this options is unkown so I uses LOGICAL_CPUS instead (is it the same?) without results.
You found the right one. Sorry I steered you wrong. All the processors get initialized even with CONFIG_LOGICAL_CPUS=0? That's not good.
Now I know that the the exception comes up in the corresponding init(dev) for the PCI: 00:02.0 device. So I disabled PCI 2.0 in the device tree and it just doesn't has any effect even it tells me that PCI 2.0 enabled 0 at boot times, it stucks at the same place.
I don't think the init function is the problem. It's more likely that something is going wrong much earlier, and just catches up to you there. I would leave the device enabled.
Thanks, Myles
Myles Watson escribió:
On Mon, Dec 21, 2009 at 9:15 AM, Knut Kujat <knuku@gap.upv.es mailto:knuku@gap.upv.es> wrote:
Myles Watson escribió:On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat <knuku@gap.upv.es <mailto:knuku@gap.upv.es>> wrote: but I haven't changed anything but inserting some printk_spew into "void dev_initialize(void)" to see where exactly jumps the exception out. Did you try increasing the stack size? When you inserted the printk statements, were there any warnings about format strings not matching the number of arguments? Have you tried disabling the siblings yet? Thanks, MylesHello, yes increasing stack size helped with the printks.How big did you make it? Try making it bigger until it doesn't make a difference any more.
And yes I tried to disable siblings by adding uses CONFIG_LOGICAL_PROCESSORS and default CONFIG_LOGICAL_PROCESSORS=0 to the Options.lb file but it complains at building time that this options is unkown so I uses LOGICAL_CPUS instead (is it the same?) without results.You found the right one. Sorry I steered you wrong. All the processors get initialized even with CONFIG_LOGICAL_CPUS=0? That's not good.
Now I know that the the exception comes up in the corresponding init(dev) for the PCI: 00:02.0 device. So I disabled PCI 2.0 in the device tree and it just doesn't has any effect even it tells me that PCI 2.0 enabled 0 at boot times, it stucks at the same place.I don't think the init function is the problem. It's more likely that something is going wrong much earlier, and just catches up to you there. I would leave the device enabled.
Thanks, Myles
Morning,
stack_size = 0x4000 and seems to work fine.
Sorry, I didn't explain myself, changing CONFIG_LOGICAL_CPUS to 0 made the compile process fail in northbridge.c so I had to change it back. Yes disabling devices didn't make any difference so I leave them enabled.
hmmmm what else could I do??
THX,
Knut Kujat.
Hi Knut,
On Tue, Dec 22, 2009 at 10:25:06AM +0100, Knut Kujat wrote:
stack_size = 0x4000 and seems to work fine.
Sorry, I didn't explain myself, changing CONFIG_LOGICAL_CPUS to 0 made the compile process fail in northbridge.c so I had to change it back.
Yeah, that's because of this in northbridge.c:
#if CONFIG_LOGICAL_CPUS==1 #include <cpu/amd/quadcore.h> #include <pc80/mc146818rtc.h> #endif
The read_nb_cfg_54() function is defined in quadcore.h, so if you set CONFIG_LOGICAL_CPUS to zero compilation fails with an implicit definition error for read_nb_cfg_54.
The tree compiles for me if I comment out that if/endif lines and have CONFIG_LOGICAL_CPUS set to zero.
Thanks, Ward.
Hello,
as Myles suggested to disable siblings to see if I can pass through this weird exception and the impossibility to do so because of the compile error I changed the physical cpu option to 1 and it worked! But increasing it back to 2 or 4 made the exception come back again. I told you, Myles, I increased stack size to 4000 that was a filthy lie because I thought I'm increasing it to 4000 what I didn't see was that the same option was repeated at the end of the Options.lb file with STACK_SIZE=8000 (So I don't know why the printks started working). Now fooling around with stack size and setting it up to 10000 all 4 cpus started working and I got a grub menu :) in text mode :( so I have a graphics Initializing faild and Linux doesn't boot up completly.
I attached a complete log file, it is not so complete because the first lines of linux boot up are missing because I had to change serial speed on minicom. Thats because I'm having trouble of setting a speed and getting a total different one.
Now I thing that my device tree is not completely working and thats why linux got some collusion at the beginning ?? And I have no idea why graphic mode doesn't work since it looks like it finds vga without any problem.
Bye and thanks, Knut Kujat.
Ward Vandewege escribió:
Hi Knut,
On Tue, Dec 22, 2009 at 10:25:06AM +0100, Knut Kujat wrote:
stack_size = 0x4000 and seems to work fine.
Sorry, I didn't explain myself, changing CONFIG_LOGICAL_CPUS to 0 made the compile process fail in northbridge.c so I had to change it back.
Yeah, that's because of this in northbridge.c:
#if CONFIG_LOGICAL_CPUS==1 #include <cpu/amd/quadcore.h> #include <pc80/mc146818rtc.h> #endif
The read_nb_cfg_54() function is defined in quadcore.h, so if you set CONFIG_LOGICAL_CPUS to zero compilation fails with an implicit definition error for read_nb_cfg_54.
The tree compiles for me if I comment out that if/endif lines and have CONFIG_LOGICAL_CPUS set to zero.
Thanks, Ward.
On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat knuku@gap.upv.es wrote:
Hello,
as Myles suggested to disable siblings to see if I can pass through this weird exception and the impossibility to do so because of the compile error I changed the physical cpu option to 1 and it worked! But increasing it back to 2 or 4 made the exception come back again. I told you, Myles, I increased stack size to 4000 that was a filthy lie because I thought I'm increasing it to 4000 what I didn't see was that the same option was repeated at the end of the Options.lb file with STACK_SIZE=8000
It's always good to check targets/vendor/board/build/fallback/ldoptions to see what's really being used.
(So I don't know why the printks started working). Now fooling around with stack size and setting it up to 10000 all 4 cpus started working and I got a grub menu :) in text mode :( so I have a graphics Initializing faild and Linux doesn't boot up completly.
Great. I think we're getting to where we should add your board to the tree. Then we can see the device tree too.
I attached a complete log file, it is not so complete because the first lines of linux boot up are missing because I had to change serial speed on minicom. Thats because I'm having trouble of setting a speed and getting a total different one.
Now I thing that my device tree is not completely working and thats why linux got some collusion at the beginning ??
It device 0:02.3 isn't getting a driver. 1:06.0 is not found.
PCI: 08:01.0 Hypertransport link capability not foundPCI: pci_scan_bus for bus 08
That doesn't look good.
PCI: Left over static devices: PCI: 08:01.0 PCI: 08:01.1 PCI: 08:02.0
And I have no idea why graphic mode doesn't work since it looks like it finds vga without any problem.
VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device
That doesn't look right. I would think it's on link 0. I don't know why that's set wrong, but it would explain why it's not working.
Thanks, Myles
Myles Watson escribió:
On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat <knuku@gap.upv.es mailto:knuku@gap.upv.es> wrote:
Hello, as Myles suggested to disable siblings to see if I can pass through this weird exception and the impossibility to do so because of the compile error I changed the physical cpu option to 1 and it worked! But increasing it back to 2 or 4 made the exception come back again. I told you, Myles, I increased stack size to 4000 that was a filthy lie because I thought I'm increasing it to 4000 what I didn't see was that the same option was repeated at the end of the Options.lb file with STACK_SIZE=8000It's always good to check targets/vendor/board/build/fallback/ldoptions to see what's really being used.
(So I don't know why the printks started working). Now fooling around with stack size and setting it up to 10000 all 4 cpus started working and I got a grub menu :) in text mode :( so I have a graphics Initializing faild and Linux doesn't boot up completly.Great. I think we're getting to where we should add your board to the tree. Then we can see the device tree too.
I attached it.
I attached a complete log file, it is not so complete because the first lines of linux boot up are missing because I had to change serial speed on minicom. Thats because I'm having trouble of setting a speed and getting a total different one. Now I thing that my device tree is not completely working and thats why linux got some collusion at the beginning ??It device 0:02.3 isn't getting a driver. 1:06.0 is not found.
PCI: 08:01.0 Hypertransport link capability not foundPCI: pci_scan_bus for bus 08
That doesn't look good.
PCI: Left over static devices: PCI: 08:01.0 PCI: 08:01.1 PCI: 08:02.0
And I have no idea why graphic mode doesn't work since it looks like it finds vga without any problem.VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device
That doesn't look right. I would think it's on link 0. I don't know why that's set wrong, but it would explain why it's not working.
Thanks, Myles
## ## This file is part of the coreboot project. ## ## Copyright (C) 2007 AMD ## Written by Yinghai Lu yinghailu@amd.com for AMD. ## ## This program is free software; you can redistribute it and/or modify ## it under the terms of the GNU General Public License as published by ## the Free Software Foundation; either version 2 of the License, or ## (at your option) any later version. ## ## This program is distributed in the hope that it will be useful, ## but WITHOUT ANY WARRANTY; without even the implied warranty of ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ## GNU General Public License for more details. ## ## You should have received a copy of the GNU General Public License ## along with this program; if not, write to the Free Software ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ##
## CONFIG_XIP_ROM_SIZE must be a power of 2. # for testing with -O != s. FIXME #default CONFIG_XIP_ROM_SIZE = 128 * 1024 default CONFIG_XIP_ROM_SIZE = 128 * 1024 include /config/failovercalculation.lb
arch i386 end
## ## Build the objects we have code for in this directory. ##
driver mainboard.o #needed by irq_tables and mptable and acpi_tables object get_bus_conf.o
if CONFIG_GENERATE_MP_TABLE object mptable.o end if CONFIG_GENERATE_PIRQ_TABLE object irq_tables.o end
if CONFIG_USE_INIT makerule ./auto.o depends "$(CONFIG_MAINBOARD)/cache_as_ram_auto.c option_table.h" action "$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) -I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/cache_as_ram_auto.c -o $@" end else makerule ./auto.inc depends "$(CONFIG_MAINBOARD)/cache_as_ram_auto.c option_table.h" action "$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) $(DEBUG_CFLAGS) -I$(TOP)/src -I. -c -S $(CONFIG_MAINBOARD)/cache_as_ram_auto.c -o $@" action "perl -e 's/.rodata/.rom.data/g' -pi $@" action "perl -e 's/.text/.section .rom.text/g' -pi $@" end end
if CONFIG_USE_FAILOVER_IMAGE else if CONFIG_AP_CODE_IN_CAR makerule ./apc_auto.o depends "$(CONFIG_MAINBOARD)/apc_auto.c option_table.h" action "$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) -I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/apc_auto.c -o $@" end end end
## ## Build our 16 bit and 32 bit coreboot entry code ## if CONFIG_HAVE_FAILOVER_BOOT if CONFIG_USE_FAILOVER_IMAGE mainboardinit cpu/x86/16bit/entry16.inc ldscript /cpu/x86/16bit/entry16.lds end else if CONFIG_USE_FALLBACK_IMAGE mainboardinit cpu/x86/16bit/entry16.inc ldscript /cpu/x86/16bit/entry16.lds end end
mainboardinit cpu/x86/32bit/entry32.inc
if CONFIG_USE_INIT ldscript /cpu/x86/32bit/entry32.lds end
if CONFIG_USE_INIT ldscript /cpu/amd/car/cache_as_ram.lds end
## ## Build our reset vector (This is where coreboot is entered) ## if CONFIG_HAVE_FAILOVER_BOOT if CONFIG_USE_FAILOVER_IMAGE mainboardinit cpu/x86/16bit/reset16.inc ldscript /cpu/x86/16bit/reset16.lds else mainboardinit cpu/x86/32bit/reset32.inc ldscript /cpu/x86/32bit/reset32.lds end else if CONFIG_USE_FALLBACK_IMAGE mainboardinit cpu/x86/16bit/reset16.inc ldscript /cpu/x86/16bit/reset16.lds else mainboardinit cpu/x86/32bit/reset32.inc ldscript /cpu/x86/32bit/reset32.lds end end
## ## Include an id string (For safe flashing) ## mainboardinit arch/i386/lib/id.inc ldscript /arch/i386/lib/id.lds
## ## ROMSTRAP table for MCP55 ## if CONFIG_HAVE_FAILOVER_BOOT if CONFIG_USE_FAILOVER_IMAGE mainboardinit southbridge/nvidia/mcp55/romstrap.inc ldscript /southbridge/nvidia/mcp55/romstrap.lds end else if CONFIG_USE_FALLBACK_IMAGE mainboardinit southbridge/nvidia/mcp55/romstrap.inc ldscript /southbridge/nvidia/mcp55/romstrap.lds end end
## ## Setup Cache-As-Ram ## mainboardinit cpu/amd/car/cache_as_ram.inc
### ### This is the early phase of coreboot startup ### Things are delicate and we test to see if we should ### failover to another image. ### if CONFIG_HAVE_FAILOVER_BOOT if CONFIG_USE_FAILOVER_IMAGE ldscript /arch/i386/lib/failover_failover.lds end else if CONFIG_USE_FALLBACK_IMAGE ldscript /arch/i386/lib/failover.lds end end
## ## Setup RAM ## if CONFIG_USE_INIT initobject auto.o else mainboardinit ./auto.inc end
## ## Include the secondary Configuration files ## config chip.h
dir /southbridge/nvidia/mcp55
chip northbridge/amd/amdfam10/root_complex device apic_cluster 0 on chip cpu/amd/socket_F_1207 device apic 0 on end end end device pci_domain 0 on chip northbridge/amd/amdfam10 #mc0 device pci 18.0 on end device pci 18.0 on end device pci 18.0 on # SB on link 2.0 chip southbridge/nvidia/mcp55 device pci 0.0 on end # HT device pci 1.0 on # LPC chip superio/winbond/w83627hf device pnp 2e.0 off # Floppy io 0x60 = 0x3f0 irq 0x70 = 6 drq 0x74 = 2 end device pnp 2e.1 off # Parallel Port io 0x60 = 0x378 irq 0x70 = 7 end device pnp 2e.2 on # Com1 io 0x60 = 0x3f8 irq 0x70 = 4 end device pnp 2e.3 off # Com2 io 0x60 = 0x2f8 irq 0x70 = 3 end device pnp 2e.5 on # Keyboard io 0x60 = 0x60 io 0x62 = 0x64 irq 0x70 = 1 irq 0x72 = 12 end device pnp 2e.6 off # SFI io 0x62 = 0x100 end device pnp 2e.7 off # GPIO_GAME_MIDI io 0x60 = 0x220 io 0x62 = 0x300 irq 0x70 = 9 end device pnp 2e.8 off end # WDTO_PLED device pnp 2e.9 off end # GPIO_SUSLED device pnp 2e.a off end # ACPI device pnp 2e.b on # HW Monitor io 0x60 = 0x290 irq 0x70 = 5 end end end device pci 1.1 on # SM 0 chip drivers/generic/generic #dimm 0-0-0 device i2c 50 on end end chip drivers/generic/generic #dimm 0-0-1 device i2c 51 on end end chip drivers/generic/generic #dimm 0-1-0 device i2c 52 on end end chip drivers/generic/generic #dimm 0-1-1 device i2c 53 on end end chip drivers/generic/generic #dimm 1-0-0 device i2c 54 on end end chip drivers/generic/generic #dimm 1-0-1 device i2c 55 on end end chip drivers/generic/generic #dimm 1-1-0 device i2c 56 on end end chip drivers/generic/generic #dimm 1-1-1 device i2c 57 on end end chip drivers/generic/generic #dimm 2-0-0 device i2c 58 on end end chip drivers/generic/generic #dimm 2-0-1 device i2c 59 on end end chip drivers/generic/generic #dimm 2-1-0 device i2c 5a on end end chip drivers/generic/generic #dimm 2-1-1 device i2c 5b on end end chip drivers/generic/generic #dimm 3-0-0 device i2c 5c on end end chip drivers/generic/generic #dimm 3-0-1 device i2c 5d on end end chip drivers/generic/generic #dimm 3-1-0 device i2c 5e on end end chip drivers/generic/generic #dimm 3-1-1 device i2c 5f on end end
end # SM device pci 1.1 on # SM 1 #PCI device smbus address will diepend on addon pci device, do we need to scan_smbus_bus? # chip drivers/generic/generic #PCIXA Slot1 # device i2c 50 on end # end # chip drivers/generic/generic #PCIXB Slot1 # device i2c 51 on end # end # chip drivers/generic/generic #PCIXB Slot2 # device i2c 52 on end # end # chip drivers/generic/generic #PCI Slot1 # device i2c 53 on end # end # chip drivers/generic/generic #Master MCP55 PCI-E # device i2c 54 on end # end # chip drivers/generic/generic #Slave MCP55 PCI-E # device i2c 55 on end # end chip drivers/generic/generic #MAC EEPROM device i2c 51 on end end
end # SM device pci 2.0 on end # USB 1.1 device pci 2.1 on end # USB 2 device pci 4.0 on end # IDE device pci 5.0 on end # SATA 0 device pci 5.1 on end # SATA 1 device pci 5.2 on end # SATA 2 device pci 6.0 on # PCI device pci 6.0 on end end device pci 6.1 off end # AZA #device pci 8.0 on end # NIC #device pci 9.0 on end # NIC device pci a.0 on end # PCI E 5 #device pci 0.0 on #nec pci-x #end #device pci 0.1 on #nec pci-x # device pci 4.0 on end #scsi # device pci 4.1 on end #scsi #end #ind device pci b.0 on end # PCI E 4 device pci c.0 on end # PCI E 3 device pci d.0 on end # PCI E 2 device pci e.0 on end # PCI E 1 device pci f.0 on end # PCI E 0 register "ide0_enable" = "1" register "sata0_enable" = "1" register "sata1_enable" = "1" register "mac_eeprom_smbus" = "3" # 1: smbus under 2e.8, 2: SM0 3: SM1 register "mac_eeprom_addr" = "0x51" end end # device pci 18.0 device pci 18.1 on end device pci 18.2 on end device pci 18.3 on end device pci 18.4 on end device pci 19.0 on end device pci 19.0 on end device pci 19.0 on chip southbridge/amd/amd8132 device pci 1.0 on end device pci 1.1 on end device pci 2.0 on device pci 3.0 on end device pci 3.1 on end end end #amd8132 end #device pci 19.0 device pci 19.1 on end device pci 19.2 on end device pci 19.3 on end device pci 19.4 on end device pci 1a.0 on end #link 0 device pci 1a.0 on end #link 1 device pci 1a.0 on end #link 2 device pci 1a.1 on end device pci 1a.2 on end device pci 1a.3 on end device pci 1a.4 on end device pci 1b.0 on end #link 0 device pci 1b.0 on end #link 1 device pci 1b.0 on end #link 2 device pci 1b.1 on end device pci 1b.2 on end device pci 1b.3 on end device pci 1b.4 on end end # mc0 end # PCI domain # chip drivers/generic/debug # device pnp 0.0 off end # chip name # device pnp 0.1 on end # pci_regs_all # device pnp 0.2 off end # mem # device pnp 0.3 off end # cpuid # device pnp 0.4 on end # smbus_regs_all # device pnp 0.5 off end # dual core msr # device pnp 0.6 off end # cache size # device pnp 0.7 off end # tsc # device pnp 0.8 off end # io # device pnp 0.9 on end # io # end end #root_complex
On Tue, Dec 22, 2009 at 11:38 AM, Knut Kujat knuku@gap.upv.es wrote:
Myles Watson escribió:
On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat knuku@gap.upv.es wrote:
Hello,
as Myles suggested to disable siblings to see if I can pass through this weird exception and the impossibility to do so because of the compile error I changed the physical cpu option to 1 and it worked! But increasing it back to 2 or 4 made the exception come back again. I told you, Myles, I increased stack size to 4000 that was a filthy lie because I thought I'm increasing it to 4000 what I didn't see was that the same option was repeated at the end of the Options.lb file with STACK_SIZE=8000
It's always good to check targets/vendor/board/build/fallback/ldoptions to see what's really being used.
(So I don't know why the printks started working). Now fooling around with stack size and setting it up to 10000 all 4 cpus started working and I got a grub menu :) in text mode :( so I have a graphics Initializing faild and Linux doesn't boot up completly.
Great. I think we're getting to where we should add your board to the tree. Then we can see the device tree too.
I attached it.
I attached a complete log file, it is not so complete because the first lines of linux boot up are missing because I had to change serial speed on minicom. Thats because I'm having trouble of setting a speed and getting a total different one.
Now I thing that my device tree is not completely working and thats why linux got some collusion at the beginning ??
It device 0:02.3 isn't getting a driver. 1:06.0 is not found.
PCI: 08:01.0 Hypertransport link capability not foundPCI: pci_scan_bus for bus 08
That doesn't look good.
PCI: Left over static devices: PCI: 08:01.0 PCI: 08:01.1 PCI: 08:02.0
device pci_domain 0 on chip northbridge/amd/amdfam10 #mc0 device pci 18.0 on end device pci 18.0 on end device pci 18.0 on # SB on link 2.0
So it really is on link 2? I forgot that these boards like to be different.
chip southbridge/nvidia/mcp55 device pci 0.0 on end # HT device pci 1.0 on # LPC
device pci 2.0 on end # USB 1.1 device pci 2.1 on end # USB 2 device pci 4.0 on end # IDE device pci 5.0 on end # SATA 0 device pci 5.1 on end # SATA 1 device pci 5.2 on end # SATA 2 device pci 6.0 on # PCI
This device should be removed.
device pci 6.0 on end
end device pci 6.1 off end # AZA #device pci 8.0 on end # NIC #device pci 9.0 on end # NIC device pci a.0 on end # PCI E 5 #device pci 0.0 on #necpci-x #end #device pci 0.1 on #nec pci-x # device pci 4.0 on end #scsi # device pci 4.1 on end #scsi #end #ind device pci b.0 on end # PCI E 4 device pci c.0 on end # PCI E 3 device pci d.0 on end # PCI E 2 device pci e.0 on end # PCI E 1 device pci f.0 on end # PCI E 0 register "ide0_enable" = "1" register "sata0_enable" = "1" register "sata1_enable" = "1" register "mac_eeprom_smbus" = "3" # 1: smbus under 2e.8, 2: SM0 3: SM1 register "mac_eeprom_addr" = "0x51" end end # device pci 18.0 device pci 18.1 on end device pci 18.2 on end device pci 18.3 on end device pci 18.4 on end device pci 19.0 on end device pci 19.0 on end device pci 19.0 on chip southbridge/amd/amd8132 device pci 1.0 on end device pci 1.1 on end device pci 2.0 on device pci 3.0 on end device pci 3.1 on end end end #amd8132
end #device pci 19.0 device pci 19.1 on end device pci 19.2 on end device pci 19.3 on end device pci 19.4 on end
These should be found automatically, so you can remove them.
device pci 1a.0 on end #link 0 device pci 1a.0 on end #link 1 device pci 1a.0 on end #link 2 device pci 1a.1 on end device pci 1a.2 on end device pci 1a.3 on end device pci 1a.4 on end device pci 1b.0 on end #link 0 device pci 1b.0 on end #link 1 device pci 1b.0 on end #link 2 device pci 1b.1 on end device pci 1b.2 on end device pci 1b.3 on end device pci 1b.4 on end
end # mc0 end # PCI domain
This would be easier to do in a different editor and if it were indented correctly. Is there a reason not to check it in?
In your log I noticed that Linux was doing a fast boot. Does that mean that it skips some initialization?
Thanks, Myles
This would be easier to do in a different editor and if it were indented correctly. Is there a reason not to check it in?
Sorry. I just noticed that it was my mail reader that inlined it, not you.
Myles
Now I thing that my device tree is not completely working and thats why
linux got some collusion at the beginning ?? And I have no idea why graphic mode doesn't work since it looks like it finds vga without any problem.
Scan for VGA option rom Got ps2 nak (status=51); continuing ps2_recvbyte timeout
I can't see your VGA ROM getting run anywhere. Did I just miss it?
You could try having Coreboot run it with vm86 and with CONFIG_CONSOLE_VGA set to see if that works. I'm wondering why SeaBIOS isn't finding it.
Thanks, Myles
Myles Watson escribió:
Now I thing that my device tree is not completely working and thats why linux got some collusion at the beginning ?? And I have no idea why graphic mode doesn't work since it looks like it finds vga without any problem.Scan for VGA option rom Got ps2 nak (status=51); continuing ps2_recvbyte timeout
I can't see your VGA ROM getting run anywhere. Did I just miss it?
Nop, not working anywhere seems like Seabios doesn't find any vga rom. So I tried setting up CONFIG_SB_HT_CHAIN_ON_BUS0 to different values, no luck!
You could try having Coreboot run it with vm86 and with CONFIG_CONSOLE_VGA set to see if that works. I'm wondering why SeaBIOS isn't finding it.
CONFIG_CONSOLE_VGA was already set to 1. How do I run coreboot with vm86?
Thanks, Myles
At least now at linux boot up my NICs are found but trying to initialize they got to a "Unable to allocate interrupt" :( I attach my latest log.
Now, I wishing all of you a merry merry XMAS and have some nice holidays. I hope Santa, or who ever, brings you a whole bunch of new boards ;).
Bye and thank you, Knut Kujat.
Scan for VGA option rom Got ps2 nak (status=51); continuing ps2_recvbyte timeout
I can't see your VGA ROM getting run anywhere. Did I just miss it?
Nop, not working anywhere seems like Seabios doesn't find any vga rom.
You could try a more verbose setting for SeaBIOS and send the output to Kevin. I'm surprised it doesn't just work.
So I tried setting up CONFIG_SB_HT_CHAIN_ON_BUS0 to different values, no luck!
Yeah. It doesn't seem like an enumeration problem. The device tree seems like it's getting set up pretty well.
You could try having Coreboot run it with vm86 and with CONFIG_CONSOLE_VGA set to see if that works. I'm wondering why SeaBIOS isn't finding it.
CONFIG_CONSOLE_VGA was already set to 1. How do I run coreboot with vm86?
CONFIG_VGA_ROM_RUN =1 In Kconfig there's a VM86 option, but I don't see it in newconfig.
At least now at linux boot up my NICs are found but trying to initialize they got to a "Unable to allocate interrupt" :( I attach my latest log.
Did you change the mptable and irqtables to match the factory assignments?
Now, I wishing all of you a merry merry XMAS and have some nice holidays. I hope Santa, or who ever, brings you a whole bunch of new boards ;).
Thanks. Merry Christmas to you too.
Myles
Myles Watson escribió:
Scan for VGA option rom Got ps2 nak (status=51); continuing ps2_recvbyte timeout
I can't see your VGA ROM getting run anywhere. Did I just miss it?
Nop, not working anywhere seems like Seabios doesn't find any vga rom.
You could try a more verbose setting for SeaBIOS and send the output to Kevin. I'm surprised it doesn't just work.
So I tried setting up CONFIG_SB_HT_CHAIN_ON_BUS0 to different values, no luck!
Yeah. It doesn't seem like an enumeration problem. The device tree seems like it's getting set up pretty well.
You could try having Coreboot run it with vm86 and with CONFIG_CONSOLE_VGA set to see if that works. I'm wondering why SeaBIOS isn't finding it.
CONFIG_CONSOLE_VGA was already set to 1. How do I run coreboot with vm86?
CONFIG_VGA_ROM_RUN =1 In Kconfig there's a VM86 option, but I don't see it in newconfig.
At least now at linux boot up my NICs are found but trying to initialize they got to a "Unable to allocate interrupt" :( I attach my latest log.
Did you change the mptable and irqtables to match the factory assignments?
I thought they got set up by code and I don't have to touch anything. Am I wrong? If so what and where do I have to do changes since mptable.c and irq_table.c is all code.
I attached a log with seabios set up on debug level 6, is this the highest one? because 7 and 8 made compilation fail.
THX, Knut Kujat
On Mon, Dec 28, 2009 at 3:26 AM, Knut Kujat knuku@gap.upv.es wrote:
Myles Watson escribió:
Scan for VGA option rom Got ps2 nak (status=51); continuing ps2_recvbyte timeout
I can't see your VGA ROM getting run anywhere. Did I just miss it?
Nop, not working anywhere seems like Seabios doesn't find any vga rom.
You could try a more verbose setting for SeaBIOS and send the output to Kevin. I'm surprised it doesn't just work.
So I tried setting up CONFIG_SB_HT_CHAIN_ON_BUS0 to different values, no luck!
Yeah. It doesn't seem like an enumeration problem. The device tree
seems
like it's getting set up pretty well.
You could try having Coreboot run it with vm86 and with CONFIG_CONSOLE_VGA set to see if that works. I'm wondering why SeaBIOS isn't finding it.
CONFIG_CONSOLE_VGA was already set to 1. How do I run coreboot with
vm86?
CONFIG_VGA_ROM_RUN =1 In Kconfig there's a VM86 option, but I don't see it in newconfig.
At least now at linux boot up my NICs are found but trying to initialize they got to a "Unable to allocate interrupt" :( I attach my latest log.
Did you change the mptable and irqtables to match the factory
assignments?
I thought they got set up by code and I don't have to touch anything. Am I wrong? If so what and where do I have to do changes since mptable.c and irq_table.c is all code.
in mptable.c:
dev = dev_find_slot(m->bus_mcp55[0], PCI_DEVFN(sbdn+ 0x1,0)); if (dev) { res = find_resource(dev, PCI_BASE_ADDRESS_1); if (res) { smp_write_ioapic(mc, m->apicid_mcp55, 0x11, res->base); }
/* These three values are interrupt routing values. */ dword = 0x43c6c643; pci_write_config32(dev, 0x7c, dword);
dword = 0x81001a00; pci_write_config32(dev, 0x80, dword);
dword = 0xd00012d2; pci_write_config32(dev, 0x84, dword);
}
Unfortunately, it's undocumented, so you have a couple of options: 1. Look at http://www.coreboot.org/Nvidia_MCP55_Porting_Notes 2. Decode the ACPI interrrupt assignments
Either way you may need to look at the interrupt assignments in Linux when booted with the factory BIOS.
I attached a log with seabios set up on debug level 6,
That was high enough. You can also change the debugging level of any component in config.h
From your log:
Attempting to map option rom on dev 01:01.0 Option rom sizing returned fc000001 fffe0000 Inspecting possible rom at 0xfc000000 (dv=515e1002 bdf=108) No option rom signature (got 7373)
This looks like the right device, so I don't know why the signature isn't valid. You could try reading the ROM in Linux and seeing if you don't get a valid signature. You could put the ROM into CBFS with a valid signature and try again. Some extra debugging output might help here. I guess you could ignore the signature too, just to see.
is this the
highest one? because 7 and 8 made compilation fail.
That's not good. You could send the log of the failing build to the list, or play around to see what component is having trouble.
Thanks, Myles
Myles Watson escribió:
On Mon, Dec 28, 2009 at 3:26 AM, Knut Kujat <knuku@gap.upv.es mailto:knuku@gap.upv.es> wrote:
Myles Watson escribió: >>> Scan for VGA option rom >>> Got ps2 nak (status=51); continuing >>> ps2_recvbyte timeout >>> >>> I can't see your VGA ROM getting run anywhere. Did I just miss it? >>> >> Nop, not working anywhere seems like Seabios doesn't find any vga rom. >> > You could try a more verbose setting for SeaBIOS and send the output to > Kevin. I'm surprised it doesn't just work. > > >> So I tried setting up CONFIG_SB_HT_CHAIN_ON_BUS0 to different values, no >> luck! >> > Yeah. It doesn't seem like an enumeration problem. The device tree seems > like it's getting set up pretty well. > > >>> You could try having Coreboot run it with vm86 and with >>> CONFIG_CONSOLE_VGA set to see if that works. I'm wondering why >>> SeaBIOS isn't finding it. >>> >>> >> CONFIG_CONSOLE_VGA was already set to 1. How do I run coreboot with vm86? >> > CONFIG_VGA_ROM_RUN =1 > In Kconfig there's a VM86 option, but I don't see it in newconfig. > > >> At least now at linux boot up my NICs are found but trying to initialize >> they got to a "Unable to allocate interrupt" :( I attach my latest log. >> > Did you change the mptable and irqtables to match the factory assignments? > I thought they got set up by code and I don't have to touch anything. Am I wrong? If so what and where do I have to do changes since mptable.c and irq_table.c is all code.in mptable.c:
dev = dev_find_slot(m->bus_mcp55[0], PCI_DEVFN(sbdn+ 0x1,0)); if (dev) { res = find_resource(dev, PCI_BASE_ADDRESS_1); if (res) { smp_write_ioapic(mc, m->apicid_mcp55, 0x11, res->base); }/* These three values are interrupt routing values. */ dword = 0x43c6c643; pci_write_config32(dev, 0x7c, dword);
dword = 0x81001a00; pci_write_config32(dev, 0x80, dword); dword = 0xd00012d2; pci_write_config32(dev, 0x84, dword); }Unfortunately, it's undocumented, so you have a couple of options:
- Look at http://www.coreboot.org/Nvidia_MCP55_Porting_Notes
- Decode the ACPI interrrupt assignments
Either way you may need to look at the interrupt assignments in Linux when booted with the factory BIOS.
I'm wondering if it isn't possible to just read those registers out once booted with a factory BIOS?
I attached a log with seabios set up on debug level 6,That was high enough. You can also change the debugging level of any component in config.h
From your log:
Attempting to map option rom on dev 01:01.0 Option rom sizing returned fc000001 fffe0000 Inspecting possible rom at 0xfc000000 (dv=515e1002 bdf=108) No option rom signature (got 7373)This looks like the right device, so I don't know why the signature isn't valid. You could try reading the ROM in Linux and seeing if you don't get a valid signature. You could put the ROM into CBFS with a valid signature and try again. Some extra debugging output might help here. I guess you could ignore the signature too, just to see.
is this the highest one? because 7 and 8 made compilation fail.That's not good. You could send the log of the failing build to the list, or play around to see what component is having trouble.
Using SeaBios 5.0 it "accepts" level 8 for debugging, but still no luck with the vga initialization. It doesn't even seem to be SeaBios "fault" because Coreboot complains exactly the same story:
PCI: 01:01.0 init Check CBFS header at fffc1fe0 magic is 4f524243 Found CBFS header at fffc1fe0 Check normal/payload CBFS: follow chain: fff00000 + 28 + 13038 + align -> fff13080 Check normal/coreboot_ram CBFS: follow chain: fff13080 + 38 + e481 + align -> fff21540 Check fallback/payload CBFS: follow chain: fff21540 + 38 + 13038 + align -> fff345c0 Check fallback/coreboot_ram CBFS: follow chain: fff345c0 + 38 + e296 + align -> fff428c0 Check CBFS: follow chain: fff428c0 + 28 + 7f6f8 + align -> fffc2000 CBFS: Could not find file pci1002,515e.rom On card, rom address for PCI: 01:01.0 = fc000000 PCI Expansion ROM, signature 0x7373, INIT size 0xe600, data ptr 0x7373 Incorrect Expansion ROM Header Signature 7373
Another thing is a line from the booting linux: Found 2 Quad-Core AMD Opteron(tm) Processor 8350 processors (16 cpu cores) (version 2.20.00) But there are 4 and I thing that coreboot finds them. So here my question could these problems be related to my bad IRQ handling ?
THX, Knut Kujat.
Unfortunately, it's undocumented, so you have a couple of options:
- Look at http://www.coreboot.org/Nvidia_MCP55_Porting_Notes
- Decode the ACPI interrrupt assignments
Either way you may need to look at the interrupt assignments in Linux when booted with the factory BIOS.
I'm wondering if it isn't possible to just read those registers out once booted with a factory BIOS?
You can. You still have to make the mptable and irq table match, which requires you to know what the values mean.
Using SeaBios 5.0 it "accepts" level 8 for debugging, but still no luck with the vga initialization. It doesn't even seem to be SeaBios "fault" because Coreboot complains exactly the same story:
PCI: 01:01.0 init
CBFS: Could not find file pci1002,515e.rom
You could read the ROM, correct the signature, and put it in CBFS as pci1002,515e.rom
On card, rom address for PCI: 01:01.0 = fc000000 PCI Expansion ROM, signature 0x7373, INIT size 0xe600, data ptr 0x7373 Incorrect Expansion ROM Header Signature 7373
You're right. It looks like the signature in your ROM is not coming out correctly. You need to figure out why, or just try to ignore the bad signature and see if you can get past it. In Linux with the factory BIOS you could see if the signature is still broken.
Another thing is a line from the booting linux: Found 2 Quad-Core AMD Opteron(tm) Processor 8350 processors (16 cpu cores) (version 2.20.00) But there are 4 and I thing that coreboot finds them. So here my question could these problems be related to my bad IRQ handling ?
I don't know where Linux got that information. It looks like it found all 16 cores, though.
Thanks, Myles
Myles Watson escribió:
Unfortunately, it's undocumented, so you have a couple of options:
- Look at http://www.coreboot.org/Nvidia_MCP55_Porting_Notes
- Decode the ACPI interrrupt assignments
Either way you may need to look at the interrupt assignments in Linux when booted with the factory BIOS.
I'm wondering if it isn't possible to just read those registers out once booted with a factory BIOS?
You can. You still have to make the mptable and irq table match, which requires you to know what the values mean.
at irq table you mean this values:
write_pirq_info(pirq_info, m->bus_mcp55[0], ((sbdn+6)<<3)|0, 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0); <<< this
pirq_info++; slot_num++;
for(i=1; i< sysconf.hc_possible_num; i++) { if(!(sysconf.pci1234[i] & 0x1) ) continue; unsigned busn = (sysconf.pci1234[i] >> 12) & 0xff; unsigned devn = sysconf.hcdn[i] & 0xff;
write_pirq_info(pirq_info, busn, (devn<<3)|0, 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0); <<< and this. pirq_info++; slot_num++; }
Sorry for those noob questions but this is getting much deeper i thought it would go. ;)
Using SeaBios 5.0 it "accepts" level 8 for debugging, but still no luck with the vga initialization. It doesn't even seem to be SeaBios "fault" because Coreboot complains exactly the same story:
PCI: 01:01.0 init
CBFS: Could not find file pci1002,515e.rom
You could read the ROM, correct the signature, and put it in CBFS as pci1002,515e.rom
On card, rom address for PCI: 01:01.0 = fc000000 PCI Expansion ROM, signature 0x7373, INIT size 0xe600, data ptr 0x7373 Incorrect Expansion ROM Header Signature 7373
You're right. It looks like the signature in your ROM is not coming out correctly. You need to figure out why, or just try to ignore the bad signature and see if you can get past it. In Linux with the factory BIOS you could see if the signature is still broken.
OK I'll will first try to make my irqs work after. Because I think most of the trouble is coming from there. One difference I noticed between my lspci -tvnn output and coreboot is that the ati es 1000 is at bus 6 on the lspci output and on bus 7 at coreboot.
+-05.0 nVidia Corporation MCP55 SATA Controller [10de:037f] +-05.1 nVidia Corporation MCP55 SATA Controller [10de:037f] +-05.2 nVidia Corporation MCP55 SATA Controller [10de:037f] +-06.0-[01]----01.0 ATI Technologies Inc ES1000 [1002:515e] +-0a.0-[02]-- +-0b.0-[03]-- +-0c.0-[04]--
and
PCI: 00:07.0 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 80202 index 20 PCI: 01:01.0 links 0 child on link 0 NULL PCI: 01:01.0 resource base 0 size 8000000 align 27 gran 27 limit ffffffff flags 1200 index 10 PCI: 01:01.0 resource base 0 size 100 align 8 gran 8 limit ffff flags 100 index 14 PCI: 01:01.0 resource base 0 size 10000 align 16 gran 16 limit ffffffff flags 200 index 18 PCI: 01:01.0 resource base 0 size 20000 align 17 gran 17 limit ffffffff flags 2200 index 30
Is this just a different kind of enumeration or an error?
thx again, again and again, Knut Kujat.
-----Original Message----- From: Knut Kujat [mailto:knuku@gap.upv.es] Sent: Wednesday, December 30, 2009 3:09 AM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió:
Unfortunately, it's undocumented, so you have a couple of options:
- Look at http://www.coreboot.org/Nvidia_MCP55_Porting_Notes
- Decode the ACPI interrrupt assignments
Either way you may need to look at the interrupt assignments in Linux when booted with the factory BIOS.
I'm wondering if it isn't possible to just read those registers out
once
booted with a factory BIOS?
You can. You still have to make the mptable and irq table match, which requires you to know what the values mean.
at irq table you mean this values:
write_pirq_info(pirq_info, m->bus_mcp55[0], ((sbdn+6)<<3)|0, 0x1, 0xdef8, 0x2, 0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0); <<< this
pirq_info++; slot_num++; for(i=1; i< sysconf.hc_possible_num; i++) { if(!(sysconf.pci1234[i] & 0x1) ) continue; unsigned busn = (sysconf.pci1234[i] >> 12) & 0xff; unsigned devn = sysconf.hcdn[i] & 0xff; write_pirq_info(pirq_info, busn, (devn<<3)|0, 0x1, 0xdef8, 0x2,0xdef8, 0x3, 0xdef8, 0x4, 0xdef8, 0, 0); <<< and this. pirq_info++; slot_num++; }
Yes. I've never actually used it because I used the ACPI DSDT to specify the same things, but that's what I meant.
Sorry for those noob questions but this is getting much deeper i thought it would go. ;)
No problem.
OK I'll will first try to make my irqs work after. Because I think most of the trouble is coming from there.
Sure.
One difference I noticed between my lspci -tvnn output and coreboot is that the ati es 1000 is at bus 6 on the lspci output and on bus 7 at coreboot.
+-05.0 nVidia Corporation MCP55 SATA Controller [10de:037f] +-05.1 nVidia Corporation MCP55 SATA Controller [10de:037f] +-05.2 nVidia Corporation MCP55 SATA Controller [10de:037f] +-06.0-[01]----01.0 ATI Technologies Inc ES1000 [1002:515e] +-0a.0-[02]-- +-0b.0-[03]-- +-0c.0-[04]--
The way I read this is device 6.0 has bus number 1 with device 1.
and
PCI: 00:07.0 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 80202 index 20 PCI: 01:01.0 links 0 child on link 0 NULL PCI: 01:01.0 resource base 0 size 8000000 align 27 gran 27 limit ffffffff flags 1200 index 10 PCI: 01:01.0 resource base 0 size 100 align 8 gran 8 limit ffff flags 100 index 14 PCI: 01:01.0 resource base 0 size 10000 align 16 gran 16 limit ffffffff flags 200 index 18 PCI: 01:01.0 resource base 0 size 20000 align 17 gran 17 limit ffffffff flags 2200 index 30
Is this just a different kind of enumeration or an error?
Just a different kind of enumeration. HyperTransport devices can be enumerated at different offsets (in HT terminology "assigned a different UnitID") with no problem.
Good luck.
Myles
On Tue, Dec 29, 2009 at 03:10:50PM +0100, Knut Kujat wrote:
Myles Watson escribió:
From your log:
Attempting to map option rom on dev 01:01.0 Option rom sizing returned fc000001 fffe0000 Inspecting possible rom at 0xfc000000 (dv=515e1002 bdf=108) No option rom signature (got 7373)This looks like the right device, so I don't know why the signature isn't valid.
Using SeaBios 5.0 it "accepts" level 8 for debugging, but still no luck with the vga initialization. It doesn't even seem to be SeaBios "fault" because Coreboot complains exactly the same story:
[...]
CBFS: Could not find file pci1002,515e.rom On card, rom address for PCI: 01:01.0 = fc000000 PCI Expansion ROM, signature 0x7373, INIT size 0xe600, data ptr 0x7373 Incorrect Expansion ROM Header Signature 7373
Is this an onboard VGA device? If so, the rom may be in flash instead of in the PCI rom space - in which case you should try following the directions at:
http://www.coreboot.org/SeaBIOS#Adding_a_VGA_option_ROM
But there are 4 and I thing that coreboot finds them. So here my question could these problems be related to my bad IRQ handling ?
I don't think IRQs would have any impact on the VGA rom not being found.
-Kevin
Kevin O'Connor escribió:
On Tue, Dec 29, 2009 at 03:10:50PM +0100, Knut Kujat wrote:
Myles Watson escribió:
From your log:
Attempting to map option rom on dev 01:01.0 Option rom sizing returned fc000001 fffe0000 Inspecting possible rom at 0xfc000000 (dv=515e1002 bdf=108) No option rom signature (got 7373)This looks like the right device, so I don't know why the signature isn't valid.
Using SeaBios 5.0 it "accepts" level 8 for debugging, but still no luck with the vga initialization. It doesn't even seem to be SeaBios "fault" because Coreboot complains exactly the same story:
[...]
CBFS: Could not find file pci1002,515e.rom On card, rom address for PCI: 01:01.0 = fc000000 PCI Expansion ROM, signature 0x7373, INIT size 0xe600, data ptr 0x7373 Incorrect Expansion ROM Header Signature 7373
Is this an onboard VGA device? If so, the rom may be in flash instead of in the PCI rom space - in which case you should try following the directions at:
http://www.coreboot.org/SeaBIOS#Adding_a_VGA_option_ROM
But there are 4 and I thing that coreboot finds them. So here my question could these problems be related to my bad IRQ handling ?
I don't think IRQs would have any impact on the VGA rom not being found.
-Kevin
Hello, first of all Happy new year!! :)
Yip, finally as you and Myles suggested adding the vga rom to the cbfs manually made SeaBios find it. The only thing is that I had to go back to SeaBios 4.2 because 5.0 wasn't still able to get it right. Btw, yes it this a onboard vga (ATI 1000ES).
Thanks, Knut Kujat.
On Mon, Jan 04, 2010 at 02:35:31PM +0100, Knut Kujat wrote:
Kevin O'Connor escribió:
Is this an onboard VGA device? If so, the rom may be in flash instead of in the PCI rom space - in which case you should try following the directions at:
Yip, finally as you and Myles suggested adding the vga rom to the cbfs manually made SeaBios find it. The only thing is that I had to go back to SeaBios 4.2 because 5.0 wasn't still able to get it right. Btw, yes it this a onboard vga (ATI 1000ES).
That's odd. Can you forward the log files (debug set to 8) from SeaBIOS v0.5.0 and SeaBIOS v0.4.2?
-Kevin
Kevin O'Connor escribió:
On Mon, Jan 04, 2010 at 02:35:31PM +0100, Knut Kujat wrote:
Kevin O'Connor escribió:
Is this an onboard VGA device? If so, the rom may be in flash instead of in the PCI rom space - in which case you should try following the directions at:
Yip, finally as you and Myles suggested adding the vga rom to the cbfs manually made SeaBios find it. The only thing is that I had to go back to SeaBios 4.2 because 5.0 wasn't still able to get it right. Btw, yes it this a onboard vga (ATI 1000ES).
That's odd. Can you forward the log files (debug set to 8) from SeaBIOS v0.5.0 and SeaBIOS v0.4.2?
-Kevin
Hi, on SeaBios 0.4.2 only debug level 6 is possible because if I set up level 8 it fails compiling with:
out/rombios.lds:18 cannot move location counter backwards (from 00000000000f7475 to 00000000000f7230) make: *** [out/rom.o] Error 1
and if i low it down to 7 it fails with:
out/rombios.lds:18 cannot move location counter backwards (from 00000000000f743d to 00000000000f7310) make: *** [out/rom.o] Error 1
setting it to 6 makes it compile.
On SeaBios 0.5.0 compiling with debug level 8 works fine.
Please find the two logs attached.
Thx, Knut Kujat.
Yip, finally as you and Myles suggested adding the vga rom to the cbfs manually made SeaBios find it. The only thing is that I had to go back to SeaBios 4.2 because 5.0 wasn't still able to get it right. Btw, yes it this a onboard vga (ATI 1000ES).
That's odd. Can you forward the log files (debug set to 8) from SeaBIOS v0.5.0
Scan for VGA option rom Checking rom 0x000c0000 (sig 0 size 0) init usb
and SeaBIOS v0.4.2?
Scan for VGA option rom Attempting to init PCI bdf 01:01.0 (dev/ven 515e1002) Searching CBFS for prefix pci1002,515e.rom Found CBFS file normal/payload Found CBFS file normal/coreboot_ram Found CBFS file fallback/payload Found CBFS file fallback/coreboot_ram Found CBFS file pci1002,515e.rom Copying data 45056@0xfff3c9f8 to 196608@0x000c0000 Checking rom 0x000c0000 (sig aa55 size 88) Running option rom at c000:0003
It looks like 5.0 doesn't have CONFIG_OPTIONROMS_DEPLOYED set to 0. It's looking in RAM instead of in CBFS.
Thanks, Myles
On Mon, Jan 04, 2010 at 03:48:20PM +0100, Knut Kujat wrote:
Kevin O'Connor escribió:
That's odd. Can you forward the log files (debug set to 8) from SeaBIOS v0.5.0 and SeaBIOS v0.4.2?
on SeaBios 0.4.2 only debug level 6 is possible because if I set up level 8 it fails compiling with:
As Myles points out, please confirm that CONFIG_OPTIONROMS_DEPLOYED is set to 0 in v0.5.0.
-Kevin
Kevin O'Connor escribió:
On Mon, Jan 04, 2010 at 03:48:20PM +0100, Knut Kujat wrote:
Kevin O'Connor escribió:
That's odd. Can you forward the log files (debug set to 8) from SeaBIOS v0.5.0 and SeaBIOS v0.4.2?
on SeaBios 0.4.2 only debug level 6 is possible because if I set up level 8 it fails compiling with:
As Myles points out, please confirm that CONFIG_OPTIONROMS_DEPLOYED is set to 0 in v0.5.0.
-Kevin
No, it wasn't I set it up to 0 and now it works fine. Sorry for so much confusion I should have taken a closer look before posting!
Thanks, Knut Kujat
I attached a log with seabios set up on debug level 6, is this the highest one? because 7 and 8 made compilation fail.
You could try the latest SeaBIOS.
Yours: Start bios (version 0.4.2-20091228_104949-pcq.gap.upv.es)
I'm not sure how old 0.4.2 is, but the one I just tried is 0.5.1 pre-0.5.1-20091228_125433-orangutan
Thanks, Myles
-
Kevin O'Connor -
Knut Kujat -
Myles Watson -
Ward Vandewege