[LinuxBIOS] Read SPD issue

[Joseph Smith]

Hello,
I am having a problem with raminit.c reading SPD data. When I use the  
smbus_read_byte function it is only returning a value of 0xFF.

smbus_read_byte(ctrl->channel0[i], 2)

No  matter what SPD Byte I try I am just getting 0xFF. What could this  
be? Please help.

On another note I am finally getting console output on the i82830 chipset:-)
Getting closer....

Thanks - Joe

[Stefan Reinauer]

Joseph Smith wrote:
> Hello,
> I am having a problem with raminit.c reading SPD data. When I use the  
> smbus_read_byte function it is only returning a value of 0xFF.
>
> smbus_read_byte(ctrl->channel0[i], 2)

your i2c bus functions of the southbridge code don't work.

[Joseph Smith]

Quoting Stefan Reinauer :
> Joseph Smith wrote:
> > Hello,
> > I am having a problem with raminit.c reading SPD data. When I use the
> > smbus_read_byte function it is only returning a value of 0xFF.
> >
> > smbus_read_byte(ctrl->channel0[i], 2)
>
> your i2c bus functions of the southbridge code don't work.

Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx  
src code.
Corey, mabe you could shed some light on this?? Here is my serial  
console output, where it says "SPD is ff, ff, ff, ff" I just tried a  
bunch of different SPD bytes to see the return values.

LinuxBIOS-2.0.0.0Fallback Sat Aug 11 01:30:14 EDT 2007 starting...
Setting Initial Registers....
Initial registers have been set.
SPD is ff, ff, ff, ff
No DIMM found in slot 00, Setting DRA to 0xFF
DRA 70 has been set to ff
SPD is ff, ff, ff, ff
No DIMM found in slot 01, Setting DRA to 0xFF
DRA 71 has been set to ff
RAM Enable 1: Apply NOP
     Sending RAM command 0x00000010 to 0x00000000
RAM Enable 2: Precharge all
     Sending RAM command 0x00000020 to 0x00000000
RAM Enable 3: CBR
     Sending RAM command 0x000000
RAM Enable 4: Mode register set
     Sending RAM command 0x00000030 to 0x00000000
RAM Enable 5: Normal operation
     Sending RAM command 0x20000170 to 0x00000000
Northbridge following SDRAM init:
PCI: 00:00.00
00: 86 80 75 35 06 00 10 20 04 00 00 06 00 00 00 00
10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
40: 09 00 05 01 00 00 00 00 00 00 00 00 02 28 00 0e
50: 72 a0 00 00 00 00 00 00 00 30 33 33 33 33 33
60: 00 00 04 04 00 00 00 00 00 00 00 00 00 00 00 00
70: ff ff ff ff 00 00 00 00 10 00 00 00 70 01 00 20
80: 00 00 00 00 00 00 00 00 00 70 d7 d4 00 00 00 00
90: 02 38 00 01 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 54 0e 41 a2 99 01 00 c0 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 fc 14 00 00
f0: 11 11 01 00 00 00 0d 05 37 d6 30 d3 1f cf 1e
Copying LinuxBIOS to RAM.
Jumping to LinuxBIOS.
SMBus controller enabled

Thanks - Joe

[Stefan Reinauer]

* Joseph Smith  [070811 18:52]:
> Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx  
> src code.
> Corey, mabe you could shed some light on this?? Here is my serial  
> console output, where it says "SPD is ff, ff, ff, ff" I just tried a  
> bunch of different SPD bytes to see the return values.

Hm. maybe the spd roms are on a different position then. I think Corey's
code is known to work. They're usually at 0x50...0x53 but that may be
different on any other board.

[Joseph Smith]

Quoting Stefan Reinauer :
> Joseph Smith  [070811 18:52]:
> > Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx
> > src code.
> > Corey, mabe you could shed some light on this?? Here is my serial
> > console output, where it says "SPD is ff, ff, ff, ff" I just tried a
> > bunch of different SPD bytes to see the return values.
>
> Hm. maybe the spd roms are on a different position then. I think Corey's
> code is known to work. They're usually at 0x50...0x53 but that may be
> different on any other board.

