coreboot

coreboot@coreboot.org

25 participants
39551 discussions

RE: config tool + tree enumeration
by Alan Mimms 29 Sep '03

29 Sep '03

Hello Lu, Is there anything in CVS yet for K8 CPU support? I didn't see anything a week or so ago. The AMD folks say it's there and "production level". ? Thanks. Alan Mimms, Senior Architect F5 Networks, Inc. Spokane Development Center Liberty Lake, Washington v: 509-343-3524 f: 509-343-3501 -----Original Message----- From: YhLu [mailto:YhLu@tyan.com] Sent: Monday, September 29, 2003 10:06 AM To: ron minnich Cc: Stefan Reinauer; Eric W. Biederman; linuxbios(a)clustermatic.org Subject: Re: config tool + tree enumeration Ron, In s2880, If I don't change the 0 to 1. I will get two copy of bus1 devices in the Linux. In S2885, it is OK, if I don't change it. In Arima, You still can not see bus1 device now? Regards Yinghai Lu -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年9月29日 10:00 收件人: YhLu 抄送: Stefan Reinauer; Eric W. Biederman; linuxbios(a)clustermatic.org 主题: Re: config tool + tree enumeration On Mon, 29 Sep 2003, YhLu wrote: > Stefan, > > >It's bus 1, that LinuxBIOS and OpenBIOS > >find really well, only Linux refuses to see it. > > Do you update the irq_table.c's interrupt router bus no. from to "0" to "1"? that's not the problem. The problem is that linux does not see bus 1 at all. ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

Re: config tool + tree enumeration
by YhLu 29 Sep '03

29 Sep '03

Ron, In s2880, If I don't change the 0 to 1. I will get two copy of bus1 devices in the Linux. In S2885, it is OK, if I don't change it. In Arima, You still can not see bus1 device now? Regards Yinghai Lu -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年9月29日 10:00 收件人: YhLu 抄送: Stefan Reinauer; Eric W. Biederman; linuxbios(a)clustermatic.org 主题: Re: config tool + tree enumeration On Mon, 29 Sep 2003, YhLu wrote: > Stefan, > > >It's bus 1, that LinuxBIOS and OpenBIOS > >find really well, only Linux refuses to see it. > > Do you update the irq_table.c's interrupt router bus no. from to "0" to "1"? that's not the problem. The problem is that linux does not see bus 1 at all. ron

2 1

V2 and epia
by ron minnich 29 Sep '03

29 Sep '03

I really think that if you are working on EPIA-*, you should make the cut to V2. I need the help. The port is going to be a much better job, and we won't have to keep fighting hacks in assembly code. Things that need looking at right now: - vt8231 early spd code - pci bus set up - northbridge and southbridge enumeration I feel very strongly that if we get EPIA done, EPIA-M will be pretty easy. So please consider making the move. ron

1 0

Re: config tool + tree enumeration
by YhLu 29 Sep '03

29 Sep '03

Stefan, >It's bus 1, that LinuxBIOS and OpenBIOS >find really well, only Linux refuses to see it. Do you update the irq_table.c's interrupt router bus no. from to "0" to "1"? Regards YH. -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年9月29日 2:18 收件人: Eric W. Biederman 抄送: ron minnich; YhLu; linuxbios(a)clustermatic.org 主题: Re: config tool + tree enumeration * Eric W. Biederman <ebiederman(a)lnxi.com> [030929 00:38]: > And until I have a reason I don't see the point, in making > a change. Hm. You are right. With some more tests I found out that this solution only fixes the problem occasionally. It seems that the chance that it works is higher with the number of tries. Really weird. > Mostly I suspect this is a matter of keeping the irq tables > in sync, or something similar where hard codes don't match the dynamic > assignments. And if that is the case we need to dig and do a good fix > instead of papering over the problem. If LinuxBIOS hangs during CPU/Northbridge enumeration, can this really be a matter of irq tables? I thought that they are touched quite a while later in the setup process. I suspect it might be connected to the highest bus number set in the default resource map, but I did not try more in this direction yet. Additionally I have Linux moaning that the irq table contains entries for a bus that does not exist. It's bus 1, that LinuxBIOS and OpenBIOS find really well, only Linux refuses to see it. Stefan -- Architecture Team SuSE Linux AG

