| Submitter | Myles Watson |
|---|---|
| Date | 2009-12-17 17:02:03 |
| Message ID | <2831fecf0912170902i24bd41f6r7bfda620774e8e25@mail.gmail.com> |
| Download | mbox | patch |
| Permalink | /patch/662/ |
| State | Not Applicable |
| Headers | show |
Comments
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 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. 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, >> 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. 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=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 > > > > > 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 #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 > 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
> > 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
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
> > 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
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: > 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.
> > 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. > 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: >>> 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, (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: > >>> 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, (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: > > > > http://www.coreboot.org/SeaBIOS#Adding_a_VGA_option_ROM > > 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
> >> > >> 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
Patch
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. */