[LinuxBIOS] flashrom on ga 2761gxdk

[ron minnich]

It now finds the part, and gets ready to program it, but exits
instantly without doing anything. I think this is the culprit:
void generic_spi_page_program(int block, uint8_t *buf, uint8_t *bios)
{
        if (it8716f_flashport)
                it8716f_spi_page_program(block, buf, bios);
}

i.e. the flashport is not set. So, before I dig too far into this, is
there some simple thing I should look at to get flashrom working on
this board?

Also, seems to me it's a pretty serious error if this can not be
determined, ... anyone mind if I add an error message? right now it
exits with no error, having done no work :-)

thanks

ron

[Carl-Daniel Hailfinger]

On 09.01.2008 07:36, ron minnich wrote:
> It now finds the part, and gets ready to program it, but exits
> instantly without doing anything. I think this is the culprit:
> void generic_spi_page_program(int block, uint8_t *buf, uint8_t *bios)
> {
>         if (it8716f_flashport)
>                 it8716f_spi_page_program(block, buf, bios);
> }
>
> i.e. the flashport is not set. So, before I dig too far into this, is
> there some simple thing I should look at to get flashrom working on
> this board?

Yes, set the flash port to a reasonable value during BIOS init. Since
all versions of the board will have that flash translation chip, you
probably can do that unconditionally in Config.lb instead of the
boardrevision-dependent way I did it for the GA-M57SLI. Code follows:
tmp = pnp_read_config(SERIAL_DEV, IT8716F_CONFIG_REG_SWSUSP);
/* Enable writing to serial flash. */
pnp_write_config(SERIAL_DEV, IT8716F_CONFIG_REG_SWSUSP, tmp | 0x10);
pnp_set_logical_device(GPIO_DEV);
/* Set Serial Flash interface to 0x0820 */
pnp_write_config(GPIO_DEV, 0x64, 0x08);
pnp_write_config(GPIO_DEV, 0x65, 0x20);

Or the Config.lb way:
chip superio/ite/it8716f
  device pnp 2e.7 on #  GPIO, SPI flash
    # Software Suspend and Flash Interface, see IT8716F datasheet,
section 8.3.7
    # FIXME: make sure this enables the right pin and the right segments
    irq 0x24 = 0x1a
    # Serial Flash I/O (SPI only, the thing flashrom calls
it8716f_flashport)
    io 0x64 = 0x820
  end
> Also, seems to me it's a pretty serious error if this can not be
> determined, ... anyone mind if I add an error message? right now it
> exits with no error, having done no work :-)

Later, we will have more of these if style statements. Suggestion (rough
cut-n-paste, whitespace damaged, may need a change of return types):
{

if (it8716f_flashport)
                return it8716f_spi_page_program(block, buf, bios);
    printf("generic_spi_page_program called, but no machine specific program routine available!\n");
    return;
}

Regards,
Carl-Daniel

[ron minnich]

On Jan 9, 2008 3:28 AM, Carl-Daniel Hailfinger
 wrote:
> Yes, set the flash port to a reasonable value during BIOS init.

This is under the factory BIOS. I will dig a little deeper. I could
not at first see why it would not be set. I hope to have more time
tonight.
> {
>     if (it8716f_flashport)
>             return it8716f_spi_page_program(block, buf, bios);
>     printf("generic_spi_page_program called, but no machine specific program routine available!\n");
>     return;
>
> }

you'll get this message many times. I think it needs to be done in an
outer function. I will dig a bit and try to see what to do.

thanks

ron

[Carl-Daniel Hailfinger]

On 09.01.2008 17:03, ron minnich wrote:
> On Jan 9, 2008 3:28 AM, Carl-Daniel Hailfinger
>  wrote:
> > Yes, set the flash port to a reasonable value during BIOS init.
>
> This is under the factory BIOS. I will dig a little deeper. I could
> not at first see why it would not be set. I hope to have more time
> tonight.

That's easy. You don't need that port set unless you want to write to
flash. Try the patch below and please post full verbose log.

Index: flashrom-ron/spi.c
===================================================================
--- flashrom-ron/spi.c	(Revision 3036)
+++ flashrom-ron/spi.c	(Arbeitskopie)
@@ -139,6 +139,8 @@
    	printf("serial flash pin %i\n",	(tmp & 1 << 5) ? 87 : 29);
    	/* LDN 0x7, reg 0x64/0x65 */
    	regwrite(port, 0x07, 0x7);
