coreboot October 2004

coreboot@coreboot.org

45 participants
197 discussions

RE: FYI: Merge in progress...
by YhLu 20 Oct '04

20 Oct '04

Why enable cache in amd_early_mtrr_init? That causes CPU sleep 5s again. After get rid of that, the new auto.c stage still cost more 1s than the code two weeks ago. Regards YH -----Original Message----- From: YhLu Sent: Tuesday, October 19, 2004 6:30 PM To: ebiederman(a)lnxi.com Cc: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: RE: FYI: Merge in progress... Suggest you to add two options 1. premem 64 bit support? PCI_MEM_PREF_64BIT_SUPPORT 2. pci mmio optimizing? PCI_MEM_BASE_OPTIMIZATION Regards YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Tuesday, October 19, 2004 4:37 PM To: YhLu Cc: Li-Ta Lo; 'ebiederman(a)lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: Re: FYI: Merge in progress... YhLu <YhLu(a)tyan.com> writes: > Find out the problem, should be typo error. > > /* Now place the memory as high up as it will go */ > mem2->base = resource_max(mem2); > mem1->limit = mem2->base - 1; > mem1->base = resource_max(mem2); > ------> > /* Now place the memory as high up as it will go */ > mem2->base = resource_max(mem2); > mem1->limit = mem2->base - 1; > mem1->base = resource_max(mem1); > > regards Thanks. That was a definite blind spot, on my side. I have now committed the fix. Eric _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

RE: Makefile changes for symbols
by Stephen.Kimball＠bench.com 20 Oct '04

20 Oct '04

The file under your target in normal/linuxbios_c.o seems to have all the symbols if you add "-gdwarf-2" to the $CFLAGS in the Makefile. Then when you open the first C module the SourcePoint software asks where the file exists, after you tell SourcePoint it seems to find the rest by itself. I recreated the same Linux directory structure on Windows. Thanks Rod! Steve -----Original Message----- From: Kittleson, Rodney C. Sent: Wednesday, October 20, 2004 11:47 AM To: Kimball, Stephen; linuxbios(a)clustermatic.org Subject: RE: Makefile changes for symbols Linuxbios_c, from the build directory, can be sucked into Sourcepoint to extract the symbols. This allows the disassembled instructions to display the symbols inline. It makes it easier to set breakpoints and follow the code, but it's a far cry from source level debugging. I haven't attempted to link the source with sourcepoint yet. I may try it later this week, let me know if you have any success. Rod -----Original Message----- From: Kimball, Stephen Sent: Tuesday, October 19, 2004 3:33 PM To: linuxbios(a)clustermatic.org Subject: Makefile changes for symbols Can someone give me the Makefile changes to make a LinuxBIOS with symbols? I tried adding "-gdwarf-2" to CFLAGS, but I'm not sure where the unstripped output would be. Are there any features in the code that are useful in debugging LinuxBIOS? Any defines that should change as well? Someone must have some experience with source code level debugging of LinuxBIOS with an American Arium ECM-50. Thanks. Steve Kimball Benchmark Electronics Hudson, NH _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

RE: FYI: Merge in progress...
by YhLu 20 Oct '04

20 Oct '04

