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.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
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 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/
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 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/
Hi,
Having a 64Mbit IS25LP064A and using flashrom 1.0, when calling
sudo flashrom -p ft2232_spi:type=2232H,port=A,divisor=100
I get:
flashrom v1.0 on Linux 4.15.0-33-generic (x86_64)
...
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on ft2232_spi.
...
:(
Writing and reading commands break with the same message.
So I checked the table at https://www.flashrom.org/Supported_hardware
The chip is not supported yet. But it says that chips supporting JESD216 should work.
Measuring the signal I got that the command given above does first a RDJDID Operation and later the RDSFDP operation (which should be according to JESD216).
I attach the signals. You can see the the operations and what is done.
According to the datasheet is MF7-MF0: 9Dh and Memory Type + Capacity (ID15 - ID0): 6017h. Which you can see on the RDJDID signals image.
I know the signal quality is not the best but doing real improves would cost a lot of time. As I already successfully programmed another supported chip and because the Flash chip response the right way I think that it´s not a signal integrity problem.
So my questions are:
1) Does "unknown SPI chip (RDID)" mean "it´s not in the database" or does it mean "RDID could not be read successfully"?
2) If it means "RDID could not be read successfully": Is there any other possibility than signal integrity why flashrom does not show the right RDID?
3) If it means "it´s not in the database": Would adding it to the database solve the problem or is that not crucial?
4) Does flashrom supports flashs with memory of 64Mbit? As I can´t find any in the supported hardware list.
The datasheet of the flash can be obtained from:
https://www.mouser.de/datasheet/2/198/25LP032-64A-B-737452.pdf
Btw: the JESD216 link at https://www.flashrom.org/Supported_hardware does not work. May be https://www.jedec.org/standards-documents/docs/jesd216b is what should be linked?
Regards,
Simon
Hello ,
Device programming is successful with flashrom, but I wanted to report this and see if there should be any concern here..
flashrom v0.9.7-r1782 on Linux 3.0.0-19-generic (i686)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found chipset "Intel ICH8M". Enabling flash write... BBAR offset is unknown on ICH8!
OK.
Found GigaDevice flash chip "GD25Q80(B)" (1024 kB, SPI) at physical address 0xfff00000.
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Trying to unmap a nonexisting mapping!
Please report a bug at flashrom(a)flashrom.org
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
Script started, file is /root/flashrom-2018-08-23T1626-003_10b.rom.log
Script started, file is /root/flashrom-2018-08-23T1626-003_10b.rom.log
Script done, file is /root/flashrom-2018-08-23T1626-003_10b.rom.log
Sleeping 5 sec and shutting down to trigger BIOS flash.
Best Regards
Clay Dean
Vice President, Operations
c.dean(a)wegener.com<mailto:c.dean@wegener.com>
770 623 0096 x4419 Office
706 878 8115 Mobile
claydean Skype
P Please think about our environment before considering printing this mail.
This email and the associated attachments may contain information that is proprietary, privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient or otherwise have received this message in error, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you are not the intended recipient or otherwise have received this message in error, please notify us immediately, destroy any paper copies and delete all electronic files of the message
________________________________
Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.
Hello B.,
I guess you might have solved your problem by now, anyway:
On 13.07.2018 15:56, B. Ford wrote:
> I am trying to read a MX25L6473F bios chip, it is in your supported list
> of chips. However when i read the chip (ch341a programmer) it asks to
> specify the chip type using the -c command, but the MX25L6473F is not in
> the selected ones, and therfore i cannot continue to read..
MX25L6473F was added rather late indeed. Though, it's one of those
chips that share their ID with many others. For flashrom-0.9.9 this
should work:
-c MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E
They are all compatible to the 73F as far as flashrom is concerned.
Nico
Hi,
On 14.08.2018 19:50, Владимир Амельянович wrote:
> I would be nice to get the patch. I will check my board tomorrow.
> I have 3 different boards. Would you like to get reports from all of them?
it seems the issue is already mitigated by other changes in the core
of flashrom (though, the actual bug is still there). For the moment,
it would be nice if you could try flashrom-1.0 to see if the issue
persists.
Nico
