September 2005 - coreboot - mail.coreboot.org

Re: [LinuxBIOS] BIOS Saver RD1
by Ken Fuchs June 5, 2007

June 5, 2007

> On Wed, Aug 03, 2005 at 11:59:20AM +0900, Jun OKAJIMA wrote: > > Probably, most guys here use BIOS Saver. > > And it works well? > > In mine, RD1 for PLCC gets not being writable suddenly. > > I mean, it seems writable but # flash_rom -v fails. > > I solved this problem by a quick hack. > > > > How about yours? You can write RD1 or W49F002U well? > > Any problem happen? Johnathan McDowell wrote: > Even after that it's sometimes a bit flakey and I have to erase, then > write it. I've put the board's original BIOS in the RD1 and am writing > to the SST 39SF020A instead, which works without problems. I've read posts about the RD1 that suggest its integrated flash device is low quality and it may take 10 or more flash attempts to get a good flash update to the RD1 flash device. As a result, many RD1 BIOS Savior users will flash the commercial BIOS image (or other known good BIOS image) into the RD1 integrated flash device as many times as needed to get an image that boots. Then use the original BIOS device to flash test BIOS image (usually LinuxBIOS images among this group), since the original BIOS device usually flashes OK on the first attempt. I've used the RD1 in the above fashion with great success on the Tyan S2885 mainboard. The same RD1 would not work on the nVidia CK8-04 CRB mainboard. I think the CK8-04 CRB requires a flash device that the RD1 does not support. However, the RD1 worked well as an "do nothing" adapter which allowed swapping the BIOS flash device between my flash burner and the mainboard without any wear to the mainboard's BIOS socket. BTW, my flash burner is an older Enhanced Willem Universal Programmer. I got mine for only $60 US over a year ago. I've seen it for less than $40 on eBay a few weeks ago. The newest model is going for about $50 US. It does a LinuxBIOS flash in about 5 minutes; not bad for a $60 burner. However, it does require changing DIP switches to match an image for each device it can program. Great for the amateur or professional with a small budget. > > BTW, a cable of your RD1 is not broken? > > I needed soldering to fix it. > Mine was fine out of the box. Mine cable and switch worked fine out of the box as well. Sincerely, Ken Fuchs <kfuchs(a)winternet.com> ami-mac-sun

16 47

RE: [LinuxBIOS] E7501 Raminit rewrite
by Lu, Yinghai Nov. 1, 2005

Nov. 1, 2005