+		regwrite(port, 0x64, 0x08);
+		regwrite(port, 0x65, 0x20);
    	flashport = regval(port, 0x64) << 8;
    	flashport |= regval(port, 0x65);
    }

Regards,
Carl-Daniel

[ron minnich]

verbose output attached. With the patch, it no longer finds the flash part.

I will look at this too, but I thought you might find it useful

ron

[ron minnich]

Turns out, with a few debug prints added, I am more confused than I realized.

The port is set to a reasonable value and it is indeed trying to flash
(port is 0a30).

It gets right into the page programming. The flash is mmap'ed. It's
doing all the right things, but programming time appears to be zero. I
put some prints in and this part:

while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
    	usleep(1000);

completes instantly.

So, not sure what to go after. Morgan, is the ITE8761F the part that
should let me program SPI? Is there any mainboard-specific trick to
making programming of SPI work?

thanks

ron

[Carl-Daniel Hailfinger]

On 10.01.2008 05:16, ron minnich wrote:
> verbose output attached. With the patch, it no longer finds the flash part.

Ah ok, I misunderstood. I thought the routine was unable to find the
port. Looking at the log, we see:
> LPC write to serial flash disabled

Which naturally means all writes will never reach the chip. Try the
patch below:

Enable LPC write cycle to SPI write cycle translation for IT8716F.

Signed-off-by: Carl-Daniel Hailfinger

Index: flashrom-ron/spi.c
===================================================================
--- flashrom-ron/spi.c	(Revision 3036)
+++ flashrom-ron/spi.c	(Arbeitskopie)
@@ -136,6 +136,11 @@
    		0xFFF80000, 0xFFFEFFFF, (tmp & 1 << 3) ? "en" : "dis");
    	printf("LPC write to serial flash %sabled\n",
    		(tmp & 1 << 4) ? "en" : "dis");
+		if (!(tmp & 1 << 4)) {
+			printf("Force enabling LPC write to serial flash\n");
+			tmp |= 1 << 4;
+			regwrite(port, 0x24, tmp);
+		}
    	printf("serial flash pin %i\n",	(tmp & 1 << 5) ? 87 : 29);
    	/* LDN 0x7, reg 0x64/0x65 */
    	regwrite(port, 0x07, 0x7);
> Serial flash segment 0xfffe0000-0xffffffff enabled
> Serial flash segment 0x000e0000-0x000fffff enabled
> Serial flash segment 0xffee0000-0xffefffff disabled
> Serial flash segment 0xfff80000-0xfffeffff enabled

That's the next problem. Do you see the gaps and overlaps between
ranges? It seems it is entirely impossible to map flash to the
0xfff00000-0xfff7ffff range. Then again, this might be a data sheet bug.
I'm reasonably sure a dump of the 1 MByte chip (if that chip has
different contents in the upper and lower 512 kByte) will clear up any
misunderstandings.

Regards,
Carl-Daniel

[Carl-Daniel Hailfinger]

Btw, the block lock bits are all set, so even if you manage to convince
the SPI translation to map more than 512 KByte and even if you use
enable LPC-to-SPI writes, you will still flash nothing. Try this for
better lock bit printing:

Enable LPC write cycle to SPI write cycle translation for IT8716F.
Print detailed status register information for SST25VF series flash.

Signed-off-by: Carl-Daniel Hailfinger

Index: flashrom-ron/spi.c
===================================================================
--- flashrom-ron/spi.c	(Revision 3036)
+++ flashrom-ron/spi.c	(Arbeitskopie)
@@ -136,6 +136,11 @@
    		0xFFF80000, 0xFFFEFFFF, (tmp & 1 << 3) ? "en" : "dis");
    	printf("LPC write to serial flash %sabled\n",
    		(tmp & 1 << 4) ? "en" : "dis");
+		if (!(tmp & 1 << 4)) {
+			printf("Force enabling LPC write to serial flash\n");
+			tmp |= 1 << 4;
+			regwrite(port, 0x24, tmp);
+		}
    	printf("serial flash pin %i\n",	(tmp & 1 << 5) ? 87 : 29);
    	/* LDN 0x7, reg 0x64/0x65 */
    	regwrite(port, 0x07, 0x7);
