On Mon, 9 May 2016 20:46:18 -0700
David Hendricks <dhendrix(a)google.com> wrote:
> Hi Victor,
> From Flashrom's software perspective all chips with the same ID are
> indistinguishable.
>
> Part number often includes characteristics such as package and thermal
> tolerance which do not affect software compatibility.
However, we will add the new names to the in-program (and hence
wiki) database so that this new information becomes public. Thanks for
the heads up, Victor.
…
[View More]
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
[View Less]
Hi,
we're hitting the 80 column limit in our code in ways which actually
reduce readability for the code. Examples are various multiline messages
and complicated nested code where refactoring to a separate function
doesn't make sense.
Keeping the old 80 column limit is not really an option anymore.
Standard terminal sizes have one of 80, 100 or 132 columns.
Given the monitor resolutions many people have nowadays, I think it is
safe to say that you can fit two xterms with 100 columns …
[View More]horizonally
next to each other. 100 columns should also be sufficient for a msg_p*
of roughly 80 columns of text.
132 columns provide more leeway, but IMHO that would be too wide for
good readability (and my screen can't fit two xterms side-by-side anymore).
Of course some files have sections where any column limit is not
acceptable (board lists etc.), but the column limit violations should be
limited to the affected file sections, not whole files.
Comments?
I'd like to get this decided today or tomorrow so we know where we need
line breaks in Stefan Tauner's new struct flashchip patch.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
[View Less]
A Hardware Enablement devroom will be taking place at FOSDEM this year,
on Sunday 10 December 2017. This newly-created devroom is the result of
3 proposals that were merged together. It is co-organized by several
individuals.
The devroom covers all aspects related to hardware enablement and
support with free software, including aspects related to boot software,
firmwares, drivers and userspace tools and adaptation.
Proposals for talks related to these topics are welcome and can be
submitted …
[View More]until Sunday 26 November 2017 via the pentabarf interface.
Short talks are encouraged over longer ones in order to cover a wide
range of topics.
The announcement for the devroom, that contains all the useful
information, was published at:
https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html
Cheers and see you at FOSDEM!
--
Paul Kocialkowski, developer of free digital technology and hardware
support
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/https://git.code.paulk.fr/
[View Less]
Hi Yaron, its very interesting why MOSI voltage is low. Have you tried
disconnecting the peripheral devices like RAM ? about Bus Pirate -
which firmware you have? (Bus Pirate old firmware is not good quality,
its much more stable if you flash a new "Community Firmware" to it -
github BusPirate/Bus_Pirate ) Also please try getting CH341A - it is
very cheap flasher which should be reliable thanks to its' simplicity.
Another idea: there are small circuit boards called " Step-Up Voltage
Regulator " …
[View More]- some versions of them convert 0.5-3.3V to 3.3V ---
however if you increase the voltage, it would be less current (maybe
not enough to transmit a signal). Still I really hope that you could
flash it without complicating a setup by adding the new boards... Best
regards, Ivan
2017-11-24 17:56 GMT+03:00 Yaron Shragai <yshragai.firmware(a)gmail.com>:
> Thank you Ivan.
>
> As I mentioned, I did try with/without the board plugged in, and
> with/without the VCC pin connected to the programmer. (I also tried, on an
> identical board that still has a booting BIOS, powering it on to a point
> that likely has no BMC traffic.)
>
> One thing that we have determined, using a scope, is that the VCC pin does
> likely get appropriate voltage, but the signals on the MOSI pin are not at a
> high enough voltage: The voltage at the MOSI pin, when signals are being
> sent, is about 1/2 VCC. This explains why it almost always isn't successful
> at finding the chip, but every once in a while, on a rare occasion, it is.
> So now the question is, why is the voltage on the MOSI pin too low - what is
> pulling it down.
>
> I'm getting identical results with both the Dediprog SF100 and a Bus Pirate
> (not sure which version). And I did try the trick on the Bus Pirate where
> you apply the VCC voltage to the Bus Pirate's VUP (pull-up voltage) pin, and
> used the flashrom argument to turn on the pull-ups.
>
> Thanks,
> Yaron
>
>
> On Wed, Nov 22, 2017 at 10:29 AM, Ivan Ivanov <qmastery16(a)gmail.com> wrote:
>>
>> Hi Yaron, please read about the In-System Programming. It could be
>> that the peripheral devices of your motherboard are consuming some
>> percentage of the power that was aimed to power a BIOS chip during the
>> access - because of that, there is not enough power for a BIOS chip
>> and your attempts are failing. What to do:
>>
>> I) You could try to reduce the amount of peripheral devices - e.g.
>> disconnect the RAM modules from your system and try again
>>
>> II) Also you can try to power a BIOS chip by the motherboard :
>> 1) disconnect a VCC wire from your programmer, also disconnect WP and
>> HOLD just in case
>> 2) disconnect all the boot devices from your motherboard
>> 3) connect a clip to a BIOS chip
>> 4) connect a power adapter to your motherboard and turn it on
>> 5) just in case, wait 5 minutes so that all the initialization
>> processes will be completed
>> 6) read the contains of a BIOS chip a few times
>> 7) compare the checksums of read files, if they are the same - erase
>> the BIOS chip (by filling it with FF's), turn off the motherboard,
>> then turn it on again, wait 5 minutes - then flash your desired binary
>> image to this BIOS chip
>>
>> III) Alternatively you may want to de-solder a BIOS chip from
>> motherboard and connect it to your programmer with DIP adapter, but
>> probably could be avoided if you do I) or II) successfully
>>
>> IV) Try a different programmer, e.g. CH341A which is super cheap
>> simple hardware fully supported by flashrom - should be reliable
>>
>> I wish you good luck, sadly Supermicro X10DRT-Lis not supported by
>> coreboot open source BIOS - hopefully you will be able to get a better
>> hardware one day...
>>
>> Best regards,
>>
>> 2017-11-21 17:57 GMT+03:00 Yaron Shragai <yshragai.firmware(a)gmail.com>:
>> > Hello,
>> > I am trying to use flashrom to program a Winbond W25Q128FV chip, on a
>> > Supermicro X10DRT-L mobo, with a Dediprog SF 100.
>> >
>> > I am running flashrom from an Ubuntu VM on a Win10 laptop as well as
>> > from a
>> > Minnowboard Max system running Ubuntu.
>> > I am running flashrom v0.9.9-rc1-r1942, installed via apt.
>> > I am connecting to the chip via a SOIC clip.
>> >
>> > I should note that I have looked at the product support data on the
>> > flashrom
>> > web site. It lists full support for the W25Q128FV. It does not list
>> > the
>> > X10DRT-L mobo.
>> >
>> > flashrom almost never "sees" the flash chip (output: "No EEPROM/flash
>> > device
>> > found.").
>> >
>> > I say "almost", b/c it did see it a couple of times (out of, I would
>> > say,
>> > ~100 tries) - which was enough for me to read out the pre-existing
>> > content,
>> > and write to it an image that has effectively bricked it. :-) So, now
>> > I'm
>> > trying to flash the pre-existing content back... (There is no
>> > documented
>> > way to force the X10DRT-L to use the recovery block, and I have yet to
>> > find
>> > an undocumented way...)
>> >
>> > I have tried with the system board plugged in and unplugged, and with
>> > and
>> > without connecting the VCC pin to the programmer.
>> >
>> > I have been using these two command lines, at various times:
>> > flashrom -p dediprog
>> > flashrom -p dediprog:voltage=3.5
>> >
>> > When I add -VVV, the following relevant lines appear in the output:
>> >
>> > Probing for Winbond W25Q128.V, 16384 kB: programmer_map_flash_region:
>> > mapping W25Q128.V from 0x00000000ff000000 to 0x0000000000000000
>> > dediprog_spi_send_command, writecnt=1, readcnt=3
>> > RDID returned 0xff 0xff 0xff. RDID byte 0 parity violation.
>> > probe_spi_rdid_generic: id1 0xff, id2 0xffff
>> > programmer_unmap_flash_region: unmapped 0x0000000000000000
>> >
>> > ...and further down...
>> >
>> > Probing for Winbond unknown Winbond (ex Nexcom) SPI chip, 0 kB:
>> > dediprog_spi_send_command, writecnt=1, readcnt=3
>> > RDID returned 0xff 0xff 0xff. RDID byte 0 parity violation.
>> > probe_spi_rdid_generic: id1 0xff, id2 0xffff
>> >
>> > One more datapoint: When I connect my laptop -> Dediprog -> to the flash
>> > chip on the Minnowboard Max (Micron 25Q064A), it does recognize the
>> > chip.
>> >
>> > Any advice would be appreciated!
>> >
>> > Thanks,
>> > Yaron
>> >
>> > _______________________________________________
>> > flashrom mailing list
>> > flashrom(a)flashrom.org
>> > https://mail.coreboot.org/mailman/listinfo/flashrom
>
>
[View Less]
Thank you Ivan.
As I mentioned, I did try with/without the board plugged in, and
with/without the VCC pin connected to the programmer. (I also tried, on an
identical board that still has a booting BIOS, powering it on to a point
that likely has no BMC traffic.)
One thing that we have determined, using a scope, is that the VCC pin does
likely get appropriate voltage, but the signals on the MOSI pin are not at
a high enough voltage: The voltage at the MOSI pin, when signals are being
sent, is …
[View More]about 1/2 VCC. This explains why it almost always isn't
successful at finding the chip, but every once in a while, on a rare
occasion, it is.
So now the question is, why is the voltage on the MOSI pin too low - what
is pulling it down.
I'm getting identical results with both the Dediprog SF100 and a Bus Pirate
(not sure which version). And I did try the trick on the Bus Pirate where
you apply the VCC voltage to the Bus Pirate's VUP (pull-up voltage) pin,
and used the flashrom argument to turn on the pull-ups.
Thanks,
Yaron
On Wed, Nov 22, 2017 at 10:29 AM, Ivan Ivanov <qmastery16(a)gmail.com> wrote:
> Hi Yaron, please read about the In-System Programming. It could be
> that the peripheral devices of your motherboard are consuming some
> percentage of the power that was aimed to power a BIOS chip during the
> access - because of that, there is not enough power for a BIOS chip
> and your attempts are failing. What to do:
>
> I) You could try to reduce the amount of peripheral devices - e.g.
> disconnect the RAM modules from your system and try again
>
> II) Also you can try to power a BIOS chip by the motherboard :
> 1) disconnect a VCC wire from your programmer, also disconnect WP and
> HOLD just in case
> 2) disconnect all the boot devices from your motherboard
> 3) connect a clip to a BIOS chip
> 4) connect a power adapter to your motherboard and turn it on
> 5) just in case, wait 5 minutes so that all the initialization
> processes will be completed
> 6) read the contains of a BIOS chip a few times
> 7) compare the checksums of read files, if they are the same - erase
> the BIOS chip (by filling it with FF's), turn off the motherboard,
> then turn it on again, wait 5 minutes - then flash your desired binary
> image to this BIOS chip
>
> III) Alternatively you may want to de-solder a BIOS chip from
> motherboard and connect it to your programmer with DIP adapter, but
> probably could be avoided if you do I) or II) successfully
>
> IV) Try a different programmer, e.g. CH341A which is super cheap
> simple hardware fully supported by flashrom - should be reliable
>
> I wish you good luck, sadly Supermicro X10DRT-Lis not supported by
> coreboot open source BIOS - hopefully you will be able to get a better
> hardware one day...
>
> Best regards,
>
> 2017-11-21 17:57 GMT+03:00 Yaron Shragai <yshragai.firmware(a)gmail.com>:
> > Hello,
> > I am trying to use flashrom to program a Winbond W25Q128FV chip, on a
> > Supermicro X10DRT-L mobo, with a Dediprog SF 100.
> >
> > I am running flashrom from an Ubuntu VM on a Win10 laptop as well as
> from a
> > Minnowboard Max system running Ubuntu.
> > I am running flashrom v0.9.9-rc1-r1942, installed via apt.
> > I am connecting to the chip via a SOIC clip.
> >
> > I should note that I have looked at the product support data on the
> flashrom
> > web site. It lists full support for the W25Q128FV. It does not list the
> > X10DRT-L mobo.
> >
> > flashrom almost never "sees" the flash chip (output: "No EEPROM/flash
> device
> > found.").
> >
> > I say "almost", b/c it did see it a couple of times (out of, I would say,
> > ~100 tries) - which was enough for me to read out the pre-existing
> content,
> > and write to it an image that has effectively bricked it. :-) So, now
> I'm
> > trying to flash the pre-existing content back... (There is no documented
> > way to force the X10DRT-L to use the recovery block, and I have yet to
> find
> > an undocumented way...)
> >
> > I have tried with the system board plugged in and unplugged, and with and
> > without connecting the VCC pin to the programmer.
> >
> > I have been using these two command lines, at various times:
> > flashrom -p dediprog
> > flashrom -p dediprog:voltage=3.5
> >
> > When I add -VVV, the following relevant lines appear in the output:
> >
> > Probing for Winbond W25Q128.V, 16384 kB: programmer_map_flash_region:
> > mapping W25Q128.V from 0x00000000ff000000 to 0x0000000000000000
> > dediprog_spi_send_command, writecnt=1, readcnt=3
> > RDID returned 0xff 0xff 0xff. RDID byte 0 parity violation.
> > probe_spi_rdid_generic: id1 0xff, id2 0xffff
> > programmer_unmap_flash_region: unmapped 0x0000000000000000
> >
> > ...and further down...
> >
> > Probing for Winbond unknown Winbond (ex Nexcom) SPI chip, 0 kB:
> > dediprog_spi_send_command, writecnt=1, readcnt=3
> > RDID returned 0xff 0xff 0xff. RDID byte 0 parity violation.
> > probe_spi_rdid_generic: id1 0xff, id2 0xffff
> >
> > One more datapoint: When I connect my laptop -> Dediprog -> to the flash
> > chip on the Minnowboard Max (Micron 25Q064A), it does recognize the chip.
> >
> > Any advice would be appreciated!
> >
> > Thanks,
> > Yaron
> >
> > _______________________________________________
> > flashrom mailing list
> > flashrom(a)flashrom.org
> > https://mail.coreboot.org/mailman/listinfo/flashrom
>
[View Less]
Hi Ron,
Can you check the full part number? There appears to be a couple versions
of this chip, one with ID 0x4018 (like the existing W25Q128.V chips) and
another version with additional instructions that identifies with 0x7018.
I found a W25Q128JVSIQ and it reads/writes successfully with the existing
code. If your chip ends with an 'M' instead of a 'Q' then you can try this,
which just does as Nico suggested: https://review.coreboot.org/#/c/22567/
On Fri, Nov 17, 2017 at 9:49 AM, ron …
[View More]minnich <rminnich(a)gmail.com> wrote:
> any suggestions on making this part work? I have not done this in a while.
>
> _______________________________________________
> flashrom mailing list
> flashrom(a)flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
[View Less]
Hi Yaron, please read about the In-System Programming. It could be
that the peripheral devices of your motherboard are consuming some
percentage of the power that was aimed to power a BIOS chip during the
access - because of that, there is not enough power for a BIOS chip
and your attempts are failing. What to do:
I) You could try to reduce the amount of peripheral devices - e.g.
disconnect the RAM modules from your system and try again
II) Also you can try to power a BIOS chip by the …
[View More]motherboard :
1) disconnect a VCC wire from your programmer, also disconnect WP and
HOLD just in case
2) disconnect all the boot devices from your motherboard
3) connect a clip to a BIOS chip
4) connect a power adapter to your motherboard and turn it on
5) just in case, wait 5 minutes so that all the initialization
processes will be completed
6) read the contains of a BIOS chip a few times
7) compare the checksums of read files, if they are the same - erase
the BIOS chip (by filling it with FF's), turn off the motherboard,
then turn it on again, wait 5 minutes - then flash your desired binary
image to this BIOS chip
III) Alternatively you may want to de-solder a BIOS chip from
motherboard and connect it to your programmer with DIP adapter, but
probably could be avoided if you do I) or II) successfully
IV) Try a different programmer, e.g. CH341A which is super cheap
simple hardware fully supported by flashrom - should be reliable
I wish you good luck, sadly Supermicro X10DRT-Lis not supported by
coreboot open source BIOS - hopefully you will be able to get a better
hardware one day...
Best regards,
2017-11-21 17:57 GMT+03:00 Yaron Shragai <yshragai.firmware(a)gmail.com>:
> Hello,
> I am trying to use flashrom to program a Winbond W25Q128FV chip, on a
> Supermicro X10DRT-L mobo, with a Dediprog SF 100.
>
> I am running flashrom from an Ubuntu VM on a Win10 laptop as well as from a
> Minnowboard Max system running Ubuntu.
> I am running flashrom v0.9.9-rc1-r1942, installed via apt.
> I am connecting to the chip via a SOIC clip.
>
> I should note that I have looked at the product support data on the flashrom
> web site. It lists full support for the W25Q128FV. It does not list the
> X10DRT-L mobo.
>
> flashrom almost never "sees" the flash chip (output: "No EEPROM/flash device
> found.").
>
> I say "almost", b/c it did see it a couple of times (out of, I would say,
> ~100 tries) - which was enough for me to read out the pre-existing content,
> and write to it an image that has effectively bricked it. :-) So, now I'm
> trying to flash the pre-existing content back... (There is no documented
> way to force the X10DRT-L to use the recovery block, and I have yet to find
> an undocumented way...)
>
> I have tried with the system board plugged in and unplugged, and with and
> without connecting the VCC pin to the programmer.
>
> I have been using these two command lines, at various times:
> flashrom -p dediprog
> flashrom -p dediprog:voltage=3.5
>
> When I add -VVV, the following relevant lines appear in the output:
>
> Probing for Winbond W25Q128.V, 16384 kB: programmer_map_flash_region:
> mapping W25Q128.V from 0x00000000ff000000 to 0x0000000000000000
> dediprog_spi_send_command, writecnt=1, readcnt=3
> RDID returned 0xff 0xff 0xff. RDID byte 0 parity violation.
> probe_spi_rdid_generic: id1 0xff, id2 0xffff
> programmer_unmap_flash_region: unmapped 0x0000000000000000
>
> ...and further down...
>
> Probing for Winbond unknown Winbond (ex Nexcom) SPI chip, 0 kB:
> dediprog_spi_send_command, writecnt=1, readcnt=3
> RDID returned 0xff 0xff 0xff. RDID byte 0 parity violation.
> probe_spi_rdid_generic: id1 0xff, id2 0xffff
>
> One more datapoint: When I connect my laptop -> Dediprog -> to the flash
> chip on the Minnowboard Max (Micron 25Q064A), it does recognize the chip.
>
> Any advice would be appreciated!
>
> Thanks,
> Yaron
>
> _______________________________________________
> flashrom mailing list
> flashrom(a)flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
[View Less]
Hi.
I did a flashrom -p internal. My laptop is not supported ;(
As requested, here's the output of flashrom -V -p internal.
"
flashrom v0.9.8-r1888 on Linux 4.4.92-31-default (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
flashrom was built with libpci 3.2.1, GCC 4.8.5, little endian
Command line (3 args): flashrom -V -p internal
Calibrating delay loop... OS timer resolution is 1 usecs, 1406M loops
per second, 10 myus = 9 us, 100 myus = 97 us, 1000 myus =…
[View More] 1087 us, 10000
myus = 10091 us, 4 myus = 3 us, OK.
Initializing internal programmer
No coreboot table found.
Using Internal DMI decoder.
DMI string chassis-type: "Notebook"
Laptop detected via DMI.
DMI string system-manufacturer: "Acer"
DMI string system-product-name: "Aspire E5-553G"
DMI string system-version: "V1.13"
DMI string baseboard-manufacturer: "Acer"
DMI string baseboard-product-name: "Wasp_BR"
DMI string baseboard-version: "V1.13"
W836xx enter config mode worked or we were already in config mode.
W836xx leave config mode had no effect.
Active config mode, unknown reg 0x20 ID: 89.
Please send the output of "flashrom -V -p internal" to
flashrom(a)flashrom.org with W836xx: your board name: flashrom -V
as the subject to help us finish support for your Super I/O. Thanks.
"
Regards,
August.
[View Less]
Hello,
I am trying to use flashrom to program a Winbond W25Q128FV chip, on a
Supermicro X10DRT-L mobo, with a Dediprog SF 100.
I am running flashrom from an Ubuntu VM on a Win10 laptop as well as from a
Minnowboard Max system running Ubuntu.
I am running flashrom v0.9.9-rc1-r1942, installed via apt.
I am connecting to the chip via a SOIC clip.
I should note that I have looked at the product support data on the
flashrom web site. It lists full support for the W25Q128FV. It does not
list the …
[View More]X10DRT-L mobo.
flashrom almost never "sees" the flash chip (output: "No EEPROM/flash
device found.").
I say "almost", b/c it did see it a couple of times (out of, I would say,
~100 tries) - which was enough for me to read out the pre-existing content,
and write to it an image that has effectively bricked it. :-) So, now I'm
trying to flash the pre-existing content back... (There is no documented
way to force the X10DRT-L to use the recovery block, and I have yet to find
an undocumented way...)
I have tried with the system board plugged in and unplugged, and with and
without connecting the VCC pin to the programmer.
I have been using these two command lines, at various times:
flashrom -p dediprog
flashrom -p dediprog:voltage=3.5
When I add -VVV, the following relevant lines appear in the output:
Probing for Winbond W25Q128.V, 16384 kB: programmer_map_flash_region:
mapping W25Q128.V from 0x00000000ff000000 to 0x0000000000000000
dediprog_spi_send_command, writecnt=1, readcnt=3
RDID returned 0xff 0xff 0xff. RDID byte 0 parity violation.
probe_spi_rdid_generic: id1 0xff, id2 0xffff
programmer_unmap_flash_region: unmapped 0x0000000000000000
...and further down...
Probing for Winbond unknown Winbond (ex Nexcom) SPI chip, 0 kB:
dediprog_spi_send_command, writecnt=1, readcnt=3
RDID returned 0xff 0xff 0xff. RDID byte 0 parity violation.
probe_spi_rdid_generic: id1 0xff, id2 0xffff
One more datapoint: When I connect my laptop -> Dediprog -> to the flash
chip on the Minnowboard Max (Micron 25Q064A), it does recognize the chip.
Any advice would be appreciated!
Thanks,
Yaron
[View Less]