[LinuxBIOS] [PATCH] flashrom: Fix wrong VT8235 flash enable failed warning.

[Luc Verhaegen]

This fixes the warning that's present for all VT8235 southbridges:

...
Enabling flash write on VT8235...tried to set 0x4 to 0x14 on VT8235 failed (WARNING ONLY)
...

It's bourne from misinterpreting the return value of pci_write_byte, 
which peculiarly returns 1 for success.

Luc Verhaegen.

[LinuxBIOS] [PATCH] flashrom: Fix wrong VT8235 flash enable failed warning.

[Uwe Hermann]

Hi,

On Fri, Mar 02, 2007 at 02:22:37PM +0100, Luc Verhaegen wrote:
> This fixes the warning that's present for all VT8235 southbridges:
>
> ...
> Enabling flash write on VT8235...tried to set 0x4 to 0x14 on VT8235 failed (WARNING ONLY)
> ...
>
> It's bourne from misinterpreting the return value of pci_write_byte, 
> which peculiarly returns 1 for success.
>
> Luc Verhaegen.
> flashrom: Fix wrong VT8235 flash enable failed warning.
> Fix harmless but worrying warning where the return value of 
> pci_write_byte is misinterpreted.
> Hash together VT8231 and VT8235 code into VT823x. VT8231 is the better
> implementation, but lacked the write protect disable code that's
> apparently needed for VT8235.
>
> Signed-off-by: Luc Verhaegen

Looks reasonable to me, but I cannot test this.

Have you tested the patch on both vt8235 and vt8231 (actual hardware)?

Any complaints from anybody? Otherwise I guess we can commit this.

Uwe.

[LinuxBIOS] [PATCH] flashrom: Fix wrong VT8235 flash enable failed warning.

[Luc Verhaegen]

On Fri, Mar 02, 2007 at 03:15:28PM +0100, Uwe Hermann wrote:
> Hi,
>
> Looks reasonable to me, but I cannot test this.
>
> Have you tested the patch on both vt8235 and vt8231 (actual hardware)?
>
> Any complaints from anybody? Otherwise I guess we can commit this.
>
> Uwe.

Verified on:
CLE266 + VT8235
KM400 + VT8237
K8M800 + VT8235

I have no VT8231 at my disposal, but the codepath is and used to be the 
same for VT8237.

Luc Verhaegen.

[LinuxBIOS] [PATCH] flashrom: Fix wrong VT8235 flash enable failed warning.

[Stefan Reinauer]

* Luc Verhaegen  [070302 14:22]:
> flashrom: Fix wrong VT8235 flash enable failed warning.
> Fix harmless but worrying warning where the return value of 
> pci_write_byte is misinterpreted.
> Hash together VT8231 and VT8235 code into VT823x. VT8231 is the better
> implementation, but lacked the write protect disable code that's
> apparently needed for VT8235.
>
> Signed-off-by: Luc Verhaegen

Looks great to me. The warning was kind of useless, since I got this a
couple of times, while flashing worked nicely every time.

Acked-by: Stefan Reinauer