How would I go about finding out what it is on my board??

Thanks - Joe

[Corey Osgood]

Stefan Reinauer wrote:
> Joseph Smith  [070811 18:52]:
> > Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx  
> > src code.
> > Corey, mabe you could shed some light on this?? Here is my serial  
> > console output, where it says "SPD is ff, ff, ff, ff" I just tried a  
> > bunch of different SPD bytes to see the return values.
>
> Hm. maybe the spd roms are on a different position then. I think Corey's
> code is known to work. They're usually at 0x50...0x53 but that may be
> different on any other board.

Yeah, the code works for me, and was a hack up of the other 82801s, so
it should work for just about any. Can you do me a favor and check that
the smbus device is located at device 0x1f (ie 31) function 3? That was
one big assumption I made, I checked most of the datasheets but not all
of them, and datasheets do lie. I did throw in a check just as a
failsafe, but that may not have worked either. Also check your factory
bios's smbus IO base, it should be programmed at d31f3 rx20-21, and will
have an extra 1 at the end. If that's not 0x0f00, then try plugging it
in as SMBUS_IO_BASE in i82801xx.h.

The current code also makes no attempt to do give any sort of warning if
an smbus timeout/error occurs. It was something that I wanted to do, but
other things came up. You could probably drop in some debugging info
there, as the functions already do return negative values in case of an
error. The other thought is, run smbus_enable before enabling
serial/console, and also try to force a full smbus dump using the
debug.c that I left in with the i82810 (oops, meant to move that). It
may be that your smbus needs a little time to initialize, if you're
smbus dump starts pulling good values after the first few transactions,
this is the case. It it is, let me know and I can take care of it, and
for the time being just do an smbus dump before attempting to do ram init.