@@ -323,7 +328,8 @@
    switch (flash->manufacture_id) {
    case ST_ID:
    case MX_ID:
-		if ((flash->model_id & 0xff00) == 0x2000)
+		if (((flash->model_id & 0xff00) == 0x2000) ||
+		    ((flash->model_id & 0xff00) == 0x2500))
    		generic_spi_prettyprint_status_register_st_m25p(status);
    	break;
    }

[Carl-Daniel Hailfinger]

Ron?

On 10.01.2008 13:32, Carl-Daniel Hailfinger wrote:
> Btw, the block lock bits are all set, so even if you manage to convince
> the SPI translation to map more than 512 KByte and even if you use
> enable LPC-to-SPI writes, you will still flash nothing. Try this for
> better lock bit printing:
>
> Enable LPC write cycle to SPI write cycle translation for IT8716F.
> Print detailed status register information for SST25VF series flash.
>
> Signed-off-by: Carl-Daniel Hailfinger
> Index: flashrom-ron/spi.c
>
> --- flashrom-ron/spi.c	(Revision 3036)
> +++ flashrom-ron/spi.c	(Arbeitskopie)
> @@ -136,6 +136,11 @@
>    		0xFFF80000, 0xFFFEFFFF, (tmp & 1 << 3) ? "en" : "dis");
>    	printf("LPC write to serial flash %sabled\n",
>    		(tmp & 1 << 4) ? "en" : "dis");
> if (!(tmp & 1 << 4)) {
> 	printf("Force enabling LPC write to serial flash\n");
> 	tmp |= 1 << 4;
> 	regwrite(port, 0x24, tmp);
> }
> printf("serial flash pin %i\n",	(tmp & 1 << 5) ? 87 : 29);
> /* LDN 0x7, reg 0x64/0x65 */
> regwrite(port, 0x07, 0x7);
>
> @@ -323,7 +328,8 @@
>    switch (flash->manufacture_id) {
>    case ST_ID:
>    case MX_ID:
> if ((flash->model_id & 0xff00) == 0x2000)
> if (((flash->model_id & 0xff00) == 0x2000) ||
>     ((flash->model_id & 0xff00) == 0x2500))
> generic_spi_prettyprint_status_register_st_m25p(status);
> break;
> }

[ron minnich]

On Jan 22, 2008 8:27 AM, Carl-Daniel Hailfinger
 wrote:
> Ron?

See my other note, this works but verify did not, which I think you
also just fixed.

The board still does not boot or even POST for me. I am wishing I had
some 512kB parts.

ron

[Carl-Daniel Hailfinger]

On 22.01.2008 17:37, ron minnich wrote:
> On Jan 22, 2008 8:27 AM, Carl-Daniel Hailfinger
>  wrote:
> > Ron?
>
> See my other note, this works but verify did not, which I think you
> also just fixed.

Yes, but status register printing for your chips was in that patch as
well and this is not yet merged. It is entirely possible that we have to
mess with these registers in creative ways.
> The board still does not boot or even POST for me. I am wishing I had
> some 512kB parts.

Hm. That's unfortunate. Not even if you start with a cold boot? Flashrom
may confuse the IT8716F in a way that prevents booting from some slow
SPI chips.

Maybe Morgan Tsai has an image which you can flash with the usual
"replicate the small image n times until flash is full" technique?

Regards,
Carl-Daniel

[ron minnich]

OK, with 3073, something went worse.

Last night, I was flashing just fine. As of today, it's not id'ing it
and it is reading 0xff back for that pass. I am attaching a failed
(first) and successfull on the 4mbit part (second half) of the file.

I'm trying to get to the point of trying to figure out if this 2M part
will ever work on this board. I am beginning to have my doubts.

My only remaining differences are this:

Index: spi.c
===================================================================
--- spi.c       (revision 3073)
+++ spi.c       (working copy)
@@ -155,6 +155,12 @@
                        0xFFF80000, 0xFFFEFFFF, (tmp & 1 << 3) ? "en" : "dis");
                printf("LPC write to serial flash %sabled\n",
                        (tmp & 1 << 4) ? "en" : "dis");
