coreboot

coreboot@coreboot.org

3 participants
39562 discussions

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

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

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