Just check in Tyan update to support new config. CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: src/include/device/device.h src/mainboard/amd/quartet/auto.c CVS: src/mainboard/tyan/s2850/Config.lb CVS: src/mainboard/tyan/s2850/auto.c CVS: src/mainboard/tyan/s2850/chip.h CVS: src/mainboard/tyan/s2850/cmos.layout CVS: src/mainboard/tyan/s2850/failover.c CVS: src/mainboard/tyan/s2850/mainboard.c CVS: src/mainboard/tyan/s2850/mptable.c CVS: src/mainboard/tyan/s2875/Config.lb CVS: src/mainboard/tyan/s2875/auto.c CVS: src/mainboard/tyan/s2875/chip.h CVS: src/mainboard/tyan/s2875/cmos.layout CVS: src/mainboard/tyan/s2875/failover.c CVS: src/mainboard/tyan/s2875/mainboard.c CVS: src/mainboard/tyan/s2875/mptable.c CVS: src/mainboard/tyan/s2880/Config.lb CVS: src/mainboard/tyan/s2880/auto.c CVS: src/mainboard/tyan/s2880/chip.h CVS: src/mainboard/tyan/s2880/cmos.layout CVS: src/mainboard/tyan/s2880/failover.c CVS: src/mainboard/tyan/s2880/mainboard.c CVS: src/mainboard/tyan/s2880/mptable.c CVS: src/mainboard/tyan/s2881/Config.lb CVS: src/mainboard/tyan/s2881/auto.c CVS: src/mainboard/tyan/s2881/chip.h CVS: src/mainboard/tyan/s2881/cmos.layout CVS: src/mainboard/tyan/s2881/failover.c CVS: src/mainboard/tyan/s2881/mainboard.c CVS: src/mainboard/tyan/s2881/mptable.c CVS: src/mainboard/tyan/s2882/Config.lb CVS: src/mainboard/tyan/s2882/auto.c CVS: src/mainboard/tyan/s2882/chip.h CVS: src/mainboard/tyan/s2882/cmos.layout CVS: src/mainboard/tyan/s2882/failover.c CVS: src/mainboard/tyan/s2882/irq_tables.c CVS: src/mainboard/tyan/s2882/mainboard.c CVS: src/mainboard/tyan/s2882/mptable.c CVS: src/mainboard/tyan/s2885/Config.lb CVS: src/mainboard/tyan/s2885/auto.c CVS: src/mainboard/tyan/s2885/chip.h CVS: src/mainboard/tyan/s2885/cmos.layout CVS: src/mainboard/tyan/s2885/failover.c CVS: src/mainboard/tyan/s2885/mainboard.c CVS: src/mainboard/tyan/s2885/mptable.c CVS: src/mainboard/tyan/s2885/resourcemap.c CVS: src/mainboard/tyan/s2885/ti_firewire.c CVS: src/mainboard/tyan/s4880/Config.lb CVS: src/mainboard/tyan/s4880/auto.c CVS: src/mainboard/tyan/s4880/chip.h CVS: src/mainboard/tyan/s4880/cmos.layout CVS: src/mainboard/tyan/s4880/failover.c CVS: src/mainboard/tyan/s4880/mainboard.c CVS: src/mainboard/tyan/s4880/mptable.c CVS: src/mainboard/tyan/s4882/Config.lb CVS: src/mainboard/tyan/s4882/auto.c CVS: src/mainboard/tyan/s4882/chip.h CVS: src/mainboard/tyan/s4882/cmos.layout CVS: src/mainboard/tyan/s4882/failover.c CVS: src/mainboard/tyan/s4882/mainboard.c CVS: src/mainboard/tyan/s4882/mptable.c CVS: src/northbridge/amd/amdk8/incoherent_ht.c CVS: src/superio/winbond/w83627hf/chip.h CVS: src/superio/winbond/w83627hf/superio.c CVS: targets/tyan/s2850/Config.lb targets/tyan/s2875/Config.lb CVS: targets/tyan/s2880/Config.lb targets/tyan/s2880/ns2880 CVS: targets/tyan/s2881/Config.lb targets/tyan/s2882/Config.lb CVS: targets/tyan/s2885/Config.lb targets/tyan/s4880/Config.lb CVS: targets/tyan/s4882/Config.lb util/flash_and_burn/flash_rom.c CVS: util/flash_and_burn/pm49fl004.c -----------------------------------------

3 2

building Image with RTL8169 NIC
by Sagiv Yefet 20 Oct '04

20 Oct '04

Hello, I am trying to build IMAGE for Tyan 2850 with RTL8169 NIC. Which driver supports this NIC? Sagiv

2 1

RE: Makefile changes for symbols
by Rodney.Kittleson＠bench.com 20 Oct '04

20 Oct '04

Linuxbios_c, from the build directory, can be sucked into Sourcepoint to extract the symbols. This allows the disassembled instructions to display the symbols inline. It makes it easier to set breakpoints and follow the code, but it's a far cry from source level debugging. I haven't attempted to link the source with sourcepoint yet. I may try it later this week, let me know if you have any success. Rod -----Original Message----- From: Kimball, Stephen Sent: Tuesday, October 19, 2004 3:33 PM To: linuxbios(a)clustermatic.org Subject: Makefile changes for symbols Can someone give me the Makefile changes to make a LinuxBIOS with symbols? I tried adding "-gdwarf-2" to CFLAGS, but I'm not sure where the unstripped output would be. Are there any features in the code that are useful in debugging LinuxBIOS? Any defines that should change as well? Someone must have some experience with source code level debugging of LinuxBIOS with an American Arium ECM-50. Thanks. Steve Kimball Benchmark Electronics Hudson, NH _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

