coreboot September 2003

coreboot@coreboot.org

68 participants
171 discussions

Re: [COMMIT] Infrastructure Updates 4
by YhLu 04 Sep '03

04 Sep '03

Eric, If I disable the hard_reset, it can enumerate from link2 to link0. And the 8131 on link2 and 8151 on link0 all show out. Maybe you can add MACRO to control reverse scan for AMKK8 northbridge. ( link2 then link0) But it continues to reboot. Regards Yinghai Lu Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.42.0_Fallback Thu Sep 4 19:17:58 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 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] 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 amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 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] 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 [1022/746d] enabled PCI: 01:04.6 [1022/746e] enabled PCI: pci_scan_bus for bus 2 PCI: 02:09.0 [14e4/16a7] ops PCI: 02:09.0 [14e4/16a7] enabled PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: pci_scan_bus returning with max=03 PCI: pci_scan_bus for bus 4 PCI: 04:00.0 [1022/7464] ops PCI: 04:00.0 [1022/7464] enabled PCI: 04:00.1 [1022/7464] ops PCI: 04:00.1 [1022/7464] enabled PCI: 04:00.2 [1022/7463] ops PCI: 04:00.2 [1022/7463] enabled PCI: 04:01.0 [1022/7462] enabled PCI: 04:0b.0 [1095/3114] ops PCI: 04:0b.0 [1095/3114] enabled PCI: 04:0c.0 [104c/8023] ops PCI: 04:0c.0 [104c/8023] enabled PCI: pci_scan_bus returning with max=04 PCI: pci_scan_bus returning with max=04 Hyper transport scan link: 2 new max: 0 Hypertransport scan link done Hyper transport scan link: 0 max: 5 PCI: 05:01.0 [1022/7454] enabled next_unitid: 0004 Hypertransport link capability not foundPCI: pci_scan_bus for bus 5 PCI: 05:00.0 [ffff/ffff/00ffff] has unknown header type ff, ignoring. PCI: 05:00.0 No device operations PCI: 05:01.0 [1022/7454] ops PCI: 05:01.0 [1022/7454] enabled PCI: 05:02.0 [1022/7455] bus ops PCI: 05:02.0 [1022/7455] enabled Copying LinuxBIOS to ram. -----邮件原件----- 发件人: YhLu 发送时间: 2003年9月4日 10:48 收件人: ebiederman(a)lnxi.com 抄送: Stefan Reinauer; LinuxBIOS 主题: re: [COMMIT] Infrastructure Updates 4 Eric, In the hypertransport_scan_chain, if the hard_reset is needed, it may produce problem. Hard_reset call 8111 LPC (B1, D4, F0) reg 0x47 to trigger Reset. But it is called before pci_scan_bus. At that time the 8111 LPC is still unkown. Regards YH -----邮件原件----- 发件人: YhLu 发送时间: 2003年9月4日 10:30 收件人: 'ebiederman(a)lnxi.com' 抄送: Stefan Reinauer; LinuxBIOS 主题: Re: [COMMIT] Infrastructure Updates 4 I still have problems for s2885. Amdk8_scan_bus for MC0 only from link0 to link2. link0 is connected to 8151 and link2 is connected to 8131. Then it reboot again and agin. After I reverse the scan from link2 to link0. It can scan out 8131 and 8111 but hung after "HyperT reset needed" is printed. Maybe the reset.c that I move from hdama got some problems. YH. LinuxBIOS-1.1.42.0_Fallback Thu Sep 4 17:07:56 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 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] 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 amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

re: [COMMIT] Infrastructure Updates 4
by YhLu 04 Sep '03

04 Sep '03

Eric, In the hypertransport_scan_chain, if the hard_reset is needed, it may produce problem. Hard_reset call 8111 LPC (B1, D4, F0) reg 0x47 to trigger Reset. But it is called before pci_scan_bus. At that time the 8111 LPC is still unkown. Regards YH -----邮件原件----- 发件人: YhLu 发送时间: 2003年9月4日 10:30 收件人: 'ebiederman(a)lnxi.com' 抄送: Stefan Reinauer; LinuxBIOS 主题: Re: [COMMIT] Infrastructure Updates 4 I still have problems for s2885. Amdk8_scan_bus for MC0 only from link0 to link2. link0 is connected to 8151 and link2 is connected to 8131. Then it reboot again and agin. After I reverse the scan from link2 to link0. It can scan out 8131 and 8111 but hung after "HyperT reset needed" is printed. Maybe the reset.c that I move from hdama got some problems. YH. LinuxBIOS-1.1.42.0_Fallback Thu Sep 4 17:07:56 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 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] 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 amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed

1 0

