On 18.01.2016 00:28, Stefan Tauner wrote:
> Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at>
I'm not totally happy about not logging the commands during actual
compilation. That way, if something fails after the configure phase, we
need both a paste from the shell and the debug log file.
Anyway...
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Regards,
Carl-Daniel
On Sat, 23 Jan 2016 17:51:27 +0100
Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> wrote:
> On Sat, 23 Jan 2016 19:32:14 +0300
> Andrey Korolyov <andrey(a)xdel.ru> wrote:
>
> > 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...
>
> You might be interested in https://www.coreboot.org/FlexyICE
> I have just discovered that project a few weeks ago myself so I cannot
> give much more information than that. It is probably not purchasable
> anymore but open enough that one could build something new from that.
> Sooner or later I am planning to give a related projected out as
> Bachelor or Master thesis but that will take a while (and would
> probably be SPI-related).
I have freed the two repositories of the project from opencores (they
require registration just to download and the registration process is
manual!).
Currently they reside in the flashrom realm of github:
https://github.com/flashrom/artec_dongle_fpgahttps://github.com/flashrom/artec_dongle_ii_fpga
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Mon, 18 Jan 2016 16:18:59 -0500
David Wood <jbevren(a)gmail.com> wrote:
> Hello,
>
> Stefanct on freenode:#flashrom requested I email this to you.
>
> I've successfully reprogrammed a M25PE40 device, which was listed as
> untested by SVN flashrom. Setup info and related TTY log follows.
>
> http://pix.jbevren.net/e/LTV/leaptv-debrick
>
> The ROM is left in-circuit, and the LeapTV is powered up after the
> Raspberry Pi boots. Power is provided by the LeapTV system board. More
> relevant information is available on the page linked above, including an
> image of the setup.
Hello David,
thanks for your report!
I have marked the flash chip as fully tested and will commit that later
together with other small changes.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hello,
I wanted to contact with you earlier about the buspirate write failure,
just I have forgotten it
I have also had problems with different external programmers and a the
solution was adding a 100nF capacitor right next to the SPI flash.
That sorted out the intermittent failures.
HTH
Regards,
Miklos Marton
2016-01-05 12:54 keltezéssel, flashrom-request(a)flashrom.org írta:
> Send flashrom mailing list submissions to
> flashrom(a)flashrom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.flashrom.org/mailman/listinfo/flashrom
> or, via email, send a message with subject or body 'help' to
> flashrom-request(a)flashrom.org
>
> You can reach the person managing the list at
> flashrom-owner(a)flashrom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of flashrom digest..."
>
>
> Today's Topics:
>
> 1. READ ERASE WRITE tested for W25X64 on buspirate_spi, ICH9M-E
> (Johannes Krampf)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 Jan 2016 12:43:31 +0100
> From: Johannes Krampf <johannes.krampf(a)googlemail.com>
> To: flashrom(a)flashrom.org
> Subject: [flashrom] READ ERASE WRITE tested for W25X64 on
> buspirate_spi, ICH9M-E
> Message-ID: <568BAC63.30008(a)googlemail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hello,
>
> I have successfully tested the Winbond W25X64 flash chip (8192 kB, SPI)
> for Probe, Read, Erase and Write operations using the buspirate_spi and
> Intel ICH9M-E (Thinkpad T400) programmers.
>
> Testing was done with flashrom v0.9.8-r1901 on ICH9M-E and v0.9.8-r1888
> (Parabola/Arch default) on buspirate_spi.
>
> I slightly modified board_enable.c in flashrom to add the T400 to the
> whitelist when flashing on r1901 (taken from libreboot patch):
>
> + {0x8086, 0x2917, 0x17AA, 0x20F5, 0x8086, 0x2930, 0x17AA, 0x20F9,
> "^ThinkPad T400", NULL, NULL, P2, "IBM/Lenovo", "ThinkPad T400",
> 0, OK, p2_whitelist_laptop},
>
> My buspirate is the sparkfun version and I used the 30cm long cable
> which connects directly to 0.1" headers and the recommended 6.2 FW
> version. Flashing worked at default (8M) speed with multiple reads
> always producing the same checksum.[1] Reading the ROM took around 13min.
>
> Logs are attached.
>
> Please don't hesitate to ask for more information if required.
>
> - Johannes
>
> [1] This was not the case when flashing a Lenovo X200 with a Macronix
> MX25L6405D chip, where reading was *never* reliable, even though
> flashing worked. This was at spispeed=30K, with ~8cm cables and both
> external and internal power. The chip would not be detected at higher
> speeds. No such issues at all with the W25X64.
>
On Mon, 4 Jan 2016 13:14:03 +0300
Andrey Korolyov <andrey(a)xdel.ru> wrote:
> >
> > thanks for the patch. Did you notice any breakage in the wild? I
> > hesitate to include your change because that could actually break some
> > configurations: in case HAVE_STRNLEN is not defined but strnlen is
> > provided nonetheless linking would fail. Actually I'd be surprised if it
> > would not make problems with other libc implementations.
>
> NetBSD before 6.0 is definitely the one which breaks here, as well as
> other late adopters of srtnlen(), like FreeBSD before 8.0. Please feel
> free to NAK the patch if you think that the support of ancient libcs
> is not something to worry about (and old BSDs are definitely not LTS
> distros with ten-year support span).
Thanks for the explanation. I have merged the respective change now in
r1917 because I could not find any problems with it on any of our
buildbot tests. Hopefully no one else will either :)
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Sat, 23 Jan 2016 19:32:14 +0300
Andrey Korolyov <andrey(a)xdel.ru> wrote:
> 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...
You might be interested in https://www.coreboot.org/FlexyICE
I have just discovered that project a few weeks ago myself so I cannot
give much more information than that. It is probably not purchasable
anymore but open enough that one could build something new from that.
Sooner or later I am planning to give a related projected out as
Bachelor or Master thesis but that will take a while (and would
probably be SPI-related).
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Fri, Jan 15, 2016 at 8:42 PM, Andrey Korolyov <andrey(a)xdel.ru> wrote:
> On Fri, Jan 15, 2016 at 8:11 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006(a)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(a)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(a)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...