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.