Can someone check this in, please? I am a bit loaded.
> Index: util/flashrom/flash_enable.c
>
> --- util/flashrom/flash_enable.c	(revision 2566)
> +++ util/flashrom/flash_enable.c	(working copy)
> @@ -158,52 +158,49 @@
>    return enable_flash_ich(dev, name, 0xdc);
>  }
>
> -static int enable_flash_vt8235(struct pci_dev *dev, char *name)
> +static int enable_flash_vt823x(struct pci_dev *dev, char *name)
>  {
> uint8_t old, new, val;
> unsigned int base;
> int ok;
> old = pci_read_byte(dev, 0x40);
> new = old | 0x10;
> if (new == old)
> return 0;
> ok = pci_write_byte(dev, 0x40, new);
> if (ok != 0) {
> printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n",
>        old, new, name);
> }
> /* enable GPIO15 which is connected to write protect. */
> base = ((pci_read_byte(dev, 0x88) & 0x80) | pci_read_byte(dev, 0x89) << 8);
> val = inb(base + 0x4d);
> val |= 0x80;
> outb(val, base + 0x4d);
> if (ok != 0) {
> return -1;
> } else {
> return 0;
> }
>
> -}
>
> -static int enable_flash_vt8231(struct pci_dev *dev, char *name)
> -{
>    uint8_t val;
>    int ret = 0;
>
>    /* ROM Write enable */
>
> val = pci_read_byte(dev, 0x40);
>  val |= 0x10;
>  pci_write_byte(dev, 0x40, val);
>
> if (pci_read_byte(dev, 0x40) != val) {
> printf("tried to set 0x%x to 0x%x on %s failed (WARNING ONLY)\n",
>        0x40, val, name);
> return -1;
> printf("Warning: Failed to enable ROM Write on %s\n", name);
> ret = -1;
> }
> return 0;
>    if (dev->device_id == 0x3177) { /* VT8235 */
>            if (!iopl(3)) { /* enable full IO access */
>                    unsigned int base;
>                    /* GPIO12-15 -> output */
>                    val = pci_read_byte(dev, 0xE4);
>                    val |= 0x38;
>                    pci_write_byte(dev, 0xE4, val);
>                    /* Get Power Management IO address. */
>                    base = pci_read_word(dev, 0x88) & 0xFF80;
>                    /* enable GPIO15 which is connected to write protect. */
>                    val = inb(base + 0x4d);
>                    val |= 0xFF;
>                    outb(val, base + 0x4d);
>                    val = inb(base + 0x4E);
>                    val |= 0x0F;
>                    outb(val, base + 0x4E);
>            } else {
>                    printf("Warning; Failed to disable Write Protect"
>                           " on %s (iopl failed)\n", name);
>                    return -1;
>            }
>    }
> return ret;
>
> }
>
> static int enable_flash_cs5530(struct pci_dev *dev, char *name)
> @@ -445,9 +442,9 @@
>    {0x8086, 0x2810, "ICH8/ICH8R", enable_flash_ich_dc},
>    {0x8086, 0x2812, "ICH8DH", enable_flash_ich_dc},
>    {0x8086, 0x2814, "ICH8DO", enable_flash_ich_dc},
> {0x1106, 0x8231, "VT8231", enable_flash_vt8231},
> {0x1106, 0x3177, "VT8235", enable_flash_vt8235},
> {0x1106, 0x3227, "VT8237", enable_flash_vt8231},
> {0x1106, 0x8231, "VT8231", enable_flash_vt823x},
> {0x1106, 0x3177, "VT8235", enable_flash_vt823x},
> {0x1106, 0x3227, "VT8237", enable_flash_vt823x},
> {0x1106, 0x0686, "VT82C686", enable_flash_amd8111},
> {0x1078, 0x0100, "CS5530", enable_flash_cs5530},
> {0x100b, 0x0510, "SC1100", enable_flash_sc1100},
>

[LinuxBIOS] [PATCH] flashrom: Fix wrong VT8235 flash enable failed warning.

[Luc Verhaegen]

On Fri, Mar 02, 2007 at 03:43:07PM +0100, Stefan Reinauer wrote:
> Looks great to me. The warning was kind of useless, since I got this a
> couple of times, while flashing worked nicely every time.

Ah, so you wrote that :) Then you also know what board that write 
protect had to be disabled for there :) I gathered someplace that this 
was needed for some asus board, right?

My other KM400 based system (Asus A7V400-MX) refuses to have its ROM 
identified, while it uses the same well-supported VT8235/SST39SF020A 
combination as found on the EPIA Ms. This behaviour didn't get altered 
by that patch.

I tested various combinations for the io pins, yet didn't get anywhere, 
all i haven't tried yet is reboot the machine (in the off chance that 
that changes anything). Mind you, this testing was done more than a 
month ago, when i ordered the willem and wrote that patch, but i can 
freely access that machine at all times.

This motherboards BIOS is supposed to have a "CrashFree" BIOS, and i 
have a hard time finding out what that actually is supposed to do. I 
have a hard time looking through the marketing, and some bits have 
already fallen off the web.

Here's the marketing from Asus' site:
"CrashFree BIOS allows users to restore BIOS data from a floppy diskette 
even when BIOS code and data are corrupted during upgrade or invaded by 
virus. Unlike other competing vendors' products, ASUS motherboards now 
enable users to enjoy this protection feature without the need to pay 
for an extra ROM."

