coreboot

coreboot@coreboot.org

6 participants
39707 discussions

K8 Progress
by ron minnich 23 Jul '03

23 Jul '03

it's getting easier and easier to resync the new config tool to the ongoing changes. Took a few minutes earlier today and I was back on the air. I have noticed that the testing of the first 16M of memory in auto.c is very slow, so I've turned it off on my version. My guess is for you guys it runs very fast. There must still be a difference somewhere. Can someone confirm that the K8 memory test in auto.c is fast? A note on the SST 49LF0[48]0 flash parts, since we've all had trouble with them. Here's what I have found. The first time I flash there is always trouble. However, if I 'eraseall /dev/mtd0' a few times, then do the 'dd trick': dd if=image of=/dev/mtd0 bs=65536 seek=$i skip=$i i.e. program individual blocks, it almost always works. >From that point on, programming is a matter of cat image > /dev/mtd0 So it seems there is something 'sticky' in these parts when new, cured by programming individual blocks. Flash is very odd ... ron

1 0

second alternate startup idea
by ron minnich 23 Jul '03

23 Jul '03

Seems to me we could enable the full flash rom decoding, then put the c_payload at 0xfffx0000, then have really big linuxbios images. I'll take a look at this too, later. ron

1 0

About my last post
by Gregg C Levine 23 Jul '03

23 Jul '03

Hello again from Gregg C Levine I dislike sending these. Along with the problems associated with this cloddish mailer. Sorry guys for sending that blasted thing out, twice. Ron, when you get the four of them, just discard one pair, or the other. ------------------- Gregg C Levine hansolofalcon(a)worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )

1 0

K8 news
by ron minnich 23 Jul '03

23 Jul '03

For those just joining. Eric Biederman has a solid C compiler for x86 for no-memory situations. The amount of assembly code in LinuxBIOS shrinks day-by-day. Stefan Reinauer at Suse and Eric have been working on different parts of the K8 problem and have linuxbios up on K8 1, 2, and 4 CPU systems. YHLu of Tyan has linuxbios up on the new K8 motherboard. Linuxbios also works now on the Arima HDAMA. Greg Watson and I have been upgrading the config tool. It is a substantial improvement. I am now easily able to track the tree and build with the new config tool only. The new tool is faster and produces more comprehensible makefiles. Perl expressions in makefiles are a thing of the past. The new tool is also much better for non-PC systems, e.g. PPC. I am also booting Linux directly out of FLASH using the 49LF080 1 Mbyte parts. I will be starting work on the NewISYS board soon. AMD has provided support in many ways, including opening up the documents. AMD should be credited for their longstanding support of LinuxBIOS on the K8, going back to long before the K8 was officially released. I think vendors such as AMD, LNXI, Suse, Tyan, Arima, and Newisys (I hope I left no one else out) are to be commended for their support of LinuxBIOS on this new CPU. This work represents a substantial financial commitment on the part of these companies. Thanks to you all. ron

1 0

fallbackimage, question
by Felix Kloeckner 22 Jul '03

22 Jul '03

hello, i successfully ported the fallbackimage-principle for the elitegroup p6stp-fl (sis630)but the problem is that it only works with 64KB fallback-image (i took the calculations from "supermicro/p4dpeg2/Config") because i need more space for the payload i need a bigger fallbackimage, but if i change the size of "FALLBACK_IMAGE_SIZE" only the fallbackimage will boot, not the normalimage (each time the normalimage should be jumped to the watchdogtimer expires and resets the board, after that the fallbackimage will boot again) does anybody see what i made wrong? (below is a part of my config - felix size related stuff from my config ---------------------------------------------- option USE_FALLBACK_IMAGE=0 expr USE_NORMAL_IMAGE=!USE_FALLBACK_IMAGE option ROM_SIZE=0x80000 #works only with exactly 0x10000, need more! <--------- option FALLBACK_IMAGE_SIZE=0x10000 option ROM_IMAGE_SIZE=43520 expr ROM_SECTION_SIZE=(USE_FALLBACK_IMAGE * FALLBACK_IMAGE_SIZE) + (USE_NORMAL_IMAGE * (ROM_SIZE - FALLBACK_IMAGE_SIZE) ) expr ROM_SECTION_OFFSET=(USE_FALLBACK_IMAGE * (ROM_SIZE - FALLBACK_IMAGE_SIZE)) + (USE_NORMAL_IMAGE * 0) expr ZKERNEL_START=(0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1) expr PAYLOAD_SIZE=ROM_SECTION_SIZE - ROM_IMAGE_SIZE expr _ROMBASE=ZKERNEL_START + PAYLOAD_SIZE #cache the upper 16M of the 4G address space #or else the decompression would be so slow that #the watchdogtimer resets the board even before #decompression is done option XIP_ROM_SIZE= 0x01000000 option XIP_ROM_BASE= 0xfe000000

1 0

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

22 Jul '03

Eric, It can be compiled with you new code. But it meet problems in Etherboot stage. In S2880 has two broadcom NIC port in 8131 bus B, and one amd 8111 built-in nic, and even if I hide it in amd8111 init and Etherboot can find it and try to enable it and can not find the PM cap so aborting, in the old linuxbios code (before yesterday) ( with mem hard code), it will go to tickle on Broadcom nic, but in the new code (yesterday check in) ( mem configurable), it will go to MB restarting.??? How about arima broadcom nic position? Regards Yinghai Lu -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2003年7月21日 18:33 收件人: YhLu 抄送: ron minnich; Stefan Reinauer; linuxbios(a)clustermatic.org 主题: Re: K8 + 2.4.21 + Tyan S2880 YhLu <YhLu(a)tyan.com> writes: > 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 ??? All functions are inline and the set of functions called is large. At least I believe that is the issue. And good luck catching up.... While I am away you get a chance. My latest code has changed sdram_initialize one more time to take a cpu count parameter. And perversely this should help because if a function is called in a loop it will only be inlined once instead of multiple times. Eric

1 0

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

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