[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
<c-d.hailfinger.devel.2006(a)gmx.net&gt; 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
 <c-d.hailfinger.devel.2006(a)gmx.net&gt; 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

[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 <c-d.hailfinger.devel.2006(a)gmx.net&gt;

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 <c-d.hailfinger.devel.2006(a)gmx.net&gt;

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 <c-d.hailfinger.devel.2006(a)gmx.net&gt;

 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;
  	}




-- 
http://www.hailfinger.org/

[ron minnich]

On Jan 22, 2008 8:27 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006(a)gmx.net&gt; 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
 <c-d.hailfinger.devel.2006(a)gmx.net&gt; 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
<c-d.hailfinger.devel.2006(a)gmx.net&gt; 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 <c-d.hailfinger.devel.2006(a)gmx.net&gt;

 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;
  	}




-- 
http://www.hailfinger.org/

[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 <bari(a)onelabs.com&gt; 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...
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org

[Carl-Daniel Hailfinger]

On 15.05.2008 22:45, Joseph Smith wrote:
 On Thu, 15 May 2008 15:38:34 -0500, bari <bari(a)onelabs.com&gt; 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 <bari(a)onelabs.com&gt; 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 <bari(a)onelabs.com&gt; wrote:
 Carl-Daniel Hailfinger wrote:
> On 15.05.2008 22:45, Joseph Smith wrote:
>
>> On Thu, 15 May 2008 15:38:34 -0500, bari <bari(a)onelabs.com&gt; 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?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org

[ron minnich]

On Thu, May 15, 2008 at 2:31 PM, Joseph Smith <joe(a)settoplinux.org&gt; 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" <rminnich(a)gmail.com&gt;
wrote:
 On Thu, May 15, 2008 at 2:31 PM, Joseph Smith
<joe(a)settoplinux.org&gt;
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?

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org

[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 <peter(a)stuge.se&gt; 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.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org

[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

[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