coreboot

coreboot@coreboot.org

11 participants
39712 discussions

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

18 Oct '04

It should config.g bug, there is some un consistent. For dev33 and it sibling should be .bus = &_dev4.link[2], instead of .bus = &_dev4.link[0], struct device _dev4 = { .ops = 0, .bus = &_dev3.link[0], .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0x18,0)}}}, .enabled = 1, .link = { [0] = { .link = 0, .dev = &_dev4, .children = &_dev6, }, [1] = { .link = 1, .dev = &_dev4, }, [2] = { .link = 2, .dev = &_dev4, .children = &_dev33, }, }, .links = 3, .sibling = &_dev37, .chip_ops = &northbridge_amd_amdk8_ops, .chip_info = &northbridge_amd_amdk8_info_2, .next=&_dev6 }; struct device _dev33 = { .ops = 0, .bus = &_dev4.link[0], .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0x0,0)}}}, .enabled = 1, .link = { }, .links = 0, .sibling = &_dev34, .next=&_dev34 }; struct device _dev34 = { .ops = 0, .bus = &_dev4.link[0], .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0x0,1)}}}, .enabled = 1, .link = { }, .links = 0, .sibling = &_dev35, .next=&_dev35 }; struct device _dev35 = { .ops = 0, .bus = &_dev4.link[0], .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0x1,0)}}}, .enabled = 1, .link = { }, .links = 0, .sibling = &_dev36, .next=&_dev36 }; struct device _dev36 = { .ops = 0, .bus = &_dev4.link[0], .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0x1,1)}}}, .enabled = 1, .link = { }, .links = 0, .next=&_dev37 }; -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: Monday, October 18, 2004 1:36 PM To: Li-Ta Lo Cc: Eric W. Biederman; YhLu; 'LinuxBIOS' Subject: Re: FYI: Merge in progress... On Mon, 18 Oct 2004, Li-Ta Lo wrote: > This is exactly why I was proposing this change. We also got rid of > a lot of static -> dynamice code. > even cooler: there is no static code structure any more. What the config tool creates is a statically allocated set of device structs. The enumeration of static to dynamic is gone. And so on, and so on, it's a huge improvement. ron

4 5

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

18 Oct '04

I'm using Mallanox PCI-E HCA. YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Monday, October 18, 2004 4:31 PM To: YhLu Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' Subject: Re: FYI: Merge in progress... YhLu <YhLu(a)tyan.com> writes: > There is overlapping between prefmem and mem. Ok that is really weird. Do you have a prefmem resource whose limit is below 4G? A few small glitches don't surprise me as the 64bit support in the resources is new, and I am still refining it. And it should be suboptimal for multiple HT chains. (Because I am artificially limiting them in the PCI_DOMAIN). However. I don't know of a case that would assign prefmem and mem the same base address. In src/northbridge/amd/amdk8/northbridge.c:pci_domain_read_resources You might try setting the limit to 4G - 1 == 0xffffffff An lspci -vvv of the failing system would be interesting if you have BIOS under which it boots. > PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000005fff] io > PCI_DOMAIN: 0000 01 <- [0x00f8000000 - 0x01007fffff] prefmem > PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fe6fffff] mem > PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0> > PCI: 00:18.0 1b8 <- [0x0000000000 - 0x000fffffff] prefmem <node 0 link 0> > PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fe1fffff] mem <node 0 link 0> > PCI: 00:18.0 1da <- [0x0000004000 - 0x0000004fff] io <node 0 link 2> > PCI: 00:18.0 1aa <- [0x0100800000 - 0x01007fffff] prefmem <node 0 link 2> > PCI: 00:18.0 1a2 <- [0x00fe200000 - 0x00fe4fffff] mem <node 0 link 2> > > PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart> > PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart> > PCI: 00:19.0 1c8 <- [0x0000005000 - 0x0000005fff] io <node 1 link 0> > PCI: 00:19.0 198 <- [0x00f8000000 - 0x01007fffff] prefmem <node 1 link 0> > PCI: 00:19.0 190 <- [0x00fe500000 - 0x00fe6fffff] mem <node 1 link 0> For reference on my HDAMA with a mellanox HCA plugged in I am getting: PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io PCI_DOMAIN: 0000 01 <- [0xfcf0000000 - 0xfcf87fffff] prefmem PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fd3fffff] mem PCI: 00:18.0 1b8 <- [0xfcf0000000 - 0xfcf87fffff] prefmem <node 0 link 0> PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 0> Eric

