coreboot July 2003

coreboot@coreboot.org

67 participants
150 discussions

Re: configurable onboard components
by ron minnich 22 Jul '03

22 Jul '03

On Tue, 22 Jul 2003, Stefan Reinauer wrote: > * you disabled onboard ethernet and ac97 in amd8111_lpc.c > can we make this somehow configurable? Is there a way to probe > whether these are actually wired through to some outputs? hmm, could I have a better example of why we need that static device tree :-) ron

1 0

SPD reading with asus A7S333 - SiS745
by Rudolf Marek 22 Jul '03

22 Jul '03

Hello, Someone earlier got similar problem. Asus is muxing the devices on the SMBUS. I'm developing drivers for lm_sensors project. (W83785 driver) I got my smbus working (same as SiS645) There are some devices on the bus - ATXP2, W83785 and some Asus ASIC. But no SPD EEPROM, nor PLL. I'm curious about the content of my SPD. Someone here pointed out that it can be enabled by some of GPO bits. I got 2 problems. 1) I dont have a datasheet for SiS745 (I ot only for SiS630) 2) I dont know which GPO to enable. Please would someone be so king and give me some advice? I got disassembled BIOS for reference, but I even dont know in wich PCI dev should I look for GPO. You will need this information anyway if you plan tu support this motherboard :) (it will be very nice) Regards Rudolf Marek

2 1

Re: Please do not fork.
by Greg Watson 22 Jul '03

22 Jul '03

At 4:11 PM -0600 21/7/03, Eric W. Biederman wrote: >ron minnich <rminnich(a)lanl.gov> writes: > >> On Mon, 21 Jul 2003, Stefan Reinauer wrote: >> >> we're not going to fork. >> >> That was more of a warning about what could happen. We have lots of >> committers out there and more are going to join. We may not always agree >> on how things are done, and we must not get into the habit of ripping each >> other's code out -- that way lies madness. > >There are some major design decisions coming before we freeze the 2.0 core, >and this is just a warning that we need to be looking at these things >closely, and that there are some strong opinions out there. I never >had any intention of forking. > >The target is to have a hardware independent hardwaremain.c > >We have called a cease fire for a until I get back with Ron and Greg promising >to look at what I have done with the device stuff. > >If a enumerate_static_devices can be written that converts from the chip tree >to the device tree and we get everyone working with and familiar with >both pieces of the code we should be able to have some more rational >discussion about what needs to happen. > >Conversations beyond this need to start hitting the list. > >Eric The issue for me is that I need to have static initialization working before I can continue, so my intention is build something that will hopefully be acceptable to everyone. I can probably merge the chip and device structures that gives me a way forward without replicating what Eric is doing. However a single call to enumerate_static_devices, particularly at the current location, is NOT acceptable to me. Here's my suggestion to move forward: 1. I need to be able to enable/configure static devices at specific points in hardwaremain, particularly on entry, after console_init and prior to pci enumeration. I suggest a routine called device_configure() that is passed the root of the device tree and a pass flag: void device_configure(struct device *, enum dev_pass) enum dev_pass { DEV_PASS_PRE_CONSOLE, DEV_PASS_PRE_PCI, DEV_PASS_ENUMERATE, DEV_PASS_CONFIGURE, DEV_PASS_ENABLE, DEV_PASS_INITIALIZE }; Calls to device_configure() with the appropriate flag will be inserted in the appropriate locations in hardwaremain. More flags/calls call be added if necessary. Calls to dev_enumerate(), dev_configure(), etc. to probe and configure dynamic bus devices will be replaced with calls to device_configure() with the appropriate flag. Dynamic devices will be added to the device tree as appropriate. 2. New fields added to struct device, including a 'static' flag that is set for static devices, and something analogous to the chip structure for static device info. 3. Continue use of the chip.h files in configuration directories (although the name could be changed to device.h) and the 'register' configuration directive. 4. Removal of all device specific calls from hardwaremain, such as 'init_timer()' into static initialization files using (4) above. 5. The configuration process will build a static device tree that will be called device_{target}.c in the target build directory and linked with the linuxbios image. My intention is to start coding this tomorrow, so if anyone has any major objections/suggestions, please let me know asap. Regards, Greg

4 8

EPIA-M DDR ram init progress
by Dave Ashley 22 Jul '03

22 Jul '03

