See patch. This is what I had to do to get the combo working again.
On 2/4/10 2:55 AM, Luc Verhaegen wrote:
Sorry to say that these are the subsystem IDs that are set by the BIOS of that machine. The old entry simply does not work. So do you have a suggestion to make, beyond Nack?
On Thu, Feb 04, 2010 at 03:18:08AM +0100, Stefan Reinauer wrote:
If the PCI subsystem ids are bogus, autodetection per pci-ids will mean that this board enable gets run on other, equally bogus, boards as well.
We have DMI, please provide the output of flashrom -V so we can try to salvage things through DMI.
If not, this board has to be -m, or coreboot ids only.
Luc Verhaegen.
On 04.02.2010 01:51, Stefan Reinauer wrote:
Just a short question: The Kontron 986LCD-M appeared to be running coreboot. Is that correct? Quoting from the failure log you sent earlier:
Apparently it finds the Kontron board just fine if the board is running coreboot.
From the above, I guess that Kontron detection fails if the board is
running classic BIOS. In that case, a verbose run of flashrom (probe is enough) on a 986LCD-M with factory BIOS should give us the DMI strings we need to match without problems even if coreboot is not running.
Thanks for the patch! Sean Nelson is currently working on a patch which handles locking in a generic way, and I heard his patch is mostly finished. Your patch is a good interim solution, but we'd have to revert it once Sean's patch goes in (which may be even this week). Not sure how to proceed.
Thanks. Given that we're currently rewriting probe to be more robust (reset before and after probe), and Sean's locking patch is just around the corner, everything will need to be retested. I plan to commit your patch if those rewrites are not committed until early next week.
Regards, Carl-Daniel
On 2/4/10 3:07 AM, Carl-Daniel Hailfinger wrote:
No. The run that requires the IDs are with vendor BIOS. coreboot can detect the board through coreboot table.
The subsystem IDs are only required when running flashrom on a not yet migrated board.
I tried not changing the subsystem IDs and simply adding a DMI match string, but that won't work because the DMI matching code is never executed because the subsystem vendor ID matching code already decided it's not a kontron board
See above.
Playing the devils advocate ;-) So then probing will fail if reset fails, and if probe fails. Now probe fails only if probe fails. So the code gets more robust by adding more potential failure points? ;-)
Don't worry committing the stuff. The patches are out there for those who need them, that'll be fine until flashrom has a decent locking framework.
Stefan
On Thu, Feb 04, 2010 at 03:30:13AM +0100, Stefan Reinauer wrote:
If DMI can be used successfully (could be that kontron also buggered that up), then the combination of subsystem ids and dmi will make a unique match.
As things are, it will not be unique. Add DMI, and it will be unique.
How did you handle this board in the past? It always used to be a -m board as far as i can tell:
/* Note: There are >= 2 version of the Kontron 986LCD-M/mITX! */ - {0x8086, 0x27b8, 0, 0, 0, 0, 0, 0, "kontron", "986lcd-m", "Kontron", "986LCD-M", board_kontron_986lcd_m}, - {0x10ec, 0x8168, 0x10ec, 0x8168, 0x104c, 0x8023, 0x104c, 0x8019, "kontron", "986lcd-m", "Kontron", "986LCD-M", board_kontron_986lcd_m}, + {0x8086, 0x27A0, 0, 0, 0x8086, 0x27b8, 0, 0, "kontron", "986lcd-m", "Kontron", "986LCD-M", board_kontron_986lcd_m},
Luc Verhaegen.
Short summary: The DMI non-match behaviour you're seeing is either by design or by accident. Not sure yet. There are patches floating around which would allow a DMI match without subsystem IDs. Will ping you once this is resolved.
On 04.02.2010 03:30, Stefan Reinauer wrote:
Ah, right. I'm not 100% familiar with the code. Looking at it again, the rules are: - Provide subsystem IDs even if they are bogus (e.g. copy of chipset vendor/device ID) - Since the above will match too many boards, DMI will be consulted as well. - DMI without subsystem IDs is too dangerous (multiple matches), so subsystem IDs are required even if they are bogus.
Given that there seems to be some confusion about whether requiring subsystem IDs even in the presence of DMI is a good idea, the rules may change.
Side note: the coreboot ID matching code needs some revamping to be more readable (and with DMI, some abuses can be eliminated).
Unless I'm mistaken, the flashrom log you sent was from a board with coreboot, but I need a flashrom log from a board with factory BIOS.
Short summary: - With the current DMI matching code, we need the sort-of-bogus subsystem IDs rejected by Luc. - The subsystem requirement may change tomorrow. - Additionally, that entry needs a DMI string as well.
Caveat: If subsystem IDs differ between vendor BIOS and coreboot, we need two entries with the current policy.
Yes and no. The problem is that sometimes a chip may be in an undefined state because of previous probe sequences it didn't understand (happened on some Alix board with an Amic chip). Resetting it before probing could fix that case. Fortunately, the variability of reset sequences is much lower than the variability of probe sequences (I think only 3 reset sequences exist in total). Besides that, probe_xxx() right now is probe/reset, and afterwards it will be reset/probe/reset.
Regards, Carl-Daniel
On 04.02.2010 04:42, Carl-Daniel Hailfinger wrote:
Resolved for now.
Subsystem IDs for the first device are required for DMI to match, subsystem IDs for the second device are optional AFAICS.
I must have missed the lspci of the Kontron 986LCD-M with factory BIOS. Anyway, if you resend your mainboard patch with one small change (added DMI match) and if it works, I'll ack.
Regards, Carl-Daniel
Hi Stefan,
W39V080FA writing should be fixed in r907 (and any later version). The DMI code has been fixed, and it now should work reliably.
I'd like to know which changes are still needed from your side, and then make sure they get merged in a way that keeps existing BIOS and coreboot versions of the board working.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Luc Verhaegen -
Stefan Reinauer