1 0

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

18 Oct '04

The prefmem and mem overlapping is the last problem. If I using pci-e card, it will overlap the range of io apic, and it will hang MB. I just happen to have some multi HT link MB to dig some problem for you. I will commit change about s288x ....today. Regards Yinghai Lu -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: Monday, October 18, 2004 4:00 PM To: YhLu Cc: ebiederman(a)lnxi.com; Li-Ta Lo; 'LinuxBIOS' Subject: RE: FYI: Merge in progress... On Mon, 18 Oct 2004, YhLu wrote: > There is overlapping between prefmem and mem. Dr. Lu, we could not ask for a better tester than you! Thanks for your patience ... I realize we did break things a bit last week! Thanks ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

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

18 Oct '04

self.firstparentdevicelink() How about IORESOURCE_FIXED ? static void pnp_set_resource(device_t dev, struct resource *resource) { if (!(resource->flags & IORESOURCE_ASSIGNED)) { printk_err("ERROR: %s %02x not allocated\n", dev_path(dev), resource->index); return; } -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Monday, October 18, 2004 2:22 PM To: YhLu Cc: Ronald G. Minnich; Li-Ta Lo; 'LinuxBIOS' Subject: Re: FYI: Merge in progress... YhLu <YhLu(a)tyan.com> writes: > It should config.g bug, there is some un consistent. It could be. I should have fixed this Saturday, but... Looking Hmm... > For dev33 and it sibling > should be .bus = &_dev4.link[2], > instead of > .bus = &_dev4.link[0], Good catch. We do not yet have the link of the parent device set properly in the .bus field. It is always hard coded to 0 :( Ok the fix looks easy, committed. Hopefully I have not missed any other cases... Eric

2 1

Re: FYI: Merge in progress...
by ebiederman＠lnxi.com 18 Oct '04

18 Oct '04

YhLu <YhLu(a)tyan.com> writes: > Config.g still miss to add > > crt0.S: $(CRT0) > cp $< $@ > linuxbios.rom: linuxbios.strip buildrom > ./buildrom $< $@ $(PAYLOAD) $(ROM_IMAGE_SIZE) $(ROM_SECTION_SIZE) > > to the fallback/Makfile Yep. That is now fixed. I am working through the changes necessary changes to the static device tree now. We are getting there. Eric

5 12

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

18 Oct '04

My fault, last week I change my Config.lb and build scripts. Mess up the pci 0.0 to pci 1.0. YH -----Original Message----- From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] Sent: Monday, October 18, 2004 12:20 PM To: YhLu Cc: Li-Ta Lo; 'Ronald G. Minnich'; 'LinuxBIOS' Subject: Re: FYI: Merge in progress... YhLu <YhLu(a)tyan.com> writes: > Werid, it should look for 1:0.0 instead of 1:1.0 before unit id is updated > in hypertransport_scan_chain. There is a double scan. Once in hypertransport.c where the unitids are assigned. And pci_scan_bus is called to finish the enumeration. The logic should still play nice with Nvidia chipsets, but I may have touched something. There was a nonsensical disabling of link optimizations in misc_control.c for the single cpu case. Just limiting the optimization to AMD chipsets as the FIXME suggested would have been better. > -----Original Message----- > From: YhLu > Sent: Monday, October 18, 2004 10:36 AM > To: ebiederman(a)lnxi.com; Li-Ta Lo > Cc: 'Ronald G. Minnich'; 'LinuxBIOS' > Subject: RE: FYI: Merge in progress... > > I got some err. > > It seems scan_k8_chains is not called. I think I have just disabled that print statement. > LinuxBIOS-1.1.62.0_Fallback Mon Oct 18 09:29:09 PDT 2004 booting... > Finding PCI configuration type. > PCI: Using configuration type 1 > Enumerating buses... > scan_static_bus for Root Device > PCI_DOMAIN: 0000 enabled > APIC_CLUSTER: 0 enabled > PCI_DOMAIN: 0000 scanning... > PCI: pci_scan_bus for bus 0 > PCI: 00:18.0 [1022/1100] bus ops > PCI: 00:18.0 [1022/1100] enabled > PCI: 00:18.1 [1022/1101] enabled > PCI: 00:18.2 [1022/1102] enabled > PCI: 00:18.3 [1022/1103] ops > PCI: 00:18.3 [1022/1103] enabled > PCI: 00:19.0 [1022/1100] bus ops > PCI: 00:19.0 [1022/1100] enabled > PCI: 00:19.1 [1022/1101] enabled > PCI: 00:19.2 [1022/1102] enabled > PCI: 00:19.3 [1022/1103] ops > PCI: 00:19.3 [1022/1103] enabled > PCI: 01:01.0 Hypertransport link capability not foundHyperT reset not needed > PCI: pci_scan_bus for bus 1 > PCI: 01:00.0 [10de/005e] enabled > PCI: 01:01.0 [10de/0051] bus ops > PCI: 01:01.0 [10de/0051] enabled > PCI: 01:01.1 [10de/0052] enabled > scan_static_bus for PCI: 01:01.0 For comparison purposes the HDAMA boot looks like: LinuxBIOS-1.1.6.8pre3Normal Sat Oct 16 13:50:39 MDT 2004 starting... setting up resource map....done. 02 nodes initialized. coherent_ht_finalize done Ram1.00 Ram1.01 Ram2.00 Ram2.01 Ram3 Initializing memory: done Initializing memory: done Clearing initial memory region: done Ram4 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.6.8pre3Normal Sat Oct 16 13:50:39 MDT 2004 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating buses... scan_static_bus for Root Device PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] bus ops PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] bus ops PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset not needed PCI: pci_scan_bus for bus 1 PCI: 01:01.0 [1022/7450] bus ops PCI: 01:01.0 [1022/7450] enabled PCI: 01:01.1 [1022/7451] ops PCI: 01:01.1 [1022/7451] enabled PCI: 01:02.0 [1022/7450] bus ops PCI: 01:02.0 [1022/7450] enabled PCI: 01:02.1 [1022/7451] ops PCI: 01:02.1 [1022/7451] enabled PCI: 01:03.0 [1022/7460] bus ops PCI: 01:03.0 [1022/7460] enabled PCI: 01:04.0 [1022/7468] bus ops PCI: 01:04.0 [1022/7468] enabled PCI: 01:04.1 [1022/7469] ops PCI: 01:04.1 [1022/7469] enabled PCI: 01:04.2 [1022/746a] enabled PCI: 01:04.3 [1022/746b] ops PCI: 01:04.3 [1022/746b] enabled PCI: 01:04.5 No device operations PCI: 01:04.6 [1022/746e] ops PCI: 01:04.6 [1022/746e] enabled PCI: pci_scan_bus for bus 2 PCI: 02:03.0 [14e4/16a6] enabled PCI: 02:04.0 [14e4/16a6] enabled PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: 03:01.0 [15b3/5a46] enabled PCI: pci_scan_bus for bus 4 PCI: 04:00.0 [15b3/5a44] enabled PCI: pci_scan_bus returning with max=04 PCI: pci_scan_bus returning with max=04 PCI: pci_scan_bus for bus 5 PCI: 05:00.0 [1022/7464] enabled PCI: 05:00.1 [1022/7464] enabled PCI: 05:00.2 [1022/7463] enabled PCI: 05:01.0 No device operations PCI: 05:06.0 [1002/4752] enabled PCI: pci_scan_bus returning with max=05 scan_static_bus for PCI: 01:04.0 PNP: 002e.0 disabled PNP: 002e.1 disabled PNP: 002e.2 disabled PNP: 002e.3 enabled PNP: 002e.4 disabled PNP: 002e.5 disabled PNP: 002e.6 enabled PNP: 002e.7 disabled PNP: 002e.8 disabled PNP: 002e.9 disabled PNP: 002e.a disabled scan_static_bus done PCI: pci_scan_bus returning with max=05 PCI: pci_scan_bus returning with max=05 APIC_CLUSTER: 0 scanning... CPU: APIC: 00 enabled CPU: APIC: 01 enabled scan_static_bus done done Allocating resources... PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem PCI: 03:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 4 io PCI: 01:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 3 io PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 5 prefmem Allocating VGA resource PCI: 05:06.0 PCI_DOMAIN: 0000 00 <- [0x0000001000 - 0x0000002fff] io PCI_DOMAIN: 0000 01 <- [0xfcf0000000 - 0xfcf87fffff] prefmem PCI_DOMAIN: 0000 02 <- [0x00f8000000 - 0x00fd3fffff] mem PCI: 00:18.0 1b8 <- [0xfcf0000000 - 0xfcf87fffff] prefmem <node 0 link 0> PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0> PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fd3fffff] mem <node 0 link 0> PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 2 mem PCI: 02:03.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem PCI: 02:04.0 10 <- [0x00fd110000 - 0x00fd11ffff] mem PCI: 01:01.1 10 <- [0x00fd300000 - 0x00fd300fff] mem PCI: 01:02.0 24 <- [0xfcf0000000 - 0xfcf87fffff] bus 3 prefmem PCI: 01:02.0 20 <- [0x00fd200000 - 0x00fd2fffff] bus 3 mem PCI: 03:01.0 24 <- [0xfcf0000000 - 0xfcf87fffff] bus 4 prefmem PCI: 03:01.0 20 <- [0x00fd200000 - 0x00fd2fffff] bus 4 mem PCI: 04:00.0 10 <- [0x00fd200000 - 0x00fd2fffff] mem PCI: 04:00.0 18 <- [0xfcf8000000 - 0xfcf87fffff] prefmem PCI: 04:00.0 20 <- [0xfcf0000000 - 0xfcf7ffffff] prefmem PCI: 01:02.1 10 <- [0x00fd301000 - 0x00fd301fff] mem PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 5 io PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 5 mem PCI: 05:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem PCI: 05:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem PCI: 05:00.2 10 <- [0x00fd003000 - 0x00fd0030ff] mem PCI: 05:00.2 14 <- [0x00fd004000 - 0x00fd00401f] mem PCI: 05:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem PCI: 05:06.0 14 <- [0x0000001000 - 0x00000010ff] io PCI: 05:06.0 18 <- [0x00fd002000 - 0x00fd002fff] mem ERROR: PNP: 002e.3 60 not allocated ERROR: PNP: 002e.3 70 not allocated ERROR: PNP: 002e.6 60 not allocated ERROR: PNP: 002e.6 62 not allocated ERROR: PNP: 002e.6 70 not allocated PCI: 01:04.1 20 <- [0x00000028b0 - 0x00000028bf] io PCI: 01:04.2 10 <- [0x0000002880 - 0x000000289f] io PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io PCI: 01:04.6 10 <- [0x0000002400 - 0x00000024ff] io PCI: 01:04.6 14 <- [0x0000002800 - 0x000000287f] io PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart> PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart> done. Enabling resourcess... PCI: 00:18.0 cmd <- 140 PCI: 01:01.0 bridge ctrl <- 0003 PCI: 01:01.0 cmd <- 146 PCI: 02:03.0 cmd <- 142 PCI: 02:04.0 cmd <- 142 PCI: 01:01.1 cmd <- 146 PCI: 01:02.0 bridge ctrl <- 0003 PCI: 01:02.0 cmd <- 146 PCI: 03:01.0 bridge ctrl <- 0003 PCI: 03:01.0 cmd <- 146 PCI: 04:00.0 cmd <- 142 PCI: 01:02.1 cmd <- 146 PCI: 01:03.0 bridge ctrl <- 000b PCI: 01:03.0 cmd <- 147 PCI: 05:00.0 subsystem <- 00/00 PCI: 05:00.0 cmd <- 142 PCI: 05:00.1 subsystem <- 00/00 PCI: 05:00.1 cmd <- 142 PCI: 05:00.2 subsystem <- 00/00 PCI: 05:00.2 cmd <- 142 PCI: 05:06.0 cmd <- 1c3 PCI: 01:04.0 cmd <- 14f PCI: 01:04.1 cmd <- 141 PCI: 01:04.2 subsystem <- 00/00 PCI: 01:04.2 cmd <- 141 PCI: 01:04.3 cmd <- 141 I2C: 70 missing enable_resources I2C: 50 missing enable_resources I2C: 51 missing enable_resources I2C: 52 missing enable_resources I2C: 53 missing enable_resources I2C: 54 missing enable_resources I2C: 55 missing enable_resources I2C: 56 missing enable_resources I2C: 57 missing enable_resources PCI: 01:04.6 cmd <- 141 PCI: 00:18.1 subsystem <- 00/00 PCI: 00:18.1 cmd <- 140 PCI: 00:18.2 subsystem <- 00/00 PCI: 00:18.2 cmd <- 140 PCI: 00:18.3 cmd <- 140 PCI: 00:19.0 cmd <- 140 PCI: 00:19.1 subsystem <- 00/00 PCI: 00:19.1 cmd <- 140 PCI: 00:19.2 subsystem <- 00/00 PCI: 00:19.2 cmd <- 140 PCI: 00:19.3 cmd <- 140 done. Initializing devices... Root Device init PCI: 00:18.0 init done. PCI: 01:01.0 init PCI: 01:02.0 init PCI: 01:03.0 init PCI: 01:04.0 init RTC Init enabling HPET @0xfed00000 PNP: 002e.3 init PNP: 002e.6 init PCI: 01:04.1 init IDE1 IDE0 PCI: 01:04.3 init set power on after power fail PCI: 00:18.3 init NB: Function 3 Misc Control.. done. PCI: 00:19.0 init done. PCI: 00:19.3 init NB: Function 3 Misc Control.. done. APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor AMD device f58 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB Setting fixed MTRRs(24-88) Type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB Setting variable MTRR 2, base: 3072MB, range: 512MB, type WB Setting variable MTRR 3, base: 3584MB, range: 256MB, type WB Setting variable MTRR 4, base: 3840MB, range: 128MB, type WB Setting variable MTRR 5, base: 4096MB, range: 1024MB, type WB DONE variable MTRRs Clear out the extra MTRR's MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Clearing memory 0K - 4194304K: --------------------------------------------------------------- done Setting up local apic... apic_id: 0 done. CPU #0 Initialized Initializing CPU #1 Waiting for 1 CPUS to stop CPU: vendor AMD device f58 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB Setting fixed MTRRs(24-88) Type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB Setting variable MTRR 2, base: 3072MB, range: 512MB, type WB Setting variable MTRR 3, base: 3584MB, range: 256MB, type WB Setting variable MTRR 4, base: 3840MB, range: 128MB, type WB Setting variable MTRR 5, base: 4096MB, range: 1024MB, type WB DONE variable MTRRs Clear out the extra MTRR's MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled C - 5242880K: ++++++++++++++++ done Setting up local apic... apic_id: 1 done. CPU #1 Initialized All AP CPUs stopped Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... /home/eric/projects/linuxbios/linuxbios/hdama/freebios2/src/arch/i386/boot/p irq_routing.c: 28:check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 done. Wrote the mp table end at: 00000020 - 00000224 Wrote linuxbios table at: 00000500 - 00000d94 checksum 21a5 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 23:stream_init() - rom_stream: 0xfff80000 - 0xfffcffff Found ELF candiate at offset 0 Loading Etherboot version: 5.2.4eb6 Dropping non PT_LOAD segment New segment addr 0x20000 size 0x41e43 offset 0xc0 filesize 0x9928 (cleaned up) New segment addr 0x20000 size 0x41e43 offset 0xc0 filesize 0x9928 Loading Segment: addr: 0x00000000f7fc8000 memsz: 0x000000000000e000 filesz: 0x0000000000009928 Clearing Segment: addr: 0x00000000f7fd1928 memsz: 0x00000000000046d8 Loading Segment: addr: 0x000000000002e000 memsz: 0x0000000000033e43 filesz: 0x0000000000000000 Clearing Segment: addr: 0x000000000002e000 memsz: 0x0000000000033e43 Jumping to boot code at 0x20000 ROM segment 0x0000 length 0x0000 reloc 0x00020000 CPU 2072 Mhz Etherboot 5.2.4eb6 (GPL) http://etherboot.org ELF64 ELF with TFTP SLAM LACP for [EEPRO100][E1000][3C90X][TG3][IDE] Relocating _text from: [00029920,00063070) to [f7ec68b0,f7f00000) Boot from (N)etwork (D)isk or (Q)uit? ^Mrobing pci nic... [tg3-5702X]Ethernet addr: 00:50:45:00:E5:13 Tigon3 [partno(BCM95702A20) rev 1002 PHY(5703)] (PCI:66MHz:32-bit) Link is up at 100 Mbps, full duplex. TX RX flow control Searching for server (DHCP)... ...Me: 172.16.16.90, Server: 172.16.31.253, Relay: 172.16.23.254, Gateway 172.16.23.254 Loading 172.16.31.253:k8-boot.ebi ...(ELF)... ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ............................................................................ ......done