+               if (!(tmp & 1 << 4)) {
+                       printf("Force enabling LPC write to serial flash\n");
+                       tmp |= 1 << 4;
+                       regwrite(port, 0x24, tmp);
+               }
+               printf("serial flash pin %i\n", (tmp & 1 << 5) ? 87 : 29);
                printf("serial flash pin %i\n", (tmp & 1 << 5) ? 87 : 29);
                /* LDN 0x7, reg 0x64/0x65 */
                regwrite(port, 0x07, 0x7);
@@ -375,7 +381,8 @@
        switch (flash->manufacture_id) {
        case ST_ID:
        case MX_ID:
-               if ((flash->model_id & 0xff00) == 0x2000)
+               if (((flash->model_id & 0xff00) == 0x2000) ||
+                       ((flash->model_id & 0xff00) == 0x2500))
                        spi_prettyprint_status_register_st_m25p(status);
                break;
        case SST_ID:

[Carl-Daniel Hailfinger]

On 23.01.2008 05:25, ron minnich wrote:
> OK, with 3073, something went worse.

r3073 and r3072 did not have any changes affecting you.
> Last night, I was flashing just fine. As of today, it's not id'ing it
> and it is reading 0xff back for that pass.

Maybe the port it reads from gives 0xff for every read? Cause could be
- a LPC misconfiguration (port not passed through anymore)
- flaky wire.
> I am attaching a failed
> (first) and successfull on the 4mbit part (second half) of the file.

The log you posted does not seem to be the log you refer to. What I read
from the log is:
First run in verbose mode with SST25VF016B.
Second run (not verbose) with a duplicated line "serial flash pin 29",
SST25VF040B.
Cut-and-paste error? Can you post the logs again as separate files with
verbose execution?

Besides that, I am confused how many chips you already have tried. There
were some Macronix and some SST chips, right?
> I'm trying to get to the point of trying to figure out if this 2M part
> will ever work on this board. I am beginning to have my doubts.
>
> My only remaining differences are this:

Yes, this is the patch I sent earlier.
> Index: spi.c
>
> --- spi.c       (revision 3073)
> +++ spi.c       (working copy)
> @@ -155,6 +155,12 @@
>                         0xFFF80000, 0xFFFEFFFF, (tmp & 1 << 3) ? "en" : "dis");
>                 printf("LPC write to serial flash %sabled\n",
>                         (tmp & 1 << 4) ? "en" : "dis");
>           if (!(tmp & 1 << 4)) {
>                   printf("Force enabling LPC write to serial flash\n");
>                   tmp |= 1 << 4;
>                   regwrite(port, 0x24, tmp);
>           }
>           printf("serial flash pin %i\n", (tmp & 1 << 5) ? 87 : 29);
>           printf("serial flash pin %i\n", (tmp & 1 << 5) ? 87 : 29);
>           /* LDN 0x7, reg 0x64/0x65 */
>           regwrite(port, 0x07, 0x7);
>
> @@ -375,7 +381,8 @@
>         switch (flash->manufacture_id) {
>         case ST_ID:
>         case MX_ID:
>           if ((flash->model_id & 0xff00) == 0x2000)
>           if (((flash->model_id & 0xff00) == 0x2000) ||
>                   ((flash->model_id & 0xff00) == 0x2500))
>                   spi_prettyprint_status_register_st_m25p(status);
>           break;
>   case SST_ID:

Regards,
Carl-Daniel

[ron minnich]

OK here goes.

Attached is:
my current svn diff
the 016 part, verbose
the 004 part, verbose.

I tried two different 16 mbit parts and both fail. I don't think the
parts are dead.

any help appreciated, I'm puzzled.

Today is my dedicated coreboot day so I can try anything here.

thanks

ron

[Carl-Daniel Hailfinger]

On 01.02.2008 21:08, ron minnich wrote:
> Attached is:
> my current svn diff
> the 016 part, verbose
> the 004 part, verbose.
>
> I tried two different 16 mbit parts and both fail. I don't think the
> parts are dead.

For the 4 Mbit part we see this in the logs:
> RDID returned bf 25 8d.

For the 16 Mbit part we see this:
> RDID returned ff ff ff.

If communication with the 16 Mbit part (SST25VF016B) had worked like in
earlier times, we would have seen this instead:
> RDID returned bf 25 41.

The ff ff ff sequence from RDID tells us that either there is some
communication failure between SPI controller and flash chip or the board
setup (southbridge/superio config) differs.
It would be very interesting to:
- boot with a 4 Mbit chip and switch to the 16 Mbit chip during runtime
- find out if the chips are wired differently (this includes being
soldered on different pads)
- check for accidential shorts.

I'm sure we can debug this, in the worst case with the help of an
oscilloscope.

Regards,
Carl-Daniel

[ron minnich]

On Feb 1, 2008 1:21 PM, Carl-Daniel Hailfinger
 wrote:
> boot with a 4 Mbit chip and switch to the 16 Mbit chip during runtime

That's how I'm doing this -- how swap.
No choice, I don't have a bios on the big parts.
> find out if the chips are wired differently (this includes being
>
> soldered on different pads)
> check for accidential shorts.

I gotta find a scope I suppose.

What's weird is these parts were being found earlier.

ron

[Carl-Daniel Hailfinger]

Hi Ron,

can I have an Ack for that patch? It has been sitting in my queue for
quite some time. I'll split the patch in 2 commits because spi.c has
been restructured and it is not advisable to commit patches for 2
different issues in one commit.

Regards,
Carl-Daniel

On 10.01.2008 13:32, Carl-Daniel Hailfinger wrote:
> Btw, the block lock bits are all set, so even if you manage to convince
> the SPI translation to map more than 512 KByte and even if you use
> enable LPC-to-SPI writes, you will still flash nothing. Try this for
> better lock bit printing:
>
> Enable LPC write cycle to SPI write cycle translation for IT8716F.
> Print detailed status register information for SST25VF series flash.
>
> Signed-off-by: Carl-Daniel Hailfinger
> Index: flashrom-ron/spi.c
>
> --- flashrom-ron/spi.c	(Revision 3036)
> +++ flashrom-ron/spi.c	(Arbeitskopie)
> @@ -136,6 +136,11 @@
>    		0xFFF80000, 0xFFFEFFFF, (tmp & 1 << 3) ? "en" : "dis");
>    	printf("LPC write to serial flash %sabled\n",
>    		(tmp & 1 << 4) ? "en" : "dis");
> if (!(tmp & 1 << 4)) {
> 	printf("Force enabling LPC write to serial flash\n");
> 	tmp |= 1 << 4;
> 	regwrite(port, 0x24, tmp);
> }
> printf("serial flash pin %i\n",	(tmp & 1 << 5) ? 87 : 29);
> /* LDN 0x7, reg 0x64/0x65 */
> regwrite(port, 0x07, 0x7);
>
> @@ -323,7 +328,8 @@
>    switch (flash->manufacture_id) {
>    case ST_ID:
>    case MX_ID:
> if ((flash->model_id & 0xff00) == 0x2000)
> if (((flash->model_id & 0xff00) == 0x2000) ||
>     ((flash->model_id & 0xff00) == 0x2500))
> generic_spi_prettyprint_status_register_st_m25p(status);
> break;
> }

