Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
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 0x000c (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 45...@0xfff3c9f8 to 196...@0x000c Checking rom 0x000c (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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
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 fc01 fffe Inspecting possible rom at 0xfc00 (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 = fc00 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió:
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?
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, (devn3)|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 = fc00
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
flags 80202 index 20
PCI: 01:01.0 links 0 child on link 0 NULL
PCI: 01:01.0 resource base 0 size 800 align 27 gran 27 limit
flags 1200 index 10
PCI: 01:01.0 resource base 0 size 100 align 8 gran 8 limit
flags 100 index 14
PCI: 01:01.0 resource base 0 size 1 align 16 gran 16 limit
flags 200 index 18
PCI: 01:01.0 resource base 0 size 2 align 17 gran 17 limit
flags 2200 index 30
Is this just a different kind of enumeration or an error?
thx again, again and again,
Knut Kujat.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
-Original Message-
From: Knut Kujat [mailto:kn...@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:
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?
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, (devn3)|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
flags 80202 index 20
PCI: 01:01.0 links 0 child on link 0 NULL
PCI: 01:01.0 resource base 0 size 800 align 27 gran 27 limit
flags 1200 index 10
PCI: 01:01.0 resource base 0 size 100 align 8 gran 8 limit
flags 100 index 14
PCI: 01:01.0 resource base 0 size 1 align 16 gran 16 limit
flags 200 index 18
PCI: 01:01.0 resource base 0 size 2 align 17 gran 17 limit
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
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió:
On Mon, Dec 28, 2009 at 3:26 AM, Knut Kujat kn...@gap.upv.es
mailto:kn...@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 fc01 fffe
Inspecting possible rom at 0xfc00 (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: fff0 + 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 = fc00
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.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
On Mon, Dec 28, 2009 at 3:26 AM, Knut Kujat kn...@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 fc01 fffe
Inspecting possible rom at 0xfc00 (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
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió: On Mon, Dec 21, 2009 at 9:15 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@gap.upv.es wrote: Myles Watson escribió: On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@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 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. h what else could I do?? THX, Knut Kujat. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
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. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat kn...@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 1 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió: On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@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 1 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 yingha...@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
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
On Tue, Dec 22, 2009 at 11:38 AM, Knut Kujat kn...@gap.upv.es wrote: Myles Watson escribió: On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat kn...@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 1 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 #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
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió:
On Fri, Dec 18, 2009 at 8:41 AM, Knut Kujat kn...@gap.upv.es
mailto:kn...@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: ebx: 00226358 ecx: 0021ea74 edx: 0001
edi: 0021ea74 esi: 0001 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 =
microcode: equivalent rev id = 0x1022, current patch id = 0x
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.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat kn...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió: On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@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: 0001 edi: 0021ea74 esi: 0001 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
On Mon, Dec 21, 2009 at 9:15 AM, Knut Kujat kn...@gap.upv.es wrote: Myles Watson escribió: On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat kn...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
On Thu, Dec 17, 2009 at 7:03 AM, Knut Kujat kn...@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 =dfff 0: mmio_basek=0038, basek=0040, limitk= 1: mmio_basek=0038, basek=0048, limitk= PCI_DOMAIN: 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 Index: svn/src/devices/device.c === --- svn.orig/src/devices/device.c +++ svn/src/devices/device.c @@ -585,11 +585,15 @@ static void constrain_resources(struct d * check is signed so that negative amounts of space * are handled correctly. */ + printk_debug(%s:@%s %02lx base %08Lx limit %08Lx\n, __func__, + dev_path(dev), res-index, res-base, res-limit); if ((signed long long)(lim-limit - (res-base + res-size -1)) (signed long long)(res-base - lim-base)) lim-base = res-base + res-size; else lim-limit = res-base -1; + printk_debug(%s:lim base %08Lx limit %08Lx\n, __func__, + lim-base, lim-limit); } /* Descend into every enabled child and look for fixed resources. */ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
On Thu, Dec 17, 2009 at 10:27 AM, Knut Kujat kn...@gap.upv.es wrote: Myles Watson escribió: On Thu, Dec 17, 2009 at 7:03 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@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 =dfff 0: mmio_basek=0038, basek=0040, limitk= 1: mmio_basek=0038, basek=0048, limitk= PCI_DOMAIN: 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: avoid_fixed_resources:@PCI_DOMAIN: 1000 limit 07ff avoid_fixed_resources:@PCI_DOMAIN: 1100 limit 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 . 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: links 1 child on link 0 PCI: 00:18.0 PCI_DOMAIN: resource base 0 size 0 align 0 gran 0 limit flags 40040100 index 1000 PCI_DOMAIN: resource base 0 size 0 align 0 gran 0 limit flags 40040200 index 1100 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 @ 0x20 (1048576 bytes), entry @ 0x20 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
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 . 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 c100 index 60 PNP: 002e.b resource base 5 size 1 align 0 gran 0 limit 0 flags c400 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