RE: Makefile changes for symbols
by Dave Aubin 20 Oct '04

20 Oct '04

Hi Steve, Nice to hear someone else in the northeast is using lb:) Methods we use to do linux bios debugging: 1. Serial 2. netconsole (same as serial but over ethernet) 3. Hardware Emulator with debugger 4. Toggling leds at certain places (i.e. like printfs for leds;) -----Original Message----- From: linuxbios-admin(a)clustermatic.org [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Stephen.Kimball(a)bench.com Sent: Wednesday, October 20, 2004 8:29 AM To: rminnich(a)lanl.gov Cc: linuxbios(a)clustermatic.org Subject: RE: Makefile changes for symbols Ron, Is LinuxBIOS development done with only serial port debug messages? You guys are good. Steve -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: Tuesday, October 19, 2004 5:25 PM To: Kimball, Stephen Cc: linuxbios(a)clustermatic.org Subject: Re: Makefile changes for symbols On Tue, 19 Oct 2004 Stephen.Kimball(a)bench.com wrote: > > Someone must have some experience with source code level debugging of > LinuxBIOS with an American Arium ECM-50. Thanks. wow! I want to hear about that when you get it going. Another FAQ entry. ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

RE: FYI: Merge in progress...
by YhLu 19 Oct '04

19 Oct '04

Suggest you to add two options 1. premem 64 bit support? PCI_MEM_PREF_64BIT_SUPPORT 2. pci mmio optimizing? PCI_MEM_BASE_OPTIMIZATION Regards YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Tuesday, October 19, 2004 4:37 PM To: YhLu Cc: Li-Ta Lo; 'ebiederman(a)lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: Re: FYI: Merge in progress... YhLu <YhLu(a)tyan.com> writes: > Find out the problem, should be typo error. > > /* Now place the memory as high up as it will go */ > mem2->base = resource_max(mem2); > mem1->limit = mem2->base - 1; > mem1->base = resource_max(mem2); > ------> > /* Now place the memory as high up as it will go */ > mem2->base = resource_max(mem2); > mem1->limit = mem2->base - 1; > mem1->base = resource_max(mem1); > > regards Thanks. That was a definite blind spot, on my side. I have now committed the fix. Eric

1 0

RE: FYI: Merge in progress...
by YhLu 19 Oct '04

19 Oct '04

Find out the problem, should be typo error. /* Now place the memory as high up as it will go */ mem2->base = resource_max(mem2); mem1->limit = mem2->base - 1; mem1->base = resource_max(mem2); ------> /* Now place the memory as high up as it will go */ mem2->base = resource_max(mem2); mem1->limit = mem2->base - 1; mem1->base = resource_max(mem1); regards YH -----Original Message----- From: YhLu Sent: Tuesday, October 19, 2004 2:04 PM To: Li-Ta Lo Cc: 'ebiederman(a)lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: RE: FYI: Merge in progress... Eric, after comment out something in static void pci_domain_set_resources(device_t dev) #if 0 /* Now reallocate the pci resources memory with the * highest addresses I can manage. */ It works now. you may need to look at these lines. Regards YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Tuesday, October 19, 2004 1:04 PM To: YhLu Cc: 'ebiederman(a)lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: RE: FYI: Merge in progress... On Tue, 2004-10-19 at 14:02, YhLu wrote: YhLu, Which mainboard are you working on ? Is it some board that's already in the public tree ? If it is already in the public tree, could be commit you change so people on the list can try it. Don't worry about broken code, every mainboard is broken in the current CVS. Ollie > Align is not assigned and it will be used to calculate the base too. (using > resource_max) > > > > root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000 > Allocating VGA resource PCI: 03:00.0 > base1: a 0xd0000000 limit1: 0xfebfffff size: 0x1880000000000000 align: > 0x1c00000000 > base2: a 0xec000000 limit2: 0xfebfffff size: 0x06700000 align: > 0x2bfc40000001a > base1: b 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 align: > 0x1c00000000 > base2: b 0xf8000000 limit2: 0xfebfffff size: 0x06700000 align: > 0x2bfc40000001a > > -----Original Message----- > From: YhLu > Sent: Tuesday, October 19, 2004 12:31 PM > To: YhLu; ebiederman(a)lnxi.com > Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' > Subject: RE: FYI: Merge in progress... > > strange size for prefmem of PCI_DOMAIN > > root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000 > Allocating VGA resource PCI: 03:00.0 > base1: 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 > base2: 0xf8000000 limit2: 0xfebfffff size: 0x06700000 > PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io > PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem > PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem > > -----Original Message----- > From: YhLu > Sent: Tuesday, October 19, 2004 12:18 PM > To: ebiederman(a)lnxi.com > Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' > Subject: RE: FYI: Merge in progress... > > Eric, > > The PCI_DOMAIN has two mem resource, root calculate the mem base correctly. > But PCI_DOMAIN get the wrong base. > > root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000 > Allocating VGA resource PCI: 03:00.0 > PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io > PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem > PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem > > > > -----Original Message----- > From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] > Sent: Monday, October 18, 2004 7:54 PM > To: YhLu > Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' > Subject: Re: FYI: Merge in progress... > > YhLu <YhLu(a)tyan.com> writes: > > > Get more worse. > > Ouch. If you can boot the board in linux please give me an lspci -vvv > > I don't have enough information to even guess what is going on. > I need to know what the size and limit of the resources are, > so I can walk through the code and see what it would do. > > At the moment I can't even begin to guess what is going wrong. > > The obvious problem of doubly allocating a base register does > not appear to apply. I am using the standard compute_allocate_resource > function which should traverse the bus and do the right thing. > > Unless my rewrite of the limit calculation code is causing a problem. > > I just don't know where to look. > > Eric > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