Every define have SPD_DDR_ prefix, or with ddr_spd.h and SPD_ prefix.... YH -----Original Message----- From: Steven J. Magnani [mailto:steve@digidescorp.com] Sent: Wednesday, September 14, 2005 11:06 AM To: Lu, Yinghai; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite Can you be more specific about the changes you'd like to see? Steve -----Original Message----- From: Lu, Yinghai [mailto:yinghai.lu@amd.com] Sent: Tuesday, September 13, 2005 10:27 AM To: Steven J. Magnani; linuxbios(a)openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite It's good to have spd.h there. But the name should be changed for support DDR2...etc. YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Steven J. Magnani Sent: Tuesday, September 13, 2005 8:08 AM To: linuxbios(a)openbios.org Subject: [LinuxBIOS] E7501 Raminit rewrite This one ends up being a little more than a "patch". I ended up reorganizing the E7501 raminit code so I could follow it, and fixed some bugs along the way. Significant logical changes: * Added support for "fast" (64-clock) refresh * Added code to support remap window for 3 - 4 GB systems * Fixed premature configuration of true row boundaries that resulted in some sections of DRAM not receiving JEDEC commands (see http://openbios.org/pipermail/linuxbios/2005-June/011752.html) * Redefined RCOMP_MMIO so that RCOMP registers can be configured on systems where A20M# is asserted. * Disabled subsystem (vendor) ID configuration * #ifdef'd out suspicious looking code (see http://openbios.org/pipermail/linuxbios/2005-June/011759.html) * Added optional run-time checking of dual-channel compatibility of installed DIMMs * Move JEDEC SPD and SDRAM definitions into reusable #include files Probably, the rewritten code should be reviewed as if it were new. My hope is that it is now easy enough to follow that this shouldn't be too bad. The original code is, of course, in Subversion. Since I reordered the functions as part of the rewrite, a 'diff' of of the new code against the original won't tell you much. I've attached a reordered copy of the Subversion code that won't compile, but should be a little easier to diff against the new code so you can see what's changed. I will hold off on committing this for awhile to give people time to look at it. I know that radical changes are a pain to review, but IMHO the improvement in maintainability is significant. New files that are part of this 'patch', but not included here (I committed these to Subversion): src/include/spd.h src/include/sdram_mode.h src/include/northbridge/intel/e7501/e7501.h Thanks, Steve ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include <standard.disclaimer>

2 1

[LinuxBIOS] Does LinuxBIOS run on the ECS 760GX-M?
by Angel Oct. 17, 2005

Oct. 17, 2005

On my search for a LinuxBIOS compatible AMD mainboard, I tripped over the ECS 760GX-M. It's socket 754 and uses the SiS chips 760GX and 964. As far as I know SiS is supporting LinuxBIOS actively, so in terms of the chipset the board should run LinuxBIOS. Plus, it has a 4Mb (=500 KiB) Flash ROM with the following description from the manufactorer's website: SYSTEM BIOS Award BIOS with 4Mb Flash ROM Supports Plug and Play 1.0A, APM 1.2, Multi Boot, DMI Supports ACPI revision 1.0 specification Because I want to be shure that this mainboard supports LinuxBIOS before I will buy it, I thought I'd better ask here if anyone has it in use and can say something about it. The chipset and the plug and play BIOS at least sound promisingly to me. Oh, and a previous ECS mainboard, the K7SEM, is proven to be compatible.

2 4

RE: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16
by Lu, Yinghai Oct. 9, 2005

Oct. 9, 2005

I didn't catch you. For 8 ways dual core system. Lapicid will be 0x10-0x1f, so 0 will be used by ioapic. YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of ebiederman(a)lnxi.com Sent: Tuesday, September 06, 2005 1:13 PM To: yhlu Cc: linuxbios(a)openbios.org Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 yhlu <yinghailu(a)gmail.com> writes: > use max_lapicid() + 1 as apicid_base is not good. > > esp for apic id lifting. > > for 8 way dual core system, max_lapicid() will be 0x0f with lifting, and with > lifting it will be 0x1f. The x86 standard is now is tuples of (nodeid, coreid) which means on k8 based systems the cpu apicids will always be densly packed. I haven't seen the reference but I have been assured that is the way things are working. I believe it was Richard Breuner assured me of this In addition in the code cleanups that have been us only use the (nodeid, coreid) as supporting multiple form simultaneously is both confusing, and creates code that is hard to maintain. Eric -- LinuxBIOS mailing list LinuxBIOS(a)openbios.org http://www.openbios.org/mailman/listinfo/linuxbios

4 6

[LinuxBIOS] AMD serenade help
by Jia Jianwei Sept. 30, 2005

Sept. 30, 2005

AMD serenade hangs when initialize ram. in the function "route_dram_accesses", when write to limit register, system just hang. If anyone has this problem before? Please help. Thanks! static void route_dram_accesses(const struct mem_controller *ctrl, unsigned long base_k, unsigned long limit_k) { /* Route the addresses to the controller node */ unsigned node_id; unsigned limit; unsigned base; unsigned index; unsigned limit_reg, base_reg; device_t device; node_id = ctrl->node_id; index = (node_id << 3); limit = (limit_k << 2); limit &= 0xffff0000; limit -= 0x00010000; limit |= ( 0 << 8) | (node_id << 0); base = (base_k << 2); base &= 0xffff0000; base |= (0 << 8) | (1<<1) | (1<<0); limit_reg = 0x44 + index; base_reg = 0x40 + index; for(device = PCI_DEV(0, 0x18, 1); device <= PCI_DEV(0, 0x1f, 1); device += PCI_DEV(0, 1, 0)) { /* hangs here */ pci_write_config32(device, limit_reg, limit); pci_write_config32(device, base_reg, base); } } Jianwei

1 0

[LinuxBIOS] Linux BIOS support for SuperMicro p8sci motherboard
by shawn fang Sept. 28, 2005

Sept. 28, 2005

Hi, Does any know if LinuxBIOS can support SuperMicro p8sci motherboard? Here is the url to motherboard: http://www.supermicro.com/products/motherboard/P4/E7221/P8SCi.cfm The BIOS is hosted in socketed PLCC chip. thanks, -xun

2 1

RE: [LinuxBIOS] compiler error isolated
by Steve Magnani Sept. 28, 2005

Sept. 28, 2005

This sounds something like the bug I reported in http://openbios.org/ pipermail/linuxbios/2005-June/011782.html. I notice in the revised spd.c file there are several if/else/else... constructs. I wonder if you would have better luck using 'switch' statements - when I have problems with 'if/else' statements, I've found that recoding as 'switch' makes the problem go away. See the latest e7501 raminit code. ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include <standard.disclaimer>

1 0

Re: [LinuxBIOS] romcc - Internal compiler error: Cannot find block dominated ....
by Doug Bell Sept. 28, 2005

Sept. 28, 2005

The attached spd.c contains functions called from my raminit.c's sdram_set_spd_registers(). Raminit.c is #included into auto.c. I've tried various workarounds including putting all the code in spd.c under one function, getting rid of the device_t ctl, etc. but compilation doesn't yet work. Ideas appreciated. Thanks, dB --- Doug Bell <nxtv3(a)yahoo.com> wrote: > Beyond that, there was one version in which I simply > switched the order of declaration of variables to > make > it compile: > > // unsigned char row,col; // broken > unsigned char col,row; // works > > In another test run........ > //if ( total < c) total+=div; // failed > > if ( total < c) subtotal+=div; // was ok > total=subtotal; > > Ron / Eric - What is the best way to proceed on > this? > What info would you want? I don't think I'm doing > anything bizarre, maybe 4 chars declared, no deep > levels of functions. > > --- Doug Bell <nxtv3(a)yahoo.com> wrote: > > > I had one version of code where it failed on a > line > > like: > > if (speed==100) speed=0; > > > > but problem disappeared if I did : > > if (speed==100) speed2=0; > > > > This may have been a factor in the first reporting > > of > > the problem as well. > > > > -dB > > > > --- Doug Bell <nxtv3(a)yahoo.com> wrote: > > > > > It seems to not be related to register > allocation, > > > how > > > many layers of functions, or code size, but to > > > nested > > > if statements or variations thereof, e.g. if ( > > > (condition a) && ( condition b) ) .... > > > > > > > > > /home/dbell # uname -a > > > Linux Doug 2.6.9 #1 Tue Jan 11 17:26:41 UTC 2005 > > > i686 > > > Intel(R) Pentium(R) 4 CPU 1500MHz GenuineIntel > > > GNU/Linux > > > > > > > > > Target is via epia-sp, under development but > close > > > to > > > an alpha release with some open items. > > > > > > BTW, is there any documentation regarding what > > > limitations romcc has (e.g. multidimensional > > arrays > > > not allowed, etc )? > > > > > > Thanks, Doug > > > > > > --- ron minnich <rminnich(a)gmail.com> wrote: > > > > > > > On 9/26/05, Doug Bell <nxtv3(a)yahoo.com> wrote: > > > > > > > > > > 0x8360d58 phi Internal compiler error: > Cannot > > > > > find block dominated by 0x82ba9a8 > > > > > > > > > > Any ideas on workarounds / fixes here? Is am > I > > > > running > > > > > out of registers or some other problem? > > > > > > > > > > > > can you tell us more about the environment, > > > > uname -a > > > > distro, and linuxbios target? > > > > > > > > ron > > > > > -- > > > > LinuxBIOS mailing list > > > > LinuxBIOS(a)openbios.org > > > > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > > > > > > > > > __________________________________ > > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > http://mail.yahoo.com > > > > > > -- > > > LinuxBIOS mailing list > > > LinuxBIOS(a)openbios.org > > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > > > > > > > __________________________________ > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > http://mail.yahoo.com > > > > -- > > LinuxBIOS mailing list > > LinuxBIOS(a)openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 1

[LinuxBIOS] Re: SMP hardware question
by Adam Talbot Sept. 28, 2005

Sept. 28, 2005

Humm So AMD will not give out this info easily or free... Then let us find it. Test a system in both states (Single and Dual) and look at the differences. See if we can spoof the system into thinking it has two MP CPU's when we have two XP's in the box. The one question would be linuxbios support for the Tyan MPX board or something along those lines. -Adam Ronald G Minnich wrote: > Adam Talbot wrote: > >> Been over two years on this setup, no hardware problems, yet. The >> big question, could this be faked in the bios? > > > it's a great question. what we could do is dump the model specific > registers, on jumpered and unjumpered, and see if all that happens is > the hardware jumper turns into an MSR setting ... > > the Athlon docs are highly NDA'ed, so this would be hard to find, > that's the big issue. > > ron >

2 1

[LinuxBIOS] [Fwd: LB Summit Schedule]
by Ronald G Minnich Sept. 28, 2005

Sept. 28, 2005

Here is the sched. Notice a few things. We have left a lot of time for discussion in important areas. We need discussion leaders in: o user friendly -- how do we make this nice for users -- they can't use boot cds! How do we make linuxbios useful for the desktop? How can we make it more useful for other types of users -- e.g. embedded? What works for users? what doesn't? o user interface Should it be open firmware, a la sparc and apple? bash? efi shell? what should it be? How should people interact with linuxbios? o developer friendly -- how do we make linuxbios easier for developers what makes it hard right now? How can we improve it? what is the biggest change you'd like to see? o development model do we need a Linux-like code vetting and approval process? how do we manage patches? Who will the gatekeepers be? how do we ensure that the code base stays pure? We need ideas. o developer friendly II (more discussion) fuse the previous two sessions and try to find the right ideas. o device object model, table gen What are we going to do about: ACPI EFI tables openbios strings etc. What (if anything) needs to change in the current device model to make this all work? o automatic build and test automatic build is possible, but test? how can we do that? can people contribute systems at their site so that, when a new version comes out, we can make sure it is tested? How far can we automate the process of verifying a new release of linuxbios? Can industry help with this? OSDL? o programmer's manual How can we create a manual for new programmers? o vendor friendly What are effective and ineffective ways to work with vendors? what's the value proposition for vendors? How can we interest more vendors in linuxbios? What's missing? o efi strategy How do we address systems such as EFI? Can we, for example, find a way to run EFI modules under openbios or Linux? o N-party NDA (or NDAs in general) How do we address the issues raised by 3-, 4-, and more-way NDAS? What I'd like is people to nominate themselves to lead a discussion. Optionally, several people can nominate themselves and we'll form panels, where people put forth a position (5 mins) and then we have discussion on those ideas. So, we're looking for YOU. Please volunteer. We've come a long way, but there's more work to be done. You can make the difference. Thanks ron

2 1