[LinuxBIOS] flashrom on ga 2761gxdk
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
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
On Jan 9, 2008 3:28 AM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> 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
On 09.01.2008 17:03, ron minnich wrote:
On Jan 9, 2008 3:28 AM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> 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
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
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@gmx.net> 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
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@gmx.net> 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? 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@gmx.net>
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; }
On Jan 22, 2008 8:27 AM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> 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
On 22.01.2008 17:37, ron minnich wrote:
On Jan 22, 2008 8:27 AM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> 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
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:
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
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
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
On Feb 1, 2008 1:21 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> 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
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@gmx.net>
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; }
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
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
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?
On Thu, 15 May 2008 15:38:34 -0500, bari <bari@onelabs.com> 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
On 15.05.2008 22:45, Joseph Smith wrote:
On Thu, 15 May 2008 15:38:34 -0500, bari <bari@onelabs.com> 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
Carl-Daniel Hailfinger wrote:
On 15.05.2008 22:45, Joseph Smith wrote:
On Thu, 15 May 2008 15:38:34 -0500, bari <bari@onelabs.com> 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
On Thu, 15 May 2008 16:14:19 -0500, bari <bari@onelabs.com> 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@onelabs.com> 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
On Thu, May 15, 2008 at 2:31 PM, Joseph Smith <joe@settoplinux.org> wrote:
Cool, I have never seen an AM2 board that small. Are they expensive to buy?
AFAIK they never shipped. ron
On Thu, 15 May 2008 17:56:11 -0700, "ron minnich" <rminnich@gmail.com> wrote:
On Thu, May 15, 2008 at 2:31 PM, Joseph Smith <joe@settoplinux.org> 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
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
On Fri, 16 May 2008 04:47:16 +0200, Peter Stuge <peter@stuge.se> 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
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
participants (5)
-
bari -
Carl-Daniel Hailfinger -
Joseph Smith -
Peter Stuge -
ron minnich