[ron minnich]

I never got it to work but it may have been the board. The board is
dead and will not be  a product. That said, I'm happy to ack them if
you resend them etc.

ron

[Carl-Daniel Hailfinger]

On 15.05.2008 16:29, ron minnich wrote:
> I never got it to work but it may have been the board. The board is
> dead and will not be  a product.

That's very unfortunate.
> That said, I'm happy to ack them if
> you resend them etc.

Cool, thanks, I've done that a few minutes ago in separate threads
because they are separate changes.

Regards,
Carl-Daniel

[bari]

ron minnich wrote:
> I never got it to work but it may have been the board. The board is
> dead and will not be  a product. That said, I'm happy to ack them if
> you resend them etc.

Was that the AM2 + 761 + 966 mini-itx board?

[Joseph Smith]

On Thu, 15 May 2008 15:38:34 -0500, bari  wrote:
> ron minnich wrote:
> > I never got it to work but it may have been the board. The board is
> > dead and will not be  a product. That said, I'm happy to ack them if
> > you resend them etc.
>
> Was that the AM2 + 761 + 966 mini-itx board?

There are AMD mini-itx boards???
Iv'e only seen VIA mini-itx boards.
Just courious...

[Carl-Daniel Hailfinger]

On 15.05.2008 22:38, bari wrote:
> ron minnich wrote:
> > I never got it to work but it may have been the board. The board is
> > dead and will not be  a product. That said, I'm happy to ack them if
> > you resend them etc.
>
> Was that the AM2 + 761 + 966 mini-itx board?

