coreboot

coreboot@coreboot.org

10 participants
39710 discussions

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

RE: Working with tsop flash
by Nick Jarmany 29 Sep '03

29 Sep '03

Kevin, In my experience of this type of SMD work, the most critcical issue is preserving the pads on the motherboard. Usually attempts to desolder parts whilst preserving them for re-use generally result in damage/weakening of the PCB. To prevent this the best way is to sacrifice the soldered on part, minimising heat damage to the PCB. Use a sharp scalpel and with a controlled hand and steady force, run the pount of the blade over the chip pins along the line where they meet the chip body. Repeating this multiple times will eventually result in the chip legs becoming severed without any undue stress having been applied. Repeat this process with the other side and lift the chip body clear. Now you are left with two rows of renundant pins! Use a hot iron with a broad tip and a good deal of solder. Put the iron on the pins and quicky apply solder. While feeding in solder, move iron over balance of the pins. With the whole lot molten you should be able to wipe off all the junk easily and quickly. The trick is speed - do not hesitate or loiter on anything for more than a second. Use plenty of solder and drag the "heap" quickly off the end. The surface tension of the ball of molten solder will bring everything with it, including any solder bridges between pads. If after this you still have some shorts, use more solder and remove by dragging a ball of molten solder steadily over the pads, adding fresh solder to the ball as you go. The best way to remove solder is with more solder! The mistake many people make with close-pitch SMD components is to use micro sized iron tips and spend ages on individual pins under microscopes. The best tactic is actually the reverse - large tip (good heat transfer), lots of solder and deal with all the pins in one operation. Our production staff can hand solder a 100-pin PQFP in under 5 seconds this way, with no shorts! Using this technique should give you the best chance of undamaged pads onto which you can solder your socket/emulator. Good luck! Nick > -----Original Message----- > From: linuxbios-admin(a)clustermatic.org > [mailto:linuxbios-admin@clustermatic.org]On Behalf Of Kevin O'Connor > Sent: 27 September 2003 06:33 > To: linuxbios(a)clustermatic.org > Subject: Working with tsop flash > > > Hi, > > I have a motherboard that I would like to get linuxbios working on. > Unfortunately, it has a TSOP flash part that is soldered > directly onto it. > I am concerned that if I write to the flash I may turn the unit into a > "brick". > > Has anyone had any experience with removing a surface mounted > flash TSOP > part, and replacing it with a ZIF socket? If I understand it > correctly, I > should be able to heat up the leads of the current flash (melting the > existing solder), extract the flash part, then solder on a zif socket > (http://www.emulation.com/catalog/off-the-shelf_solutions/sock ets/tsop/), and then finally use an eprom programmer on the existing tsop flash chip if it ever gets flashed incorrectly. Is this correct - anyone here done this before? Is this procedure very tricky (can one new to soldering expect to succeed at it)? Any advice would be appreciated, -Kevin -- ------------------------------------------------------------------------ | Kevin O'Connor "BTW, IMHO we need a FAQ for | | kevin(a)koconnor.net 'IMHO', 'FAQ', 'BTW', etc. !" | ------------------------------------------------------------------------ _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

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