> 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
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>
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.
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
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>
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
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
>
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
