On Fri, Jan 15, 2016 at 8:42 PM, Andrey Korolyov andrey@xdel.ru wrote:
On Fri, Jan 15, 2016 at 8:11 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi Andrey,
On 15.01.2016 15:33, Andrey Korolyov wrote:
On Sun, Jan 3, 2016 at 9:44 PM, Andrey Korolyov andrey@xdel.ru wrote:
> Hi Andrey, > > please post complete logs of a working and non-working probe as well as > the exact flashrom version you are using. The output of lspci -nnv > might become handy as well. >
Thanks Stefan,
even giving out a fact that I am very lucky to hit very twisted issues at all, this time it looks like chip eventually stopped to respond via an appropriate interface (slight voltage change? bit-flip during a board initialization? lack of a probe delay? ), so I think that the initial report could be incorrect, as the flash is not responding anymore even where is was supposed to. Nevertheless, the appropriate log and lspci output are attached, please take a look on them if they could be helpful.
Got an another sample of the same board, because original was died from overheating during EEPROM resoldering procedure. Internal WRITE effectively bricked a board over cold reboot but I finally obtained logs with some possible usefulness. Should I check same random behavior as I reported previously after reflashing the chip externally? Unfortunate to me, the board layout strictly requires chip desoldering before I would be able to program it with anything, in-place attempts are failing even with external power source, but when de-soldered, chip flashes just perfectly via Minipro.
flashrom v0.9.7-r1711 on NetBSD 7.0 (i386) flashrom is free software, get the source code at http://www.flashrom.org
flashrom was built with libpci 3.3.0, GCC 4.8.4, little endian Command line (7 args): flashrom -p internal:laptop=this_is_not_a_laptop -c W39V040FB -r bios.bin -V Calibrating delay loop... OS timer resolution is 5 usecs, 166M loops per second, 10 myus = 14 us, 100 myus = 105 us, 1000 myus = 1004 us, 10000 myus = 10042 us, 20 myus = 24 us, OK. Initializing internal programmer [...] Found chipset "AMD CS5536" with PCI ID 1022:2080. Enabling flash write... No MSR support for your OS yet. FAILED! Warning: unexpected second chipset match: "AMD CS5536" ignoring, please report lspci and board URL to flashrom@flashrom.org with 'CHIPSET: your board name' in the subject line.
I suspect this may be part of the issue. Another suspicion is that older NetBSD may automatically enable the MSRs we need, and later NetBSD versions don't.
Regards, Carl-Daniel
Okay, once I flash coreboot rom (GX3 is very simular to the existing implementations in the tree and its support almost entirely copy-pasted from db800), I`ll be able to boot Linux and check hypothesis about MSRs. Another interesting part, as I wrote before, is a heisenberg-style disappearance of the SuperIO register availability.
To follow this up: Linux exposes same mixed behavior as NetBSD earlier, e.g. erase+write sometimes could be completed successfully, sometimes erase procedure just messes PROM contents as mentioned before. Software environment and operating voltage are absolutely stable between those tries so this is almost surely a timing issue in the prom chip itself or mis-engineering in its electrical neighborhood which results in a protocol violation. This is just for information, I do not own any hardware which `ll be able to prove or disprove this hypothesis by measuring data on a parallel interface directly,
BTW, are there still any FWH-capable romulators in production? Looks like most of sockets from this era has been designed without bearing in mind possibility of the in-scheme reprogramming, but the only romulators I`ve seen on ebay are ancient devices bundled with software on floppies...