coreboot

coreboot@coreboot.org

12 participants
39780 discussions

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

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

03 Sep '03

Eric, For s2885 8151 | (link0) CPU0 -- CPU1 | (link2) 8131 | 8111 So the Config.lb should include northbridge amd/amdk8 "mc0" pci 0:18.0 pci 0:18.0 pci 0:18.0 pci 0:18.1 pci 0:18.2 pci 0:18.3 southbridge amd/amd8151 "amd8151" pci 5:0.0 pci 5:1.0 end southbridge amd/amd8131 "amd8131" pci 1:0.0 pci 1:0.1 pci 1:1.0 pci 1:1.1 southbridge amd/amd8111 "amd8111" pci 1:0.0 pci 1:1.0 pci 1:1.1 pci 1:1.2 pci 1:1.3 pci 1:1.5 pci 1:1.6 end end end northbridge amd/amdk8 "mc1" pci 0:19.0 pci 0:19.0 pci 0:19.0 pci 0:19.1 pci 0:19.2 pci 0:19.3 end cpu k8 "cpu0" register "up" = "{ .chip = &amd8151, .ht_width=16, .ht_speed=600 }" register "down" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }" end cpu k8 "cpu1" end Is that right? Regards YH. _

2 1

via-rhine driver on 2.4.19 on EPIA M-800
by ron minnich 03 Sep '03

03 Sep '03

via-rhine on 2.4.19 is working very poorly for us. We can plug a tulip board into the PCI slot and the board works quite well, but if we use the via-rhine we get errors and poor performance. Is the via-rhine driver any better on 2.4.19+1, 2, or more? thanks ron

3 2

epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte
by Niki Waibel 03 Sep '03

03 Sep '03