1 0

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

18 Oct '04

Werid, it should look for 1:0.0 instead of 1:1.0 before unit id is updated in hypertransport_scan_chain. YH -----Original Message----- From: YhLu Sent: Monday, October 18, 2004 10:36 AM To: ebiederman(a)lnxi.com; Li-Ta Lo Cc: 'Ronald G. Minnich'; 'LinuxBIOS' Subject: RE: FYI: Merge in progress... I got some err. It seems scan_k8_chains is not called. LinuxBIOS-1.1.62.0_Fallback Mon Oct 18 09:29:09 PDT 2004 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating buses... scan_static_bus for Root Device PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] bus ops PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] bus ops PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled PCI: 01:01.0 Hypertransport link capability not foundHyperT reset not needed PCI: pci_scan_bus for bus 1 PCI: 01:00.0 [10de/005e] enabled PCI: 01:01.0 [10de/0051] bus ops PCI: 01:01.0 [10de/0051] enabled PCI: 01:01.1 [10de/0052] enabled scan_static_bus for PCI: 01:01.0 _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

linux kernel patch
by Gin 18 Oct '04

18 Oct '04

Hello Ron, I don't' know if you are still working on this project since it's 2004 now. I just finished a presentation of Linuxbios at work. We are highly interested in getting linuxbios running on our systems(we design motherboards). I have a question about the way you do the kernel patch. If the patch is to initialize the uninitialized hardware in order to run linux. Then why didn't we add it into the C code. Let it become part of linuxbios rom image? Furthermore, why do you have different patches for different linux kernel versions? Sorry if the questions are too basic. We just started trying to get it built. Thanks, Gin