RE: FYI: Merge in progress...
by YhLu 19 Oct '04

19 Oct '04

Eric, The mail server bounce back my email.... Regards Yinghai Lu -----Original Message----- From: YhLu Sent: Tuesday, October 19, 2004 2:00 PM To: 'Li-Ta Lo' Cc: 'ebiederman(a)lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: RE: FYI: Merge in progress... Eric, after comment out something in static void pci_domain_set_resources(device_t dev) #if 0 /* Now reallocate the pci resources memory with the * highest addresses I can manage. */ It works now. you may need to look at these lines. Regards YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Tuesday, October 19, 2004 1:04 PM To: YhLu Cc: 'ebiederman(a)lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: RE: FYI: Merge in progress... On Tue, 2004-10-19 at 14:02, YhLu wrote: YhLu, Which mainboard are you working on ? Is it some board that's already in the public tree ? If it is already in the public tree, could be commit you change so people on the list can try it. Don't worry about broken code, every mainboard is broken in the current CVS. Ollie > Align is not assigned and it will be used to calculate the base too. (using > resource_max) > > > > root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000 > Allocating VGA resource PCI: 03:00.0 > base1: a 0xd0000000 limit1: 0xfebfffff size: 0x1880000000000000 align: > 0x1c00000000 > base2: a 0xec000000 limit2: 0xfebfffff size: 0x06700000 align: > 0x2bfc40000001a > base1: b 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 align: > 0x1c00000000 > base2: b 0xf8000000 limit2: 0xfebfffff size: 0x06700000 align: > 0x2bfc40000001a > > -----Original Message----- > From: YhLu > Sent: Tuesday, October 19, 2004 12:31 PM > To: YhLu; ebiederman(a)lnxi.com > Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' > Subject: RE: FYI: Merge in progress... > > strange size for prefmem of PCI_DOMAIN > > root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000 > Allocating VGA resource PCI: 03:00.0 > base1: 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 > base2: 0xf8000000 limit2: 0xfebfffff size: 0x06700000 > PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io > PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem > PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem > > -----Original Message----- > From: YhLu > Sent: Tuesday, October 19, 2004 12:18 PM > To: ebiederman(a)lnxi.com > Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' > Subject: RE: FYI: Merge in progress... > > Eric, > > The PCI_DOMAIN has two mem resource, root calculate the mem base correctly. > But PCI_DOMAIN get the wrong base. > > root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000 > Allocating VGA resource PCI: 03:00.0 > PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io > PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem > PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem > > > > -----Original Message----- > From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] > Sent: Monday, October 18, 2004 7:54 PM > To: YhLu > Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' > Subject: Re: FYI: Merge in progress... > > YhLu <YhLu(a)tyan.com> writes: > > > Get more worse. > > Ouch. If you can boot the board in linux please give me an lspci -vvv > > I don't have enough information to even guess what is going on. > I need to know what the size and limit of the resources are, > so I can walk through the code and see what it would do. > > At the moment I can't even begin to guess what is going wrong. > > The obvious problem of doubly allocating a base register does > not appear to apply. I am using the standard compute_allocate_resource > function which should traverse the bus and do the right thing. > > Unless my rewrite of the limit calculation code is causing a problem. > > I just don't know where to look. > > Eric > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios >

