coreboot September 2003

coreboot@coreboot.org

68 participants
171 discussions

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

Outstanding problems on K7SEM, EPIA and EPIA-M
by Andrew Ip 28 Sep '03

28 Sep '03

Hi, Would someone help me to fill these information in? Board Problem Solution K7SEM ECC code problem Add an option to disable ecc support EPIA ?? EPIA-M DDR setup Add SPD detection code -Andrew -- Andrew Ip Email: aip(a)cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. For public pgp key, please obtain it from http://www.keyserver.net/en.

3 2

sis740
by Andre Dias 28 Sep '03

28 Sep '03

K7SEM is sis730, in fact is a clone of M810LMR Elitegroup, Asrock and Pcchips are the same company. Btw, I use K7SEM with linuxbios and its OK (except by the keyboard idle sometimes) ======================== Andre Dias Gerente Ponto-i Equipamentos e Serviços www.ponto-i.net -----Mensagem original----- De: linuxbios-admin(a)clustermatic.org [mailto:linuxbios-admin@clustermatic.org] Em nome de David Hendricks Enviada em: sábado, 27 de setembro de 2003 01:15 Para: linuxbios(a)clustermatic.org Assunto: Re: sis740 IIRC, the Elitegroup K7SEM is supported. On Fri, 26 Sep 2003 20:01:35 -0300 "Andre Dias" <aod(a)ponto-i.net> wrote: > Has anyone tried using linuxbios with SiS740/SiS962L chipset? (eg, > pcchips new m810dlu series) > > > ======================== > Andre Dias > Gerente > Ponto-i Equipamentos e Serviços > www.ponto-i.net > > _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

4 3

Working with tsop flash
by Kevin O'Connor 27 Sep '03

27 Sep '03

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/sockets/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. !" | ------------------------------------------------------------------------

7 6

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 September 2003