Re: [COMMIT] Infrastructure Updates 4
by YhLu 04 Sep '03

04 Sep '03

I still have problems for s2885. Amdk8_scan_bus for MC0 only from link0 to link2. link0 is connected to 8151 and link2 is connected to 8131. Then it reboot again and agin. After I reverse the scan from link2 to link0. It can scan out 8131 and 8111 but hung after "HyperT reset needed" is printed. Maybe the reset.c that I move from hdama got some problems. YH. LinuxBIOS-1.1.42.0_Fallback Thu Sep 4 17:07:56 EDT 2003 booting... Finding PCI configuration type. PCI: Using configuration type 1 Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Northbridge Enumerating: AMD K8 Enumerating: AMD K8 Enumerating buses...PCI: pci_scan_bus for bus 0 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] 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 amdk8_scan_chains max: 0 starting... dev->links= 3 Hyper transport scan link: 2 max: 1 PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003 PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007 HyperT reset needed -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2003年9月3日 20:09 收件人: YhLu 抄送: Stefan Reinauer; LinuxBIOS 主题: Re: [COMMIT] Infrastructure Updates 4 YhLu <YhLu(a)tyan.com> writes: > Eric, > > Please check function hypertransport_scan_chain definition and calling > parameters. > > It seems the .h and .c is not consistent. You are right. I have removed the middle parameter (something I was playing with) from northbridge.c and hypertransport.h. Some one shoot me for forgetting to include hypertransport.h in hypertransport.c And committed that. This should be the reason why the bus numbers don't automatically work on the s2885. Eric

1 0

init_timer()
by Greg Watson 04 Sep '03

04 Sep '03

K8 developers: I've moved init_timer() from hardwaremain.c to the static initialization code in cpu/k8/cpufixup.c as it prevents PPC code from building. Please check that everything still works ok. Greg

3 3

re: [COMMIT] Infrastructure Updates 4
by YhLu 04 Sep '03

04 Sep '03

Eric, Please check function hypertransport_scan_chain definition and calling parameters. It seems the .h and .c is not consistent. Regards YH

2 1

coding
by ron minnich 03 Sep '03

03 Sep '03

anybody object to anonymous enums? I've gotten used to them in Plan 9 and like them. Instead of this: #define FLOPPY_DEVICE 0 #define PARALLEL_DEVICE 1 #define COM2_DEVICE 2 #define COM1_DEVICE 3 #define SWC_DEVICE 4 #define MOUSE_DEVICE 5 #define KBC_DEVICE 6 #define GPIO_DEVICE 7 #define ACB_DEVICE 8 #define FSCM_DEVICE 9 #define WDT_DEVICE 10 you get this: enum { FLOPPY_DEVICE=0, PARALLEL_DEVICE, COM2_DEVICE, COM1_DEVICE, SWC_DEVICE, MOUSE_DEVICE, KBC_DEVICE, GPIO_DEVICE, ACB_DEVICE, FSCM_DEVICE, WDT_DEVICE }; The advantages I see - somewhat less prone to error - looks nicer - the big one: enums are first-class objects to the compiler, and #defines are pertty much ripped out by the compiler and disappear into constant numbers. comments? ron

6 7

description of DoC control registers
by Niki Waibel 03 Sep '03

03 Sep '03

is there a written documentation about the DoC control registers? (2000, millennium) or do i have to find out from the linux kernel drivers? niki

2 1

Which board?
by Jeff Noxon 03 Sep '03

03 Sep '03

I'm about to put some 1U servers together at the office. I want to use LinuxBIOS because they will be operated offsite, and it makes management easier. So I want Linux in Flash. Which Xeon boards are recommended at this point in time? Thanks Jeff

4 4

epia-m + bios savior + dip2plcc + doc (md2802-d08)
by Niki Waibel 03 Sep '03

03 Sep '03