1 0

RE: FYI: Merge in progress...
by YhLu 19 Oct '04

19 Oct '04

Eric, after comment out something in static void pci_domain_set_resources(device_t dev) #if 0 /* Now reallocate the pci resources memory with the * highest addresses I can manage. */ It works now. you may need to look at these lines. Regards YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Tuesday, October 19, 2004 1:04 PM To: YhLu Cc: 'ebiederman(a)lnxi.com'; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: RE: FYI: Merge in progress... On Tue, 2004-10-19 at 14:02, YhLu wrote: YhLu, Which mainboard are you working on ? Is it some board that's already in the public tree ? If it is already in the public tree, could be commit you change so people on the list can try it. Don't worry about broken code, every mainboard is broken in the current CVS. Ollie > Align is not assigned and it will be used to calculate the base too. (using > resource_max) > > > > root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000 > Allocating VGA resource PCI: 03:00.0 > base1: a 0xd0000000 limit1: 0xfebfffff size: 0x1880000000000000 align: > 0x1c00000000 > base2: a 0xec000000 limit2: 0xfebfffff size: 0x06700000 align: > 0x2bfc40000001a > base1: b 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 align: > 0x1c00000000 > base2: b 0xf8000000 limit2: 0xfebfffff size: 0x06700000 align: > 0x2bfc40000001a > > -----Original Message----- > From: YhLu > Sent: Tuesday, October 19, 2004 12:31 PM > To: YhLu; ebiederman(a)lnxi.com > Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' > Subject: RE: FYI: Merge in progress... > > strange size for prefmem of PCI_DOMAIN > > root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000 > Allocating VGA resource PCI: 03:00.0 > base1: 0xf8000000 limit1: 0xf7ffffff size: 0x1880000000000000 > base2: 0xf8000000 limit2: 0xfebfffff size: 0x06700000 > PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io > PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem > PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem > > -----Original Message----- > From: YhLu > Sent: Tuesday, October 19, 2004 12:18 PM > To: ebiederman(a)lnxi.com > Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' > Subject: RE: FYI: Merge in progress... > > Eric, > > The PCI_DOMAIN has two mem resource, root calculate the mem base correctly. > But PCI_DOMAIN get the wrong base. > > root mem limit=0x00febfffff, size=0x0022700000, align=28, base=0x00d0000000 > Allocating VGA resource PCI: 03:00.0 > PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io > PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem > PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem > > > > -----Original Message----- > From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] > Sent: Monday, October 18, 2004 7:54 PM > To: YhLu > Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' > Subject: Re: FYI: Merge in progress... > > YhLu <YhLu(a)tyan.com> writes: > > > Get more worse. > > Ouch. If you can boot the board in linux please give me an lspci -vvv > > I don't have enough information to even guess what is going on. > I need to know what the size and limit of the resources are, > so I can walk through the code and see what it would do. > > At the moment I can't even begin to guess what is going wrong. > > The obvious problem of doubly allocating a base register does > not appear to apply. I am using the standard compute_allocate_resource > function which should traverse the bus and do the right thing. > > Unless my rewrite of the limit calculation code is causing a problem. > > I just don't know where to look. > > Eric > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios >

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2004