Last thought is, make sure your dimm actually has spd. I've never seen a
dimm that didn't, but that doesn't mean they don't exist, especially
with older sdram, and doesn't that board use so-dimms? lm_sensors
dimms-detect.pl should be able to tell you if there is spd info to be
found, and also the location of the spd. If I get some time, create a
little program to dump the spd info from userspace, but dimms-detect.pl
already does pretty much the same thing, except it translates it into
dimm info (which is quite annoying if that's not what you want).

Good luck!
Corey

[Joseph Smith]

Quoting Corey Osgood :
> Stefan Reinauer wrote:
> > Joseph Smith  [070811 18:52]:
> > > Hmm, I have an ICH4 i82801db southbridge and am using Corey's i82801xx
> > > src code.
> > > Corey, mabe you could shed some light on this?? Here is my serial
> > > console output, where it says "SPD is ff, ff, ff, ff" I just tried a
> > > bunch of different SPD bytes to see the return values.
> >
> > Hm. maybe the spd roms are on a different position then. I think Corey's
> > code is known to work. They're usually at 0x50...0x53 but that may be
> > different on any other board.
>
> Yeah, the code works for me, and was a hack up of the other 82801s, so
> it should work for just about any. Can you do me a favor and check that
> the smbus device is located at device 0x1f (ie 31) function 3? That was
> one big assumption I made, I checked most of the datasheets but not all
> of them, and datasheets do lie. I did throw in a check just as a
> failsafe, but that may not have worked either. Also check your factory
> bios's smbus IO base, it should be programmed at d31f3 rx20-21, and will
> have an extra 1 at the end. If that's not 0x0f00, then try plugging it
> in as SMBUS_IO_BASE in i82801xx.h.

Yep datasheet says SMBus Controller - Bus 0:Device 31:Function 3
> The current code also makes no attempt to do give any sort of warning if
> an smbus timeout/error occurs. It was something that I wanted to do, but
> other things came up. You could probably drop in some debugging info
> there, as the functions already do return negative values in case of an
> error. The other thought is, run smbus_enable before enabling
> serial/console, and also try to force a full smbus dump using the
> debug.c that I left in with the i82810 (oops, meant to move that). It
> may be that your smbus needs a little time to initialize, if you're
> smbus dump starts pulling good values after the first few transactions,
> this is the case. It it is, let me know and I can take care of it, and
> for the time being just do an smbus dump before attempting to do ram init.

How would I call debug.c and from what file?

I noticed in auto.c there is a dump_spd_registers(&memctrl[0]);  
commented out. Could I try this to dump the SPD data??

Thanks - Joe

[Joseph Smith]

Quoting Joseph Smith :
> Quoting Corey Osgood :
> > Can you do me a favor and check that
> > the smbus device is located at device 0x1f (ie 31) function 3?
>
> Yep datasheet says SMBus Controller - Bus 0:Device 31:Function 3

So, I tried the
    dump_spd_registers(&memctrl[0]);
    dump_smbus_registers();
from debug.c and here is the results:
-----------------
LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting...

dimm: 00.0: 50
00: bad device

dimm: 01.0: 51
00: bad device

smbus: 69
----------------

HELP???

Thanks - Joe

[Corey Osgood]

Joseph Smith wrote:
> Quoting Joseph Smith :
> > Quoting Corey Osgood :
> > > Can you do me a favor and check that
> > > the smbus device is located at device 0x1f (ie 31) function 3?
> >
> > Yep datasheet says SMBus Controller - Bus 0:Device 31:Function 3
>
> So, I tried the
>     dump_spd_registers(&memctrl[0]);
>     dump_smbus_registers();
> from debug.c and here is the results:
>
> LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting...
>
> dimm: 00.0: 50
> 00: bad device
>
> dimm: 01.0: 51
> 00: bad device
> smbus: 69
>
> HELP???
>
> Thanks - Joe

In the attached debug.c is probe_spd_rom(). If your device has spd, it
should be able to find it. You can use the whole file and #include it
into the southbridge or mainboard or even northbridge code, or just copy
and paste it into somewhere else. Call it whereever you called
dump_spd_registers from. Note that it's not magic (yet), it won't
actually use found spd locations, you'll have to do that manually. Also,
what make/model is your dimm and board (I know you've told me, but my
memory is terrible)? The datasheets may have more info, if they're
available.

-Corey

[Joseph Smith]

Quoting Corey Osgood :
> > So, I tried the
> >     dump_spd_registers(&memctrl[0]);
> >     dump_smbus_registers();
> > from debug.c and here is the results:
> >
> > LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting...
> >
> > dimm: 00.0: 50
> > 00: bad device
> >
> > dimm: 01.0: 51
> > 00: bad device
> > smbus: 69
> >
> > HELP???
> >
> > Thanks - Joe
>
> In the attached debug.c is probe_spd_rom(). If your device has spd, it
> should be able to find it. You can use the whole file and #include it
> into the southbridge or mainboard or even northbridge code, or just copy
> and paste it into somewhere else. Call it whereever you called
> dump_spd_registers from. Note that it's not magic (yet), it won't
> actually use found spd locations, you'll have to do that manually. Also,
> what make/model is your dimm and board (I know you've told me, but my
> memory is terrible)? The datasheets may have more info, if they're
> available.
>
> -Corey

So I tried the probe_spd_rom() and it comes back with "bad device".  
Which I expected because this line in the function

status = smbus_read_byte(i, 0);

is my whole problem:( The smbus_read_byte function is what is not  
working in raminit.c so why would it work when called from auto.c?? No  
matter what byte I try to read it just comes back with a 0xFF ??

Here is a recap of the hardware:
RCA RM4100 Embedded Set-top-box
Low Voltage Intel® Celeron® processor (Micro-FC-BGA) 733MHz
128MB PC133 SDRAM on board (Embedded) (In Socket2)
Intel i82830 (i830M4) Northbridge (Developing)
Intel i82801DB Southbridge (Using i82801xx)
SMSC lpc47m192 SuperIO (Using smscsuperio)

This is making me crazy, I'm so confused?

Thanks - Joe

[Corey Osgood]

Joseph Smith wrote:
> Quoting Corey Osgood :
> > > So, I tried the
> > >     dump_spd_registers(&memctrl[0]);
> > >     dump_smbus_registers();
> > > from debug.c and here is the results:
> > >
> > > LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting...
> > >
> > > dimm: 00.0: 50
> > > 00: bad device
> > >
> > > dimm: 01.0: 51
> > > 00: bad device
> > > smbus: 69
> > >
> > > HELP???
> > >
> > > Thanks - Joe
> >
> > In the attached debug.c is probe_spd_rom(). If your device has spd, it
> > should be able to find it. You can use the whole file and #include it
> > into the southbridge or mainboard or even northbridge code, or just copy
> > and paste it into somewhere else. Call it whereever you called
> > dump_spd_registers from. Note that it's not magic (yet), it won't
> > actually use found spd locations, you'll have to do that manually. Also,
> > what make/model is your dimm and board (I know you've told me, but my
> > memory is terrible)? The datasheets may have more info, if they're
> > available.
> >
> > -Corey
>
> So I tried the probe_spd_rom() and it comes back with "bad device".

That's because I messed up and forgot to remove the break, so after
checking the first location, it left the function. It should have (quite
literally) filled your screen with bad device messages, with one message
saying it found an spd rom. In hindsight, it was pretty damn stupid of
me to leave that message there. Try the attached version, it should be
fixed and is even simpler now.
> Which I expected because this line in the function
>
> status = smbus_read_byte(i, 0);
>
> is my whole problem:( The smbus_read_byte function is what is not
> working in raminit.c so why would it work when called from auto.c?? No
> matter what byte I try to read it just comes back with a 0xFF ??
>
> Here is a recap of the hardware:
> RCA RM4100 Embedded Set-top-box
> Low Voltage Intel® Celeron® processor (Micro-FC-BGA) 733MHz
> 128MB PC133 SDRAM on board (Embedded) (In Socket2)
> Intel i82830 (i830M4) Northbridge (Developing)
> Intel i82801DB Southbridge (Using i82801xx)
> SMSC lpc47m192 SuperIO (Using smscsuperio)
>
> This is making me crazy, I'm so confused?
>
> Thanks - Joe

Essentially what seems to be going on here is the smbus is looking for
data, but it can't find the spd rom. The "bad device" error is trying to
say bad spd device, or at least that's the hope. Better parsing of the
error code (-1 vs -2, etc) could tell us more, but that's the next step
(mainly cuz I'm almost asleep right now). This is exploring stepan's
theory that the device isn't located at the standard 0x50, etc, by
checking the first byte (byte 0) at every address (denoted by i),
through the first 256, and throwing up a message if it finds anything.
Note that just because there's a device found it's not necessarily the
spd rom, but there's a decent chance of it. The other possible problem
is that, since your ram is embedded, there isn't any spd rom at all...

-Corey

[Joseph Smith]

Quoting Corey Osgood :
> Joseph Smith wrote:
> > Quoting Corey Osgood :
> > > > So, I tried the
> > > >     dump_spd_registers(&memctrl[0]);
> > > >     dump_smbus_registers();
> > > > from debug.c and here is the results:
> > > >
> > > > LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting...
> > > >
> > > > dimm: 00.0: 50
> > > > 00: bad device
> > > >
> > > > dimm: 01.0: 51
> > > > 00: bad device
> > > > smbus: 69
> > > >
> > > > HELP???
> > > >
> > > > Thanks - Joe
> > >
> > > In the attached debug.c is probe_spd_rom(). If your device has spd, it
> > > should be able to find it. You can use the whole file and #include it
> > > into the southbridge or mainboard or even northbridge code, or just copy
> > > and paste it into somewhere else. Call it whereever you called
> > > dump_spd_registers from. Note that it's not magic (yet), it won't
> > > actually use found spd locations, you'll have to do that manually. Also,
> > > what make/model is your dimm and board (I know you've told me, but my
> > > memory is terrible)? The datasheets may have more info, if they're
> > > available.
> > >
> > > -Corey
> >
> > So I tried the probe_spd_rom() and it comes back with "bad device".
>
> That's because I messed up and forgot to remove the break, so after
> checking the first location, it left the function. It should have (quite
> literally) filled your screen with bad device messages, with one message
> saying it found an spd rom. In hindsight, it was pretty damn stupid of
> me to leave that message there. Try the attached version, it should be
> fixed and is even simpler now.
> > Which I expected because this line in the function
> >
> > status = smbus_read_byte(i, 0);
> >
> > is my whole problem:( The smbus_read_byte function is what is not
> > working in raminit.c so why would it work when called from auto.c?? No
> > matter what byte I try to read it just comes back with a 0xFF ??
> >
> > Here is a recap of the hardware:
> > RCA RM4100 Embedded Set-top-box
> > Low Voltage Intel® Celeron® processor (Micro-FC-BGA) 733MHz
> > 128MB PC133 SDRAM on board (Embedded) (In Socket2)
> > Intel i82830 (i830M4) Northbridge (Developing)
> > Intel i82801DB Southbridge (Using i82801xx)
> > SMSC lpc47m192 SuperIO (Using smscsuperio)
> >
> > This is making me crazy, I'm so confused?
> >
> > Thanks - Joe
>
> Essentially what seems to be going on here is the smbus is looking for
> data, but it can't find the spd rom. The "bad device" error is trying to
> say bad spd device, or at least that's the hope. Better parsing of the
> error code (-1 vs -2, etc) could tell us more, but that's the next step
> (mainly cuz I'm almost asleep right now). This is exploring stepan's
> theory that the device isn't located at the standard 0x50, etc, by
> checking the first byte (byte 0) at every address (denoted by i),
> through the first 256, and throwing up a message if it finds anything.
> Note that just because there's a device found it's not necessarily the
> spd rom, but there's a decent chance of it. The other possible problem
> is that, since your ram is embedded, there isn't any spd rom at all...
>
> -Corey

Ok, so I tried this and it just returns a "SPD located at 0x69" is  
this correct?
It is much different than the standard 0x50, etc. Is this because it  
is embedded?? Thanks for all help.

Thanks - Joe

[Corey Osgood]

Joseph Smith wrote:
> Ok, so I tried this and it just returns a "SPD located at 0x69" is
> this correct?
> It is much different than the standard 0x50, etc. Is this because it
> is embedded?? Thanks for all help.
>
> Thanks - Joe

I'd do an dump first, just to make sure that it really is an spd rom and
not some other device on the smbus. Or else do a dump and try to use it
in the same run, can't really hurt.

-Corey

[Joseph Smith]

Quoting Corey Osgood :
> Joseph Smith wrote:
> > Ok, so I tried this and it just returns a "SPD located at 0x69" is
> > this correct?
> > It is much different than the standard 0x50, etc. Is this because it
> > is embedded?? Thanks for all help.
> >
> > Thanks - Joe
>
> I'd do an dump first, just to make sure that it really is an spd rom and
> not some other device on the smbus. Or else do a dump and try to use it
> in the same run, can't really hurt.
>
> -Corey

OK, I think I know what is going on here. Here is a dump of my smbus  
with the legacy bios.

0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          XX XX XX XX XX XX XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX UU XX XX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX 69 XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX

SPD would show up at 0x50 or 0x51 right? It doesn't appear there is  
SPD on the on-board memory.I only show items at 0x2d (sensor) and 0x69  
(clock chip).

So where do you think I should go from here? I could set up a *.c file  
in the mainboard directory to call a function to manually set the  
correct settings for socket2 (I know what the settings are supposed to  
be) after raminit.c dynamicly configures the register but before the  
sdram_enable function is called. It should be fairly simple to do and  
call from auto.c. What do you think?

Thanks - Joe

[Stefan Reinauer]

* Joseph Smith  [070812 19:49]:
> SPD would show up at 0x50 or 0x51 right? It doesn't appear there is SPD on 
> the on-board memory.I only show items at 0x2d (sensor) and 0x69 (clock 
> chip).

Are these devices (sensor, clock chip) identified? Any chance there is
an i2c mux somewhere?

[Joseph Smith]

Quoting Stefan Reinauer :
> Joseph Smith  [070812 19:49]:
> > SPD would show up at 0x50 or 0x51 right? It doesn't appear there is SPD on
> > the on-board memory.I only show items at 0x2d (sensor) and 0x69 (clock
> > chip).
>
> Are these devices (sensor, clock chip) identified? Any chance there is
> an i2c mux somewhere?

Not sure, what is the typical address for a i2c mux? I can probe for  
it. The only other device i think there is, is the on-board tv-out  
chip, and I think that is at 0x88. How come lm-sensors default is to  
only probe between address range 0x03-0x77?

Thanks - Joe

[Feng, Libo]

Generally, I2C mux has some external pins to set its address. In my Tyan S3992, the address is 0x71, so the function activate_spd_rom is called before accessing SPD.

Best Regards

??? Feng Libo @ AMD  Ext: 20906
Mobile Phone: [phone]
Office Phone: [phone]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Joseph Smith
Sent: Monday, August 13, 2007 2:09 AM
To: Stefan Reinauer
Cc: Corey Osgood; [e-mail]
Subject: Re: [LinuxBIOS] Read SPD issue

Quoting Stefan Reinauer :
> Joseph Smith  [070812 19:49]:
> > SPD would show up at 0x50 or 0x51 right? It doesn't appear there is 
> > SPD on the on-board memory.I only show items at 0x2d (sensor) and 
> > 0x69 (clock chip).
>
> Are these devices (sensor, clock chip) identified? Any chance there is 
> an i2c mux somewhere?

Not sure, what is the typical address for a i2c mux? I can probe for it. The only other device i think there is, is the on-board tv-out chip, and I think that is at 0x88. How come lm-sensors default is to only probe between address range 0x03-0x77?

Thanks - Joe

[Robert Vogel]

Simple questions. I hope you don't mind. The LinuxBios Product page does not 
seem to show a motherboard for a desktop machine.

A few months ago I read that LinuxBios could run on the GA-M57SLI-S4 
motherboard.

There are some problems 
(http://linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial) though. To 
change the BIOS requires soldering a new socket onto the board and, even at 
that, there is a possibility that the board could be ruined in the process. 
I don't have the skills required to modify the board, so it is a 
modification that I need done by someone else. Would you recommend this 
machine for desktop use ?

Is there a desktop AMD 64 Linux machine with LinuxBios available from a good 
commercial vendor ?

Thanks in advance,
Bob

[LinuxBIOS] GA M57SLI-S4 questions [was: Read SPD issue]

[Corey Osgood]

Please create a new thread for new questions.

Robert Vogel wrote:
> Simple questions. I hope you don't mind. The LinuxBios Product page
> does not seem to show a motherboard for a desktop machine.
>
> A few months ago I read that LinuxBios could run on the GA-M57SLI-S4
> motherboard.
>
> There are some problems
> (http://linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial) though. To
> change the BIOS requires soldering a new socket onto the board and,
> even at that, there is a possibility that the board could be ruined in
> the process. I don't have the skills required to modify the board, so
> it is a modification that I need done by someone else. Would you
> recommend this machine for desktop use ?
>
> Is there a desktop AMD 64 Linux machine with LinuxBios available from
> a good commercial vendor ?

http://www.linuxbios.org/Supported_Motherboards <- look at
desktops/workstations, the first section.
> Thanks in advance,
> Bob