As a recap I was trying to get 2 specific DDR modules working with the epia-m. One has ICT chips and the other has GET chips. The ICT module works with the hardcoded dram configuration, but the GET module doesn't. ICT = 1 bank 128M colbits = 10 GET = 2 banks 64M colbits = 9 I had tried hardcoding the dram settings to the ones award bios uses for the GET module, but it wasn't working. I figured out what the problem was. I need to do the ddr setup for each bank on the ddr module, not just the first one. The hardcoded settings correspond to a ddr with just a single bank. SPD contents is very easy to access. The epia-m code is including src/northbridge/via/vt8623/raminit.inc to initialize ram. I found problems with this, the jedec ddr init spec sequence calls for reads of the ddr memory, this source actually does some writes. I'm wondering what the preferred way of implementing spd for epia-m would be. Should instead of including src/northbridge/via/vt8623/raminit.inc I put that code in with the epia-m code, mix it with the smbus SPD read code, and leave the result in the epia-m tree? Or should I modify the src/northbridge/via/vt8623/raminit.inc file directly? I don't see how that can work since the SMBUS/SPD is accessed with the vt8235 registers, but the DDR dram control registers are part of the northbridge. I can rebuild linuxbios to have it work hardcoded for either memory module type and it works fine, and I can probably live with this state until someone else gets SPD working if it might happen within a month or two. Otherwise I'll probably have to tackle it myself. VIA's Bios porting guide for the nortbridge on the epia-m seems very explicit on how to configure the ddr memory based on the SPD settings. Implementing it should just be a matter of grinding through their flow charts. It's simplified because it only has to deal with DDR memory. -Dave

3 2

See you later...
by ebiederman＠lnxi.com 21 Jul '03

21 Jul '03

I will be at the Ottowa Linux Symposium or travelling to and from there for the rest of the week. Eric

1 0

Re: K8 + 2.4.21 + Tyan S2880
by YhLu 21 Jul '03

21 Jul '03

Eric, In the auto.c, if I enable : sdram_initialize(&cpu1), the linuxbios need another 20k. What happened? Only add one line and the same function has been called ??? Regards Yinghai Lu -----邮件原件----- 发件人: YhLu 发送时间: 2003年7月21日 14:58 收件人: 'ron minnich' 抄送: ebiederman(a)lnxi.com; Stefan Reinauer; linuxbios(a)clustermatic.org 主题: Re: K8 + 2.4.21 + Tyan S2880 Ron, Before fallback is 64k, I make normal image into (512-64)k, and fallback image into 64k, and then cat them into one 512k. Actually the normal is quite loose with a lot of zeros, and the payload is about 20k. So I need to change to Config in the mainboard dir to make sure normal image has 512-96k. or that's to say change several 65536 to 96*1024?? It that right? Regards Yinghai Lu -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年7月21日 14:49 收件人: YhLu 抄送: ebiederman(a)lnxi.com; Stefan Reinauer; linuxbios(a)clustermatic.org 主题: Re: 答复: K8 + 2.4.21 + Tyan S2880 On Mon, 21 Jul 2003, YhLu wrote: > So fallback image will be 96K? that's how I'm doing it. With a 1 Mbyte flash I don't worry much. ron

2 1

Re: K8 + 2.4.21 + Tyan S2880
by YhLu 21 Jul '03

21 Jul '03