okay -- it seems that things are working (a little bit). on http://www.rootshell.be/~nwaibel/docprobe.txt you can find the output of a modified version of docprobe. you can see the plain mem map of the md2802-d08 there. it is different to the md2800-d08!!! 0x0000: 512byte IPL -- is someone able to rev eng this? 0x01ff 0x0200: 512byte mirror of IPL 0x03ff 0x0400: 512byte mirror of IPL 0x05ff 0x0600: 512byte mirror of IPL 0x07ff 0x0800: 512byte IPL -- this seems to be the first 512byte of page 0 of the 8mbyte flash memory 0x09ff 0x0a00: 512byte -- not sure but could be 2nd part of page 0 of the 8mbyte 0x0bff 0x0c00: 512byte failsave IPL? -- not sure but could be 3rd part of page 0 of the 8mbyte 0x0dff 0x0e00: 512byte -- not sure but could be 4th part of page 0 of the 8mbyte 0x0fff 0x1000: the doc 2000 and doc millennium (2001) control registers are here. but it seems that this is not true for the md2802-d08 chip! everything is set to 0x00 -> docprobe does *NOT* recognize this chip as 0x11ff DoC Millennium!!! 0x1200: hmmm -- control registers? very strange. it is like IPL but (almost) all even bytes are set to 0x00 (not all!) maybe the even bytes are the control regs? 0x13ff 0x1400: no idea -- 512 empty bytes 0x15ff 0x1600: like 0x1200, but first 3 bytes are different! control registers? 0x17ff 0x1800: expected 512byte mirror of IPL here -- but it is a mirror of 0x1200! 0x19ff 0x1a00: 512byte mirror of IPL 0x1bff 0x1c00: expected 512byte mirror of IPL here -- but it is a mirror of 0x1200! 0x1dff 0x1e00: 512byte mirror of IPL 0x1fff any ideas or more info about this md2802-d08? niki BTW: the epia-m does not boot with epia-m + bios savior + dip2plcc + doc (md2802-d08). even not if bios savior is switched to the normal flash containing the bios. even not if there is only epia-m + bios savior + dip2plcc. so i booted with epia-m + bios savior and then (when linux was running) i placed the dip2plcc + doc (md2802-d08) into bios savior and changed the switch.

1 0

Re: [COMMIT] Infrastructure Updates 4
by YhLu 03 Sep '03

03 Sep '03

I have tried in s2880. southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 [..] end end will not work. In this case amd8111 will be considered as children to amd8131. Before that 8111 is next node to amd8131. For the Frequency and Width, I have add two print_regs in mainboard.c and print all regs values. Of'course, if LDTSTOP# or reset# is not asserted, the regs has no meanings. YH -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年9月3日 9:13 收件人: Eric W. Biederman 抄送: LinuxBIOS 主题: Re: [COMMIT] Infrastructure Updates 4 * Eric W. Biederman <ebiederman(a)lnxi.com> [030903 17:47]: > First the most basic result I have is that I need to know what all of the > logical devices that come out of a chip are. > So off of each logical device I have one or more channels. The only > way I could think of to describe multiple channels is to repeat > the logical device in the configuration file. > > All of the logical device paths are relative to the device they are hanging > off of (it just looks like the bus number). So to say the amd/amd8131 was > hanging off of the second hypertransport link I would change it's logical > devices to: > > southbridge amd/amd8131 "amd8131" > pci 1:0.0 > pci 1:0.1 > pci 1:1.0 > pci 1:1.1 > end > > I am not saying that is the best way to go, but it currently works. Ah. this is fine and allows porting linuxbios easily to new opteron mainboards. I see some drawbacks: * the logical devices of the amd8131 pci-x bridge has to be described in the mainboard configuration file. This means a lot of duplicate config "code" spread over the mainboard directory. Can this somehow go to the Config.lb file in southbridge/amd/amd8131/ ? * The device description itself and the link (channel?) information is intermixed (preventing above config change from happening) * link information is duplicate. This might be a feature though when devices happen that connect to more than one link. (Is this theoretically possible, i.e. to raise bandwidth?) > The register "up" is something that has not been used at all yet. Personally > I am not comfortable with the fact that we have both cpu and northbridge > instances for the cpus.. This looks weird for the opteron case, true. But most architectures still don't come with an on-cpu northbridge, so keeping that seperated might be a good idea (in case a certain northbridge can cope with several cpu types) > > Does it look like this? : > > > > 8111 > > | > > 8131 > > | > > CPU0 -- CPU1 > > Yes. The order of the device structures is significant. should this: southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 end southbridge amd/amd8111 "amd8111" pci 0:0.0 pci 0:1.0 [..] end not rather look like this then: ? southbridge amd/amd8131 "amd8131" pci 0:0.0 pci 0:0.1 pci 0:1.0 pci 0:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 [..] end end > Yes. Except I don't yet have a way to automatically down clock it from 800Mhz > which it claims it can do but cannot. this seems only like a matter of the information not being parsed from an appropriate place in the config file yet. > > Same thing applies for the 8151 that is used in the tyan and solo > > boards. The link speed is currently written by > > src/southbridge/amd/amd8151/amd8151_agp3.c > > > > If the code is already covered by the new ht code it could be removed > > from the 8151 code. > > Sounds good. YhLu? Can you confirm that link speeds to AGP are ok without that code? Does anyone have an appropriate method of testing the actual link speed and/or width between any pair of devices? Stefan -- Architecture Team SuSE Linux AG _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

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