There have been several of these crashfree things in the course of a few 
years, all are more or less equally obscure.

Luc Verhaegen.

[LinuxBIOS] CrashFree, Virtual DualBIOS, etc.

[Uwe Hermann]

On Fri, Mar 02, 2007 at 04:09:28PM +0100, Luc Verhaegen wrote:
> This motherboards BIOS is supposed to have a "CrashFree" BIOS, and i 
> have a hard time finding out what that actually is supposed to do. I 
> have a hard time looking through the marketing, and some bits have 
> already fallen off the web.

I think we should have a section in the FAQ/wiki about all these
CrashFree, Virtual DualBIOS and whatnot features...

Each one should be tested by somebody who owns the respective hardware,
and then we document which of those really work if you brick the board
by flashing a non-working LinuxBIOS image (and which don't).

If we can, we should also gather some information about how extactly
they work internally (software-only, hardware-based, two chips,
splitting one chip in two (virtual) halves etc.).

This will be very useful for lots of people, I presume...

Uwe.

[LinuxBIOS] CrashFree, Virtual DualBIOS, etc.

[Luc Verhaegen]

On Fri, Mar 02, 2007 at 05:22:57PM +0100, Uwe Hermann wrote:
> On Fri, Mar 02, 2007 at 04:09:28PM +0100, Luc Verhaegen wrote:
> > This motherboards BIOS is supposed to have a "CrashFree" BIOS, and i 
> > have a hard time finding out what that actually is supposed to do. I 
> > have a hard time looking through the marketing, and some bits have 
> > already fallen off the web.
>
> I think we should have a section in the FAQ/wiki about all these
> CrashFree, Virtual DualBIOS and whatnot features...
>
> Each one should be tested by somebody who owns the respective hardware,
> and then we document which of those really work if you brick the board
> by flashing a non-working LinuxBIOS image (and which don't).
>
> If we can, we should also gather some information about how extactly
> they work internally (software-only, hardware-based, two chips,
> splitting one chip in two (virtual) halves etc.).
>
> This will be very useful for lots of people, I presume...
>
> Uwe.

Hrm.

First of all, let me assert that i have absolutely no clue about 
flashroms, so i might be talking pure rubbish here. But let me line up 
some facts, and what i think might be going on here.

Facts:
* The part itself is an SST39SF020A, a well known 256kB part.
* flashrom is reading: id1 0x25, id2 0x1e with probe_jedec at 256kB.
* Asus provides a 256kB (exactly) BIOS Image for this board, so it will 
  be filling this rom completely.

So, i see two options:
* Asus crashfree doesn't protect against a bad flash, but did manage to 
change the IDs returned (is this even possible?).
* The board has a tiny bit of seperate flash itself, the bios in there 
gets loaded first from the top of address space, which later on loads 
and runs the BIOS in the SST39SF020A. This would mean that the 
SST39SF020A lives somewhere else, and its id can be found, probably at 
some 512 or so boundary not too far away from the 256kB mark.

Is there anything wrong in those hypotheses? Am i missing something?

Anyway, testing options:

* make flashrom probe_jedec at 256kB, and subsequent 4k boundaries 
until 0xFF, 0xFF is returned. If it stops at 260kB, then there's no 
seperate BIOS.

* hotplug a rom (when i get them -- don't go through willem.org unless 
you're a pensioner) in at one point and see whether flashrom then is 
able to identify that one.

* try to directly read out the rom coming out of the board using a 
willem programmer.

Does any of this make sense?

Luc Verhaegen.

[LinuxBIOS] CrashFree, Virtual DualBIOS, etc.OA

[Luc Verhaegen]

On Sat, Mar 03, 2007 at 08:26:07AM +0100, Luc Verhaegen wrote:
> On Fri, Mar 02, 2007 at 05:22:57PM +0100, Uwe Hermann wrote:
> > I think we should have a section in the FAQ/wiki about all these
> > CrashFree, Virtual DualBIOS and whatnot features...
>
> Hrm.
>
> First of all, let me assert that i have absolutely no clue about 
> flashroms, so i might be talking pure rubbish here. But let me line up 
> some facts, and what i think might be going on here.
>
> Facts:
> The part itself is an SST39SF020A, a well known 256kB part.
> flashrom is reading: id1 0x25, id2 0x1e with probe_jedec at 256kB.
> Asus provides a 256kB (exactly) BIOS Image for this board, so it will 
> be filling this rom completely.

Google turned the following AMI document: 
http://www.ami.com/support/doc/AMIBIOS8-Flash-Recovery-Whitepaper.pdf
where the use of a boot block is somewhat explained.

This looks like this just is about reserving part of the rom for an 
image that's just enough to recover from a broken/failed main image. 
AMIs own utilities give one the option to also overwrite this area, so 
it seems like it is all in these utilities, and that there's no extra 
hardware involved at all.

So flashrom should probably see no difference at all.

My guess is that the crashfree award BIOS on that Asus board of mine is 
nothing different from AMIs boot block. Looking closely at the manual, 
looking for some "BIOS protect" option, there was a section about 
Crashfree there. It does allow you to recover from a failed flash.

I did find the following excerpt quite amusing:
"To use the CrashFree BIOS feature on this motherboard, install a VGA 
card into one of the expansion slots before rebooting the computer. On 
motherboards with onboard VGA, you will not see the screen display when 
the BIOS crashes even if you reboot the computer."

On VIAs IGP chips (unichrome/chrome), in the not too distant future, 
this (amongst other things) is where linuxbios will be bettering Asus's 
crashfree :)

Anyway, i'm now more convinced that flashrom failing to ID the rom is 
probably not due to Asus's crashfree. I should probably go and poke 
those io lines again and see if anything changes.

uniflash knows about an asus board with a KT400 (a close relation of the 
OAKM400, but lacking the IGP) board. And it seems to enable a different 
io line (through a different mechanism), even though it uses the exact 
same southbridge. It seems that the io line used is board and not 
southbridge specific.

Stefan, do you have some recollection what board, specifically, that io 
line change in flash_enable_VT823x is/was for?

Also, if the chip is still locked down, would it be returning a bogus ID 
or would it be returning 0xFFFF as when you try to access it at 
512/1024kB? Does the fact that it returns 0x1E25 have any significance 
at all?

Luc Verhaegen.

[LinuxBIOS] CrashFree, Virtual DualBIOS, etc.OA

[Stefan Reinauer]

* Luc Verhaegen  [070304 14:49]:
> Stefan, do you have some recollection what board, specifically, that io 
> line change in flash_enable_VT823x is/was for?

No, unfortunately I don't remember. I think that code was written by
Ollie Lho?

It is definitely mainboard specific code and should go to the mainboard
specific section, not the chipset specific section. But fortunately it
did not hurt yet.

It is some Epia or Epia-M(II) board based on C3.
> Also, if the chip is still locked down, would it be returning a bogus ID 
> or would it be returning 0xFFFF as when you try to access it at 
> 512/1024kB? Does the fact that it returns 0x1E25 have any significance 
> at all?

If the chip is locked down, reading that position would just reveal the
data written to that address in the chip. So 0x1E25 can be some data,
but also the ID. If the data changes once you send the identify command,
it is (most likely) the ID. If it stays the same, it is almost certain
only data.

[LinuxBIOS] [PATCH] flashrom: Fix wrong VT8235 flash enable failed warning.

[Uwe Hermann]

On Fri, Mar 02, 2007 at 03:43:07PM +0100, Stefan Reinauer wrote:
> > Signed-off-by: Luc Verhaegen
>
> Acked-by: Stefan Reinauer

Committed in r2568, thanks.

Uwe.

[LinuxBIOS] [PATCH] flashrom: Fix wrong VT8235 flash enable failed warning.

[Luc Verhaegen]

On Fri, Mar 02, 2007 at 11:17:56PM +0100, Uwe Hermann wrote:
> On Fri, Mar 02, 2007 at 03:43:07PM +0100, Stefan Reinauer wrote:
> > > Signed-off-by: Luc Verhaegen
> >
> > Acked-by: Stefan Reinauer
>
> Committed in r2568, thanks.
>
> Uwe.

Thanks

Luc Verhaegen.
>