Eric, I can build the linuxbios. But it is too large and it is around 60k, and tg3.zelf is about 22k, and tg3--ide_disk.zelf is about 24k, then the sum is above 65k.So I can not build the images. The Ram conf costs 20k ??? Any advise. Regards Yinghai Lu -----邮件原件----- 发件人: YhLu 发送时间: 2003年7月21日 10:31 收件人: 'ebiederman(a)lnxi.com' 抄送: ron minnich; Stefan Reinauer; linuxbios(a)clustermatic.org 主题: Re: K8 + 2.4.21 + Tyan S2880 Eric, Thanks info about ROMCC option about -mcpu=k8. I will try and make the RAM can be configurable. My CPU is C0, In Opteron We may need to manipulate the MSR to enable the apic. Regards Yinghai Lu YhLu <YhLu(a)tyan.com> writes: > Eric, > > My boss has said that I can release the source code to you. > > Please find out the patch I made. Make the diff to today's tree. > > I didn't test RON new script and still use the old scripts tools. > > I strip out the LSI scsi support, because I don't know if there is any > license problem, and I have referred to their documents and may need put > their FW in the ROM. Ah, an interesting problem. > It's greater you add ops->enable function that make it easy to handle > special device. To some device if it is not gotten magic code, it will not > get the resource allocate to it. Before that I have to do it in init > function and re-allocate the resource to it again. Welcome. > Please refer to my old amd8131_ioapic.c in southbridge/amd8111. > Also you init the io_base, upper16 reg, otherwise the device in PCIX > will not got io port allocated to them, and will not work. Sorry I don't quite parse that sentence. > I have tested Stefan's the code about coherent_ht.c, and add some hardcode > to it. > coherent_ht.o.c is the original one. Coherent_ht.1.c is total hardcode one. > coherent_ht.c and coherent_ht.2.c are modified with some hardcode ones. Interesting looking at this code are you working with C0 stepping Opterons? I have the stock B3 and am having fun getting the memory resets in all of the proper places. > raminit.c and raminit.1.c are till the hardcode one, and I have tried to use > the configurable one, but auto.c can not be compiled, it is too big and used > up REG? Looking. It is your romcc options. By default romcc will not use mmx or sse registers unless you tell it that you have them. I have been doing this with -mcpu=k8. The register pressure is much less when you have 24 registers to work with instead of just 8. > The old one has been renamed to raminit.o.c. > > To start other cpus, in auto.c We must enable apic and make sure all > apic_id is right. Please refer to mainboard/tyan/s2880/auto.c boot_cpu > function. Yep, an interesting way of doing it. > Again, thank you all to answer my questions to help Tyan s2880 work with > LinuxBIOS. Ron, Stefan. Could one of you help with merging Yinghai's code? I might have time, but I don't think I will manage it before I leave for OLS on Tuesday. Eric

3 5

Re: K8 + 2.4.21 + Tyan S2880
by YhLu 21 Jul '03

21 Jul '03

Ron, Before fallback is 64k, I make normal image into (512-64)k, and fallback image into 64k, and then cat them into one 512k. Actually the normal is quite loose with a lot of zeros, and the payload is about 20k. So I need to change to Config in the mainboard dir to make sure normal image has 512-96k. or that's to say change several 65536 to 96*1024?? It that right? Regards Yinghai Lu -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年7月21日 14:49 收件人: YhLu 抄送: ebiederman(a)lnxi.com; Stefan Reinauer; linuxbios(a)clustermatic.org 主题: Re: 答复: K8 + 2.4.21 + Tyan S2880 On Mon, 21 Jul 2003, YhLu wrote: > So fallback image will be 96K? that's how I'm doing it. With a 1 Mbyte flash I don't worry much. ron

1 0

答复: K8 + 2.4.21 + Tyan S2880
by YhLu 21 Jul '03

21 Jul '03

Ron, So fallback image will be 96K? Regards Yinghai Lu -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2003年7月21日 14:45 收件人: YhLu 抄送: ebiederman(a)lnxi.com; Stefan Reinauer; linuxbios(a)clustermatic.org 主题: Re: K8 + 2.4.21 + Tyan S2880 On Mon, 21 Jul 2003, YhLu wrote: > I can build the linuxbios. But it is too large and it is around 60k, and > tg3.zelf is about 22k, and tg3--ide_disk.zelf is about 24k, then the sum is > above 65k.So I can not build the images. I now routinely set my linuxbios size for 64K with payload size of 32k. romcc is WONDERFUL but it does grow things a bit. ron

2 1

silly ld question
by ron minnich 21 Jul '03

21 Jul '03

anybody know why ld would give you something like this: bash-2.05b$ readelf -l linuxbios Elf file type is EXEC (Executable file) Entry point 0xffff0004 There are 3 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0xffff0000 0xffff0000 0x117d0 0x117d0 RWE 0x1000 LOAD 0x012fd8 0xffffffd8 0xffffffd8 0x00028 0x00028 RWE 0x1000 LOAD 0x013ff0 0xfffffff0 0xfffffff0 0x00000 0x00000 RW 0x1000 Section to Segment mapping: Segment Sections... 00 .rom .payload .reset .id 01 .reset .id 02 bash-2.05b$ emacs ldoptions note that section 00 and section 01 have got the .reset and .id sections. This is misdirecting objcopy to do the wrong thing. What could cause ld to put duplicate section names in two different segments? What's odder: the ldcscripts that produce this file, and the right file: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0xffff0000 0xffff0000 0x10000 0x10000 RWE 0x1000 LOAD 0x011ff0 0xfffffff0 0xfffffff0 0x00000 0x00000 RW 0x1000 Section to Segment mapping: Segment Sections... 00 .rom .payload .reset .id 01 are IDENTICAL. So I guess it's something in how things are compiled? I am stumped at present. ron

1 1

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

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