3 6

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

18 Oct '04

I got some err. It seems scan_k8_chains is not called. LinuxBIOS-1.1.62.0_Fallback Mon Oct 18 09:29:09 PDT 2004 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating buses... scan_static_bus for Root Device PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 scanning... PCI: pci_scan_bus for bus 0 PCI: 00:18.0 [1022/1100] bus ops PCI: 00:18.0 [1022/1100] enabled PCI: 00:18.1 [1022/1101] enabled PCI: 00:18.2 [1022/1102] enabled PCI: 00:18.3 [1022/1103] ops PCI: 00:18.3 [1022/1103] enabled PCI: 00:19.0 [1022/1100] bus ops PCI: 00:19.0 [1022/1100] enabled PCI: 00:19.1 [1022/1101] enabled PCI: 00:19.2 [1022/1102] enabled PCI: 00:19.3 [1022/1103] ops PCI: 00:19.3 [1022/1103] enabled PCI: 01:01.0 Hypertransport link capability not foundHyperT reset not needed PCI: pci_scan_bus for bus 1 PCI: 01:00.0 [10de/005e] enabled PCI: 01:01.0 [10de/0051] bus ops PCI: 01:01.0 [10de/0051] enabled PCI: 01:01.1 [10de/0052] enabled scan_static_bus for PCI: 01:01.0

1 0

RE: Kernel for linuxbios
by Sagiv Yefet 18 Oct '04

18 Oct '04

I did what you said. New error: RAMDISK: Couldn't find valid RAM disk image starting at 0. Freeing initrd memory: 2624k freed VFS: Cannot open root device "" or 03:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 03:00 Sagiv. -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Wednesday, October 13, 2004 4:28 PM To: Sagiv Yefet Cc: Dave Aubin; linuxbios(a)clustermatic.org Subject: Re: Kernel for linuxbios * Sagiv Yefet <sagivy(a)3vium.com> [041013 16:11]: > Actually, I am using 2.4.24. > Maybe I should upgrade to 2.6.*. > but in the meanwhile what could be the problem? > > The command is: > > ./objdir/sbin/mkelfImage -t bzImage-i386 --kernel=/home/sagivy/bzImage > --command-line="rw console=ttyS0,115200 root=/dev/ram0" > --initrd=/home/sagivy/initrd --output=/home/sagivy/bzImage.elf leave root=/dev/ram0 away in the parameters and say initrd=initrd instead. IIRC there was some check in Linux that it only looks for an initrd if there is a parameter saying that there is one. Stefan

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot