coreboot March 2004

coreboot@coreboot.org

54 participants
166 discussions

A bit OT: external equipment for writing...
by Vic Berdin 31 Mar '04

31 Mar '04

Hi, This maybe the wrong list to post this but since you guys are into the field of creating your own BIOSware, I would like to ask if anyone knows of a device or equipment (connected via stadard PC port) that may be used in order to write data into a BIOS chip? I am currently scouring the net for any material (software/hardware) that can aid me in safely replacing the BIOSware on an SST49LF008A FWH that socketted on an AMD GX2-based target board. The said board and SST chip is not (yet) supported (or listed) by this project. However, our goal is to replace the existing BIOSware with Linux. TIA - Vic

7 11

CVS Management tools
by Gregg C Levine 30 Mar '04

30 Mar '04

Hello from Gregg C Levine Is anyone using this one, from the KDE environment, CERVISIA? Supposedly it will allow the user to do everything he normally does with CVS, by hand. I discovered, that the Source Forge CVS does not really appreciate the tool, despite the fact that the commands used, are the same as those on other CVS storage sites that I've visited. For example I was able to retrieve the ECOS sources from its CVS storage, without much of a hassle, and that's the other one that I've visited on a fairly regular basis. Any suggestions would be greatly appreciated. ------------------- 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

1 0

答复: 答复: 答复: Cache On and ECC clear
by YhLu 30 Mar '04

30 Mar '04

Eric, After change the FALLBACK_SIZE from 96k to 128k. it works. And 64k as XIP_ROM_SIZE it works. Regards YH -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2004年3月29日 22:50 收件人: YhLu 抄送: ron minnich; Li-Ta Lo; LinuxBIOS 主题: Re: 答复: 答复: Cache On and ECC clear YhLu <YhLu(a)tyan.com> writes: > Eric, > > It seems it's all right in mtrr setting. Except 0x201 and 0x203 setting in > earlymtrr.inc should set 0xff for msr.hi intead of 0xf > > Before mtrr processing for clearing Hmm. Assuming 0000 == 0x200, 0001 == 0x201 etc. So you have to base and mask pairs. > Normal mode > 0000=0x0000000000000006 > 0001=0x000000fffff00800 > 0002=0x00000000fffe8006 This is a base address 4GB - 96K > 0003=0x000000fffffe8800 This is a size and it tries to be 96K. It is actually something like 32K. > Fallback mode > 0000=0x0000000000000006 > 0001=0x000000fffff00800 > 0002=0x00000000fffd0006 This is a base address 4GB - 160K > 0003=0x000000fffffe8800 This is a size aand it tries to be 96K. It is actually something like 32K. So somehow you got at non power of 2 size into XIP_ROM_SIZE. So much less of your code is cached than you would expect. So instruction fetches take a very long time. And loops are slow. The comments from my HDAMA Config.lb ## XIP_ROM_SIZE must be a power of 2. ## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE It looks like these needs to be enforced, somehow so build time mistakes don't happen. Perhaps: #if ((XIP_ROM_BASE % XIP_ROM_SIZE) != 0) || ((XIP_ROM_SIZE & (XIP_ROM_SIZE - 1)) != 0) #error XIP_ROM_SIZE must be a power of 2 and XIP_ROM_BASE must be a multiple of it #endif Eric

1 0

答复: 答复: Cache On and ECC clear
by YhLu 30 Mar '04

30 Mar '04

Eric, It seems it's all right in mtrr setting. Except 0x201 and 0x203 setting in earlymtrr.inc should set 0xff for msr.hi intead of 0xf Before mtrr processing for clearing Normal mode 0000=0x0000000000000006 0001=0x000000fffff00800 0002=0x00000000fffe8006 0003=0x000000fffffe8800 Fallback mode 0000=0x0000000000000006 0001=0x000000fffff00800 0002=0x00000000fffd0006 0003=0x000000fffffe8800 after mtrr processing for clearing, Normal mode 0000=0x0000000000000001 0001=0x000000fffff00800 0002=0x00000000fffe8006 0003=0x000000fffffe8800 Fallback mode 0000=0x0000000000000001 0001=0x000000fffff00800 0002=0x00000000fffd0006 0003=0x000000fffffe8800 -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: 2004年3月29日 17:18 收件人: YhLu 抄送: ron minnich; Li-Ta Lo; LinuxBIOS 主题: Re: 答复: Cache On and ECC clear YhLu <YhLu(a)tyan.com> writes: > Eric, > > I verified the exchange the cpufixup after the cache_on...mtrr_check in cpu. > c for S2882. > > Found one interesting thing > 1. In fallback mode, it does not pause after "Clearing LinuxBIOS memory " > and "Copying LinuxBIOS to ram". > 2. In normal node, it does pause after the "Clearing" and "Copying" ( 5s and > 4s). > > What could cause that? So we are talking about quantities all within the first 1MB of ram... This sounds like something is goofy with the mtrrs. At least that is the usual suspect when something is running slowly. Eric

2 1

答复: Cache On and ECC clear
by YhLu 29 Mar '04

29 Mar '04

Eric, I verified the exchange the cpufixup after the cache_on...mtrr_check in cpu. c for S2882. Found one interesting thing 1. In fallback mode, it does not pause after "Clearing LinuxBIOS memory " and "Copying LinuxBIOS to ram". 2. In normal node, it does pause after the "Clearing" and "Copying" ( 5s and 4s). What could cause that? Regards YH -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2004年3月28日 21:03 收件人: Eric W. Biederman 抄送: Li-Ta Lo; LinuxBIOS 主题: Re: Cache On and ECC clear On 28 Mar 2004, Eric W. Biederman wrote: > But please break it out into it's own separate inline function. > > It has two very strong requirements. > 1) That we never trigger a hardware read on the addresses were are clearing > before we have triggered a hardware write. The fact I setup the area > as uncached but write-combining ensures this. > 2) That this code runs very fast. It needs to be able to run at 6.4GB/s > when you have dual channel PC3200 DDR installed. This is one of the > reasons we run it on a per cpu basis. The loop can only run at 4.0GB/s > from the other cpu. > ok, if it stays assembly this explanation will be put in with it. ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

Re: EPIA-M "Magic Potion"?
by Dave Ashley 29 Mar '04

29 Mar '04

Ron says: >dave, can you send me a diff -u and I'll apply that patch. Between what and what? Your source and my source have forked hopelessly apart. A human has to step in and integrate the changes. I certainly don't have time to do it. In fact I had thought when I passed my patch back to this group July 2003 my version would have been integrated. If I send you a patch now, maybe that will just gather dust again and we'll have to go through this all again later. Meanwhile I explained in the email what had to be patched and how, start with that. This should get VGA working at least. Maybe that's all that's left. Note I'm not actually building the latest cvs version of linuxbios, I just looked at the files and saw the vga init code wasn't there. -Dave

4 6

Cache On and ECC clear
by Li-Ta Lo 29 Mar '04

29 Mar '04

Eric, I tried to call cache_on() first than the cpufixeup() in cpu.c to fix the "slow ecc clear" problem. It still works that way. Is there any reason we can't do this ? Ollie

3 10

mkelfImage initrd help
by Don Elwell 28 Mar '04

28 Mar '04

Hello, Not sure if this is the right place for this question but I'm not sure where else to send the message. I'm having trouble booting a Linux kernel/initrd image. My original goal was: LinuxBIOS->Etherboot->Linux (single mkelfImage kernel/initrd) In the course of troubleshooting this problem I'm working with one of two configurations: Original BIOS->Etherboot via Floppy->Linux (single mkelfImage kernel/initrd). and Original BIOS->ISOLinux->Linux (separate kernel and initrd). Booting the kernel/initrd via the CD-ROM works great. Booting via Etherboot doesn't. I get kernel panics indicating that the kernel can't mount its root fs. I've modified the mkelfImage convert_params.c file to print out everything. Just before the "Jumping to Linux" line, I added code to print out the first 512 bytes of the initrd image. The values printed match perfectly with the first 512 bytes of my initrd image. The kernel table values for the initrd also look good: ramdisk at 0x800000. I also added code in the Linux kernel do_mounts.c file (just after the "RAMDISK: could not find valid ramdisk image") to print out the first 512 bytes of the buf buffer. At this point, the values in no way match the values in the initrd image (nor to those printed out in convert_params.c). Anyone got any insight on what might be happening here or how to continue debugging this? Thanks, -don

2 5

is_cpu_pre_c0()
by YhLu 28 Mar '04

28 Mar '04

Can we change is_cpu_pre_c0() to global macro define I think most K8 is C0 after. And I can not include debug info (MAX...._LOGLEVEL=8). The linuxbis image is more than 65536. Regards YH

3 3

romcc -O and -O2
by YhLu 28 Mar '04

28 Mar '04

Eric, What's the difference of -O and -O2? t seems -O2 can produce small code for auto.c. Regards YH

2 2

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 March 2004