i am still trying to get this running: epia-m + bios savior + dip2plcc adapter + doc millennium 8mbyte it took quite long until all parts arrived. anyway. the current problem is that if i plug the dip2plcc adapter into the bios savior socket epia-m does not boot anymore... (of course i've written the bios to the bios savior plcc chip before). that's very strange -- i am going to check the pins of the adapter. i've 2 adapters. both refuse to work with the board. maybe this is a high frequency electrical problem... does someone know in which "speed" the bios is accessed? niki

3 7

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

02 Sep '03

S2880 and S2882 is OK now. S2885 has some problems. I will try it more.. -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2003年9月2日 17:58 收件人: ron minnich 抄送: Stefan Reinauer; LinuxBIOS 主题: Re: [COMMIT] Infrastructure Updates 4 ron minnich <rminnich(a)lanl.gov> writes: > OK, this commit works for me. Not completely, but well enough to say it's > good enough. > > The only problem is the usual PIRQ fun. I'm going to try to work out a > reasonable solution given time. Cool that sounds about right. There is a very real chance I might reverse the order of the devices on the hypertransport chain. So I can allocate from the top of the unitid space instead of from the bottom. With that it will be easier to cram all of the hypertransport chains into bus 0 cleanly. So we really need to find a way to move irq information to the static to the dynamic device tree. That is one of the harder remaining problems. It is not a show stopper but something we need to do before we are done. Eric _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

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

02 Sep '03

Eric, Could you explain the Config.lb about northbridge and southbridge PCI numbering info? Regards YH -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2003年9月2日 12:37 收件人: Stefan Reinauer 抄送: LinuxBIOS 主题: Re: [COMMIT] Infrastructure Updates 4 Stefan Reinauer <stepan(a)suse.de> writes: > * Eric W. Biederman <ebiederman(a)lnxi.com> [030902 19:28]: > > If you want all of your hypertransport devices to be on bus 0, that is > > feasible but it will take a little more work. Right now each > > hypertranport chain get's it's own bus. > > What is missing to achieve this? Just a little code. Merging busses into bus 0 is an interesting logicistics feat, but the current infrastructure will allow it. > Can this cause trouble with current board implementations? Not it is software only. > In the Tyan update code, some hardcoded bus numbers were changed. We should be able to complete remove that. Right now each Hypertransport chains appears to be it's own bus and all of that information is dynamically calculated. The busses that are Hypertranpsort chains are enumerated just like other busses. The way to look at the code is that: - device.c has the logic to enumerate and assign resources to devices and busses. - pci_device.c has the methods for doing that on pci devices. - hypertransport.c has the methods for doing that with hypertranport devices. - northbridge/amd/amdk8/northbridge.c has the drivers for the amdk8 specific northbridge. In short dynamic resource assignment should now be pretty simple and should remove the need for most of the hard codes. I have committed the code not in a final perfect state. But in a state where it works well enough to be useful. And whatever details we encounter are minor things. Passing information to the dynamic device tree from the static device tree is currently a weak area. But we are building one tree from the other so it is just a matter of a small amount of refactoring if we want to do something better. Basically what remains is to dive into the code see what it is doing, and tweak it a little if is not doing quite the right thing. But usually all that needs to happen is to improve a method of a device so that it operates better. Eric _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

[COMMIT] Infrastructure Updates 4
by ebiederman＠lnxi.com 02 Sep '03

02 Sep '03

OK. With this update I start taking advantage of the infrastructure changes I have been making with the merged trees to dynamically allocate superio device resources, and to enumerate hypertranport devices. The code is still rough around the edges but the basic ideas are there. If you want all of your hypertransport devices to be on bus 0, that is feasible but it will take a little more work. Right now each hypertranport chain get's it's own bus. Mostly I have updated the arima/hdama the rest of the boards I have only modified enough that they still function. OK Now I'm off to bug fix land for a few days. - 1.1.4 Major restructuring of hypertransport handling. Major rewerite of superio/NSC/pc87360 as a proof of concept for handling superio resources dynamically Updates to hard_reset handling when resetting because of the need to change hypertransport link speeds and widths. (a) No longer assume the boot is good just because we get to a hard reset point. (b) Set a flag to indicate that the BIOS triggered the reset so we don't decrement the boot counter. Updates to arima/hdama mptable so it tracks the new bus numbers Eric CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: NEWS src/config/Config src/config/Options.lb CVS: src/devices/Config.lb src/devices/pci_device.c CVS: src/include/device/device.h CVS: src/mainboard/arima/hdama/Config.lb CVS: src/mainboard/arima/hdama/mainboard.c CVS: src/mainboard/arima/hdama/mptable.c CVS: src/mainboard/arima/hdama/reset.c CVS: src/northbridge/amd/amdk8/Config.lb CVS: src/northbridge/amd/amdk8/northbridge.c CVS: src/northbridge/amd/amdk8/reset_test.c CVS: src/superio/NSC/pc87360/superio.c CVS: Added Files: CVS: src/devices/hypertransport.c CVS: src/include/device/hypertransport.h CVS: src/northbridge/amd/amdk8/chip.h CVS: src/northbridge/amd/amdk8/misc_control.c CVS: src/northbridge/amd/amdk8/northbridge.h CVS: ----------------------------------------------------------------------

1 0

Re: Unified setup...
by YhLu 02 Sep '03

02 Sep '03

Then, the setup scripts tool should include that support and should have support for auto.c too. YH -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年8月29日 4:48 收件人: YhLu 抄送: linuxbios(a)clustermatic.org 主题: Re: Unified setup... * YhLu <YhLu(a)tyan.com> [030828 23:36]: > PS: > - PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00ff0000, > + PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00050000, > [..] > - PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00000000, > + PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00030000, > > should be there. It defines the bus number behind the links. It will be used > when enumerating the non-coherent devices. I agree. But maybe we find a nicer way of describing this. Are these "hard coded" in hardware? The motherboard configuration should then probably contain a busnumber value for each ht bridge that implements a pci bus southbridge amd/amd8131 "amd8131" register "bus0" = "5" end southbridge amd/amd8151 "amd8151" register "bus0" = "3" end Or should this be handled distinct from the bridges with options like option BUS1=99 option BUS2=5 ? Stefan -- Architecture Team SuSE Linux AG

2 1

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