[coreboot] Problems porting H8dmr_fam10 to H8qme-2+

Knut Kujat knuku at gap.upv.es
Tue Dec 29 15:10:50 CET 2009


Myles Watson escribió:
>
>
> On Mon, Dec 28, 2009 at 3:26 AM, Knut Kujat <knuku at gap.upv.es
> <mailto:knuku at 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'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.






More information about the coreboot mailing list