2 1

more on V2 and epia
by ron minnich 29 Sep '03

29 Sep '03

Filling in the blanks ... First all functions of a device save function 0 get this error: PCI: 00:11.1 missing read_resources seems like a bug. So there looks like a problem for functions other than 0. Bridges don't have a path that is named: @ï¿½: bus 0000bc6c, bridge 00000100, type_mask 0x100, type 0x13a44 .:.: bus 00013ad4, bridge 00000100, type_mask 0x100, type 0x139a8 <.: bus 00013ccc, bridge 00000100, type_mask 0x100, type 0x13924 compute_allocate_resources has a bug in that it references a variable 'dev' before it is set. Oddly enough, gcc did not flag this error. I am trying to figure out where this really should be. It's the printk at the top: printk_spew("%s compute_allocate_%s: base: %08lx size: \ %08lx align: %d gran: %d\n", dev_path(dev), (bridge->flags & IORESOURCE_IO)? "io": (bridge->flags & IORESOURCE_PREFETCH)? "prefmem" : "mem", base, bridge->size, bridge->align, bridge->gran); dev is not set at this point. ron

1 0

OK, in spite of all the problems
by ron minnich 29 Sep '03

29 Sep '03

via epia on linuxbios2 just loaded etherboot! ron

1 0

v2 epia mainboard.c
by ron minnich 29 Sep '03

29 Sep '03

thought I should include this ... static struct device_operations mainboard_operations = { .read_resources = root_dev_read_resources, .set_resources = root_dev_set_resources, .enable_resources = enable_childrens_resources, .init = 0, .scan_bus = pci_scan_bridge, .enable = 0, }; static void enumerate(struct chip *chip) { struct chip *child; dev_root.ops = &mainboard_operations; chip->dev = &dev_root; chip->bus = 0; for(child = chip->children; child; child = child->next) { child->bus = &dev_root.link[0]; } } struct chip_control mainboard_via_epia_control = { .enumerate = enumerate, .name = "VIA EPIA mainboard ", };

1 0

v2 and epia
by ron minnich 29 Sep '03

29 Sep '03