Yes.

Regards,
Carl-Daniel

[Carl-Daniel Hailfinger]

On 15.05.2008 22:45, Joseph Smith wrote:
> On Thu, 15 May 2008 15:38:34 -0500, bari  wrote:
> > Was that the AM2 + 761 + 966 mini-itx board?
>
> There are AMD mini-itx boards???
> Iv'e only seen VIA mini-itx boards.
> Just courious...

IIRC it was a DTX board.

Regards,
Carl-Daniel

[bari]

Carl-Daniel Hailfinger wrote:
> On 15.05.2008 22:45, Joseph Smith wrote:
> > On Thu, 15 May 2008 15:38:34 -0500, bari  wrote:
> > > Was that the AM2 + 761 + 966 mini-itx board?
> >
> > There are AMD mini-itx boards???
> > Iv'e only seen VIA mini-itx boards.
> > Just courious...
>
> IIRC it was a DTX board.
>
> Regards,
> Carl-Daniel

http://images.dailytech.com/nimage/4746_large_GA-2761GXDK_PIC.jpg

-Bari

[Joseph Smith]

On Thu, 15 May 2008 16:14:19 -0500, bari  wrote:
> Carl-Daniel Hailfinger wrote:
> > On 15.05.2008 22:45, Joseph Smith wrote:
> > > On Thu, 15 May 2008 15:38:34 -0500, bari  wrote:
> > > > Was that the AM2 + 761 + 966 mini-itx board?
> > >
> > > There are AMD mini-itx boards???
> > > Iv'e only seen VIA mini-itx boards.
> > > Just courious...
> >
> > IIRC it was a DTX board.
> >
> > Regards,
> > Carl-Daniel
>
> http://images.dailytech.com/nimage/4746_large_GA-2761GXDK_PIC.jpg

Cool, I have never seen an AM2 board that small. Are they expensive to buy?

[ron minnich]

On Thu, May 15, 2008 at 2:31 PM, Joseph Smith  wrote:
> Cool, I have never seen an AM2 board that small. Are they expensive to buy?

AFAIK they never shipped.

ron

[LinuxBIOS] flashrom on ga 2761gxdk [gone off subject]

[Joseph Smith]

On Thu, 15 May 2008 17:56:11 -0700, "ron minnich" 
wrote:
> On Thu, May 15, 2008 at 2:31 PM, Joseph Smith

wrote:
> > Cool, I have never seen an AM2 board that small. Are they expensive to
>
> buy?
>
> AFAIK they never shipped.

Why not? I would buy one if it wasn't too expensive :-0
Is it still in development stages or something?
Or did the whole project just get borked?

Speaking of (off subject), as soon as I can get to them (in the attic), I
have some AMI i840 dual cpu prototype boards that have super buggy bios'
and AMI just gave up on them.  I was thinking of calling out a "coreboot
challenge" and donating three of them (keep the fourth one) to anyone that
could get coreboot running on them. This would sooo put it to the man :-)
The trick to them is this: the i840 was designed for RAMBUS, these boards
were designed with SDRAM, but with coreboots flexability this shouldn't be
hard. What do you think?

[LinuxBIOS] flashrom on ga 2761gxdk [gone off subject]

[Peter Stuge]

On Thu, May 15, 2008 at 10:40:35PM -0400, Joseph Smith wrote:
> The trick to them is this: the i840 was designed for RAMBUS, these
> boards were designed with SDRAM, but with coreboots flexability
> this shouldn't be hard. What do you think?

I think it will be very hard to make coreboot turn SDRAM into RAMBUS.

//Peter

[LinuxBIOS] flashrom on ga 2761gxdk [gone off subject]

[Joseph Smith]

On Fri, 16 May 2008 04:47:16 +0200, Peter Stuge  wrote:
> On Thu, May 15, 2008 at 10:40:35PM -0400, Joseph Smith wrote:
> > The trick to them is this: the i840 was designed for RAMBUS, these
> > boards were designed with SDRAM, but with coreboots flexability
> > this shouldn't be hard. What do you think?
>
> I think it will be very hard to make coreboot turn SDRAM into RAMBUS.

Hmm, I think it would just take some converting. The way the boards are
setup now is you still have to install the SDRAM in pairs just like RAMBUS.