[flashrom] [PATCH] Updated vt823x "set all writes to lpc".
libv at skynet.be
Tue Dec 22 13:52:10 CET 2009
On Tue, Dec 22, 2009 at 03:48:38AM +0100, Carl-Daniel Hailfinger wrote:
> On 16.12.2009 12:14, Luc Verhaegen wrote:
> > Chipset/Board: vt8237: Set All mem cycles to LPC in chipset enable.
> I don't have the datasheet, so I can't cross-check. I'm very interested
> why this would be needed, though. If mem cycles don't go to LPC and we
> have flash on LPC, the board won't boot anyway. If we force mem cycles
> to LPC although we have parallel ROM, this will break. Does VT8237R
> support parallel ROMs?
We need this, otherwise we wouldn't be changing this many board enables
About parallel roms, no idea, but if we apply this patch, we should soon
> > Only done for VT8237R (possibly needed for VT8237 too), VT8235 does
> > not need this (even if the original bios does so: Asus A7V8X-MX SE,
> > MSI KT4V were verified).
> Yes, the VT8235 datasheet says those bits are reserved.
> How about VT8237A and VT8237S?
No idea. Although no boards have needed this so far.
> > This then opens a floodgate of cleanups in the board enables.
> > * EPIA SP board enable vanishes, taking EPIA CN match with it.
> Those should be moved to the "known good" list in print.c or they will
> end up not being listed as supported.
Not a big fan of a list which is constantly out-of-date, but will do in
a follow up patch.
> I do like the GPIO cleanups. They make the board enables shorter and
> more readable.
Yes, we have enough board enables today to be starting to see a line in
> Should say VT8237R, not VT8237 (at least according to your comments in
> other places in the code).
> > + /* All memory cycles, not just ROM ones, go to LPC. */
> > + val = pci_read_byte(dev, 0x59);
> > + val &= ~0x80;
> > + pci_write_byte(dev, 0x59, val);
> > + }
> > +
> > return 0;
> > }
> Side note: Should we read the ROMCS# strap on VT8235 to check whether
> the ROM is LPC or Parallel? Does this strap exist for other VT823x as well?
> I found a bug and two weirdnesses (at least when using VT8235 datasheet
> as reference) in the original code for vt823x_gpio_set():
> GPIO 9 on VT8235 needs val |= 0x08, not val |= 0x20. Not sure whether a
> fix here would break some board enables.
> For GPIOs 9,12-13 we have to make sure that PCI config reg 0x53 bit 7
> (PCI DMA Pair A and Pair B) is 0.
> For GPIOs 12-15 we have to make sure that PCI config reg 0x5b bit 1
> (INTE#, INTF#, INTG#, INTH#) is 0.
> If you have a good explanation for the mem cycle question and if you'll
> add the removed boards to the known good list either as followup patch
> or right now, this is
> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
First part: not sure we should look for an explanation first, or just
wait for the reports to roll in. The VT8237R is very popular, it will be
a matter of wait and see.
Second part, ok.
> A bugfix for the GPIO function would be appreciated, but that's a
> separate issue. I don't have VT8237* datasheets, so I can't do that myself.
Ok, will have a look too.
More information about the flashrom