OK, I am now almost at the limit of my understanding :-) I need to set up the device_operations for the 8601. Here is the mainboard config that is relevant. northbridge via/vt8601 "vt8601" pci 0:0.0 pci 0:1.0 southbridge via/vt8231 "vt8231" pci 0:11.0 pci 0:11.1 pci 0:11.2 pci 0:11.3 pci 0:11.4 pci 0:11.5 pci 0:11.6 pci 0:12.0 register "enable_usb" = "0" register "enable_native_ide" = "1" register "enable_com_ports" = "1" register "enable_keyboard" = "0" register "enable_nvram" = "1" end end Now there is nothing special about the 8601 enumeration wise. So I was hoping to do this: static void enumerate(struct chip *chip) { extern struct device_operations default_pci_ops_bus; chip_enumerate(chip); chip->dev->ops = &default_pci_ops_bus; } struct chip_control northbridge_via_vt8601_control = { .enumerate = enumerate, .name = "VIA vt8601 Northbridge", }; and static void enumerate(struct chip *chip) { extern struct device_operations default_pci_ops_bus; chip_enumerate(chip); chip->dev->ops = &default_pci_ops_bus; } struct chip_control southbridge_via_vt8231_control = { .enumerate = enumerate, enable: southbridge_init, name: "VIA vt8231" }; Which, basically, doesn't work :-( Things look OK for a while ... ========================================================================= PCI: Using configuration type 1 Enumerating: VIA vt8601 Northbridge malloc Enter, size 252, free_mem_ptr 00013a88 malloc 0x00013a88 path PCI: 00:00.0 malloc Enter, size 252, free_mem_ptr 00013b84 malloc 0x00013b84 path PCI: 00:01.0 Enumerating: VIA vt8231 malloc Enter, size 252, free_mem_ptr 00013c80 malloc 0x00013c80 path PCI: 00:11.0 malloc Enter, size 252, free_mem_ptr 00013d7c malloc 0x00013d7c path PCI: 00:11.1 malloc Enter, size 252, free_mem_ptr 00013e78 malloc 0x00013e78 path PCI: 00:11.2 malloc Enter, size 252, free_mem_ptr 00013f74 malloc 0x00013f74 path PCI: 00:11.3 malloc Enter, size 252, free_mem_ptr 00014070 malloc 0x00014070 path PCI: 00:11.4 malloc Enter, size 252, free_mem_ptr 0001416c malloc 0x0001416c path PCI: 00:11.5 malloc Enter, size 252, free_mem_ptr 00014268 malloc 0x00014268 path PCI: 00:11.6 malloc Enter, size 252, free_mem_ptr 00014364 malloc 0x00014364 path PCI: 00:12.0 Allocating resources... Unknown device path type: -926076609 compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 Unknown device path type: 80564 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 Unknown device path type: 81068 compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 <null> compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12 doe <null> compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: 0 <null> compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20 gran: e <null> compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 <null> compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran: 20 =========================================================================== you can see they go to pieces at the end. I'd like to have it such that if there is no enumerate struct member, the "right things" happen. Any advice on the best way to do this? I'm still working out the static/dynamic stuff on V2, and clearly have got it wrong. Anyway I'm still digging ... ron

1 0

V2 and via/epia
by ron minnich 29 Sep '03

29 Sep '03

looks like RAM is up! Now I get to this: Enumerating: VIA vt8601 Northbridge Enumerating: VIA vt8231 Enumerating buses...PCI: pci_scan_bus for bus 1 PCI: 01:18.0 [ffff/ffff] enabled PCI: 01:18.1 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 01:18.1 No device operations PCI: 01:18.2 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 01:18.2 No device operations PCI: 01:18.3 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 01:18.3 No device operations PCI: pci_scan_bus for bus 2 PCI: 02:00.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 02:00.0 No device operations PCI: 02:00.1 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 02:00.1 No device operations PCI: 02:01.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 02:01.0 No device operations PCI: 02:01.1 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 02:01.1 No device operations Time for SPEW :-) ron

1 0

Re: config tool + tree enumeration
by YhLu 29 Sep '03

29 Sep '03

Stefan, Change that to 1 seems no use. For Tyan S2885, the 8131 and 8111 is connected to CPU0 Link2, and 8151 is linked to CPU0 link0. I have to manual to change src/device/hypertransport.c 's hypertransport_scan_chain the link scan sequence from "0 to 2" to "2 to 0". I think it works for your case to. Regards YH -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年9月26日 5:19 收件人: linuxbios(a)clustermatic.org 主题: config tool + tree enumeration Hi, I have several non coherent ht devices in a chain, i.e. : CPU0 -- CPU1 or CPU2 -- CPU3 | | | 8131 CPU0 -- CPU2 | | | 8111 8111 8131 | 8131 The links to the non coherent devices are LDT1 or LDT2, not LDT0. Do I have to specify the "southbridges with Bus ID 1/2 then, since it's not on the first Link, or does it have to be 0, since it's the first south bridge? northbridge amd/amdk8 "mc0" pci 0:18.0 [..] southbridge amd/amd8131 "amd8131" pci 1:0.0 ^^^^^ [..] end southbridge amd/amd8111 "amd8111" pci 1:0.0 ^^^^^ [..] end end Stefan -- Architecture Team SuSE Linux AG _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

4 10

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