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
> 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.
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
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 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.
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.
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
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 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:
Cheers and see you at FOSDEM!
Paul Kocialkowski, developer of free digital technology and hardware
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/https://git.code.paulk.fr/
On 9/28/18 11:20 PM, ron minnich wrote:
> I spoke too soon. It just flat out does not work to have sf100 and 256Mbit
> part AFAICT
Ah, crap. I just gave this another thought and now I'm convinced that it
can't work with the current code. dediprog_spi uses its own functions
for read/write that likely don't call into the common, 4BA aware code.
I'll try to provide a patch later tonight...
successfully flashed my Lenovo T430s with a Raspberry Pi on Raspian
Jessie (Raspian Stretch dont work)
After Coreboot was implemented, ist was also possible to flash internal :-)
Thank you very much!
Greetings from Munich (Germany)
I spoke too soon. It just flat out does not work to have sf100 and 256Mbit
On Fri, Sep 28, 2018 at 11:19 AM ron minnich <rminnich(a)gmail.com> wrote:
> Got the fix. I used dpcmd to update the firmware on the FS100 to 5.5.3
> Then flashrom can program it with ease.
> And, ironically, while dpcmd can update the firmware, it still can't flash
> the part :-)
On 27.09.2018 22:34, Nico Huber wrote:
> On 9/27/18 10:11 PM, ron minnich wrote:
>> yeah, also is there a programmer you recommend for 32MiB parts?
> Any programmer that can handle arbitrary SPI commands, e.g. single-
> board computers with native SPI interface (RPi, BeagleBone Black etc.),
> CH341A is popular but slow, FTDI based programmers are faster (FT232H/
> FT2232H/FT4232H), serprog programmers (some may not be too slow), Bus-
> Pirate rather slow too.
If you want programming to be fast (almost on par with Dediprog): Either
Raspberry Pi or Beaglebone Black.
The Beaglebone Black has an abysmal internal power supply and for any
in-circuit flashing you'll need an additional 3.3V supply for the flash
chip. For standalone chips it usually is sufficient, though.
The Raspberry Pi has SPI disabled by default, you need to add
dtparam=spi=on to the file /boot/config.txt .
>> On Thu, Sep 27, 2018 at 1:10 PM Nico Huber <nico.h(a)gmx.de> wrote:
>>> Ah, dediprog... you happen to have the one programmer that is hard to
>>> On 9/27/18 9:49 PM, ron minnich wrote:
>>>> hmm, is this useful?
>>>> Found Spansion flash chip "S25FL256S......0" (32768 kB, SPI) on dediprog.
>>>> Erasing and writing flash chip... 4-byte address requested but master
>>>> handle 4-byte addresses.
>>> That is expected, native 4-byte instructions are tried first but they
>>> are not implemented yet for dediprog. It should fall back to another
>>> instruction though. Unless the dediprog resets the chip between in-
>>> structions, it should actually work. Though, David seemed to have
>>> trouble with that too, I didn't test it myself yet.
>>>> Looking for another erase function.
>>> Can you please just post the whole log (best taken with -o logfile).
I have problem with flashing W25Q256JVFQwith latest git version of flashrom.
root/Temp/flashrom/flashrom -p buspirate_spi:dev=/dev/ttyACM0 -c
W25Q256.V -w Upall_VTH52X1D.20180622.bin
flashrom p1.0-100-gcabe320 on Linux 4.14.0-kali3-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Bus Pirate firmware 6.1 and older does not support SPI speeds above 2
MHz. Limiting speed to 2 MHz.
It is recommended to upgrade to firmware 6.2 or newer.
Found Winbond flash chip "W25Q256.V" (32768 kB, SPI) on buspirate_spi.
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to flashrom(a)flashrom.org if any of the above
work correctly for you with this flash chip. Please include the flashrom log
file for all operations you tested (see the man page for details), and
which mainboard or programmer you tested in the subject line.
Thanks for your help!
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x0025d000! Expected=0xff,
Found=0xf0, failed byte count from 0x0025d000-0x0025dfff: 0x31b
Reading current flash chip contents... done. Looking for another erase
FAILED at 0x006dc800! Expected=0xff, Found=0x48, failed byte count from
Reading current flash chip contents... done. Looking for another erase
Verifying flash... FAILED at 0x002bbe59! Expected=0x3b, Found=0x00,
failed byte count from 0x00000000-0x01ffffff: 0xa114
Your flash chip is in an unknown state.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org, thanks!
First of all, is your laptop a Dell Latitude D630? Specifying the
model number may be ambiguous.
With regard to reflashing the BIOS, may I ask how exactly would
reflashing help? AFAIUI, rewriting the same code would make no
difference, and there isn't a free replacement such as coreboot for
Angel Pons Pons