>> Pro: Easy to make/get/order PCBs that fit
>> Con: Not easily accessible without setting up DRAM controller
>> (Is this the case?)
>Nope; I suggested using the I2C bus only! Only issue is
>getting the correct voltages onto the board.
Great idea - just clip it onto the SPD EEPROM. A PIC and RS232
transceiver are all you need.
> Now; this morning we had a discussion about the creation of a Programmer's
> manual. The idea is to create much more documentation for people who want
> start hacking on LinuxBIOS. People who contribute code would ideally also
> write documentation about that code - but there might be other
> too, of course.
> The consensus of the discussion was that we need a coordinator for the
> Programmer's manual. Ideally someone who is *not* yet very familiar with
> codebase, or even with low-level programming. Such a person would
> oversee the creation of the manual, encouraging (pestering?) coders to
> contribute documentation, etc. It would be a great way to dive into
> programming - the coordinator is pretty much guaranteed to learn a lot as
> this manual takes shape.
> The question is - anyone here who would be interested in taking on this
I would take this on except I am not sure what the table of contents would
On the subject dissasembly I would like to point out that (I guess) the DRAM
set-up code is probably within first 512 bytes of the BIOS, so you probably
could even dissasemble it by hand.
Has anyone other than me tried to buy from EksitData?
This is who IOSS referred me to, and they still claim to have stock on
both PMC2 and PMC4.
What, we don't do business with the Swedes now? :)
Behalf Of David H. Barr
Sent: Tuesday, November 28, 2006 2:19 PM
Subject: Re: [LinuxBIOS] Anyone bought a BIOS Savior recently?
On 11/28/06, Ed Swierk <eswierk(a)arastra.com> wrote:
> On 11/28/06, Daniel Drake <ddrake(a)brontes3d.com> wrote:
> > I'm trying to get a RD1-PMC4 BIOS savior, but am having trouble
> > places with it in stock. I even tried contacting the manufacturer
> > ordering one from Taiwan, but they don't have any available. They
> > redirected us to various resellers all around the world, but none of
> > these seem to have any stock either.
> I ordered one in September from FrozenCPU.com.
I can verify that neither PC Extreme nor FrozenCPU have any in stock
at this time. I don't personally know of any other web vendors that
carried this item.
linuxbios mailing list
I am have serious issues getting my DDR SDRAM to initialize properly.
Is there any documenation that outlines the basic steps required and
what order to do it.
The memory controller I am using is a intel 855gme. I noticed in other
intel source files lots of comments curse about the lack of
documentation, I have noticed this as well. Does this mean that I
probably won't get this to work?
I am really at a loss of what to do next. I am having a hard time
debugging this, mostly because I don't exactly know what I need to do
in the first place.
Any tips for getting ram to work correctly?
Well, I think with the couple of tips and extra documentation (I
didn't know about the JEDEC docs) I'll keep chugging away at this
until the boss says to give it up. I would much rather use LinuxBIOS
on our product than a proprietary bios.
I did try using the register values from a known BIOS. However, that
didn't work as it isn't a static configuration. The docs do outline
many registers in the memory controller, but I have notice that when I
manipulate some undocumented ones to the values seen in a working bios
I get further (although not much) in the boot, leaving me to believe
not all the registers are documented :(.
Anyway I haven't given up yet, but at the same time, I won't be too
surprised if this doesn't work out.
On 11/29/06, Drew Lundsten <drew.lundsten(a)ccpu.com> wrote:
> This is depressing, definitely. You did try copying the register values
> seen in a booted board?
> And I assume you do have the datasheet that's on Intel's public site? At
> least the registers are defined there, although it doesn't give you the
> sequence needed to use them optimally.
> Drew Lundsten <drew.lundsten(a)ccpu.com> +1 858-882-8828/619-895-1764 cell
> Continuous Computing Corporation, 9380 Carroll Park Dr, San Diego 92121
> -----Original Message-----
> From: linuxbios-bounces+drew.lundsten=ccpu.com(a)linuxbios.org
> [mailto:email@example.com] On
> Behalf Of Jon Dufresne
> Sent: Wednesday, November 29, 2006 5:12 PM
> To: ron minnich
> Cc: linuxbios(a)linuxbios.org
> Subject: Re: [LinuxBIOS] Very confused about ram initialization
> Well that is a bummer, I was having fun (accompanied by frustration)
> trying to get this to work. Thanks for all the help I received up to
> this point.
> On 11/29/06, ron minnich <rminnich(a)gmail.com> wrote:
> > I hate to say it, but you are going to probably have to give up on
> > that chipset absent docs. I have the "DOCS" as intel ships them from
> > developer.intel.com, and, unlike what you could get in 1999, the
> > current set of docs are totally worthless for writing a BIOS. I am
> > told this is intentional. I have had it put to me that this policy
> > simplifies EFI lockin -- no competition.
> > Sorry
> > ron
> linuxbios mailing list
We are working on getting LB going on a platform with 2 VGA devices.
One is an "on-board" ATI ES1000, meaning it is soldered down, without
a ROM attached to it (it is usually built into the platform BIOS
The second VGA device is a plug in PCI card (XGI Z9S).
The PCI slot is on the same bus as the "on-board" graphics controller.
We would like to use the plug-in card as the VGA interface.
We tried the "off" option (in Config.lb) for the on-board PCI device,
but it still tries to load it as the VGA console (it does not work,
since there is no ROM).
We want the plugin card's option ROM to be run, and the "on-board"
controller should not be used. What is the correct way to achive what
we want? Basically, a way to hide the ATI controller would be