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/
Hello Matt,
your mail never made it to the list, due to it's excessive size. Please
don't send such huge attachments.
On 20.03.2018 00:10, Matt Risen wrote:
> Is there any chance we could get support for the Winbond 25Q40EWNIG SPI
> eeprom?
Yes, we recently added support for the next bigger version 25Q80EW, and
I just pushed a patch for 25Q40EW [1].
With Git, you can fetch / apply it as follows:
git fetch https://review.coreboot.org/flashrom refs/changes/62/25462/1
git cherry-pick FETCH_HEAD
It's still untested, though.
Nico
[1] https://review.coreboot.org/25462/
On Wed, Mar 28, 2018 at 04:24:25PM +0200, Idwer Vollering wrote:
> I took the liberty to submit this change to gerrit;
> https://review.coreboot.org/#/c/flashrom/+/25396/
Please fix the author.
Luc Verhaegen.
On Tue, Mar 20, 2018 at 12:22:02PM +0100, Björn Tantau wrote:
>
>
> Am 19. März 2018 18:21:36 MEZ schrieb Luc Verhaegen <libv(a)skynet.be>:
> >On Mon, Mar 19, 2018 at 05:01:06PM +0100, Björn Tantau wrote:
> >> Am 19.03.2018 um 00:08 schrieb Luc Verhaegen:
> >> >
> >> >My current hypothesis: smsc at 0x480
> >> >
> >> >Action required: 0x48E |= 0x10.
> >
> >> Do you want to scan for Super I/O sensors? (YES/no): Probing for
> >Super-I/O at 0x2e/0x2f
> >> Trying family `VIA/Winbond/Nuvoton/Fintek'... Yes
> >> Found `Winbond W83627DHG Super IO Sensors' Success!
> >> (address 0x290, driver `w83627ehf')
> >
> >Hrm. Perpendicular to what the bios that i got from AOpen tells me.
> >
> >Please mail a copy of your existing rom to me personally (exclude the
> >flashrom ml, binary blobs should not go there).
>
> Here you go. Thanks for your help!
Ok, this shows how rusty i am with respect to flashrom. Not recognizing
the + 0x0C as the typical offset for intel gpio line toggle.
What this board needs is a call to intel_ich_gpio20_raise();
Will provide a patch later today.
I am a bit worried though that the lpc io BAR is empty in your lspci. I
am not sure whether that is handled in any way, and i do not think the
intel gpio code in flashrom will deal with an empty bar gracefully.
Luc Verhaegen.
Having trouble getting a good read from a Macronix MX25L3206E in situ
Thinkpad E420 Sandy Bridge/Cougar Point PCH. Don't believe it's a
programmer problem because I used the same programmer and pinouts to
successfully flash a Winbond W25Q32.V in a different system.
I found the Wistron LLW-1/LGG-1 schematic and matched the flash chip up
with the silk-screened label. Tried it in system with system power. I've
pulled the board and RAM. Also tried removing CPU. Symptoms of the problem
are:
- On system power, doesn't detect chip.
- Using an external PS, when I restrict the current to the point there's a
vdroop to ~3.0v-3.2v, flashrom detects the chip. If I give it more current
(at 3.3v), the chip disappears and flashrom no longer sees it.
- Occasionally it acts like a successful read, WRSR updates correctly but
resulting file is mostly FF with a section of pages of 00 and some with
alternating bit patterns. Oddly, the file is consistent over multiple runs
and diff reports no differences, but there is nothing in it that looks
like actual data and ifdtool says there's no descriptor.
Suspect the issue is as described on https://www.flashrom.org/ISP- that ME
is getting powered and locking/hiding the chip. It suggests connecting the
reset line to CS. Searching the schematic for RST results in numerous
pages. How can I identify the right place to accomplish this, preferably
without soldering?
Alternatively, I see in the SPI programming guide there might be a couple
other ways to disable ME?
1. Temporarily disable the Intel® ME through the MEBX. Power off or cold
reset. - This option is only applicable to non-Intel ME Ignition firmware.
2. HDA_SDO(Manufacturing mode jumper or Flash descriptor override jumper)
asserted HIGH on the rising edge of PWROK. Power off or cold reset.
Note: this is only valid as long as you do not specifically set the
variable Flash Descriptor Overrride Pin-Strap Ignore in the Flash Image
Tool to false.
I found #2 on the schematic with a not installed resistor (what does "DY"
stand for anyways, "Damn You"?) but can't find the label for it on the
motherboard and it looked like it would also need soldering beyond my
capability.
Any suggestions?
Sorry for late reply. Yes, it looks like your connection is bad.
Try using the shorter wires, and hopefully of a good quality
( e.g. pure copper wires could be 1.5 longer than the cheap aluminium wires
and still have the same conductivity given the same internal thickness )
You have mentioned that you have updated the Bus Pirate firmware.
To what version did you upgrade? I always recommend upgrading
to the latest Bus Pirate community firmware (the old official one is dead)
You could obtain it here - https://github.com/BusPirate/Bus_Pirate
Alternatively, you may try a $3 very cheap CH341A USB programmer,
which is also supported by flashrom project and has a much simpler hardware,
i.e. it does not have the internal firmware, just a tiny EEPROM of 20
or 32 bytes size +
8 bit CFG register. The board of CH341A usb programmer is small and
extremely simple,
and the simplicity could be a key to success
Best regards,
Ivan
2018-03-17 14:31 GMT+03:00 <aadu(a)airmail.cc>:
>
> I apologise if I should write to flashrom mailing list instead and not you
> directly.
>
> It was night when I wrote that message and I was tired. Bit more of what I
> was doing.
>
> I was trying to do external flashing following instructions from coreboot
> wiki.
> I used command "sudo flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -r
> filename", and I got:
> Calibrating delay loop... OK.
> Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on
> buspirate_spi.
> ===
> This flash part has status NOT WORKING 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
> operations
> work correctly for you with this flash part. Please include the flashrom
> output with the additional -V option for all operations you tested (-V, -Vr,
> -VE, -Vw), and mention which mainboard or programmer you tested.
> Please mention your board in the subject line. Thanks for your help!
> Read is not working on this chip. Aborting.
>
> Was that because it had bad connection or am I doing something really
> stupid?
> Then I used "flashrom -L" and it showed that T420 support was marked as
> "BAD".
> I bought Bus Pirate v3b and Pomona 5250 SOIC test clip. Have updated the Bus
> Pirate firmware.
>
> Aadu
>
Hello team
Here's the output of flashrom on my machine, as well as my system
information.
I will of course not use it, I am sharing this based on your request in
here https://www.flashrom.org/Board_Testing_HOWTO
This is the manufacturer website
https://www.acer.com/ac/en/US/content/support-product/5977?b=1
Let me know if you need further,
Thank you,
sudo flashrom -p internal
flashrom p1.0-22-g0bfa819 on Linux 4.14.27-1-MANJARO (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).
========================================================================
WARNING! You seem to be running flashrom on an unsupported laptop.
Laptops, notebooks and netbooks are difficult to support and we
recommend to use the vendor flashing utility. The embedded controller
(EC) in these machines often interacts badly with flashing.
See the manpage and https://flashrom.org/Laptops for details.
If flash is shared with the EC, erase is guaranteed to brick your laptop
and write may brick your laptop.
Read and probe may irritate your EC and cause fan failure, backlight
failure and sudden poweroff.
You have been warned.
========================================================================
Aborting.
Error: Programmer initialization failed.
inxi -Fx
System: Kernel: 4.14.27-1-MANJARO x86_64 bits: 64 gcc: 7.3.0
Desktop: Xfce 4.12.4 (Gtk 2.24.31) Distro: Manjaro Linux
Machine: Device: laptop System: Acer product: Aspire E5-573G v: V3.72
serial: N/A
Mobo: Acer model: ZORO_BH v: Type2 - A01 Board Version
serial: N/A
UEFI [Legacy]: Insyde v: V1.15 date: 05/27/2015
Battery BAT1: charge: 33.1 Wh 100.0% condition: 33.1/37.0 Wh (90%)
model: SANYO AL15A32 status: Full
CPU: Dual core Intel Core i7-5500U (-MT-MCP-) arch: Broadwell
rev.4 cache: 4096 KB
flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 9580
clock speeds: max: 3000 MHz 1: 2794 MHz 2: 2718 MHz 3: 2738
MHz 4: 2940 MHz
Hi!
I tried to flash a new BIOS to my AOpen i965GMt-LA motherboard. Reading
the ROM worked, but flashing did not. I'll gladly give you more
information, just tell me what you need. :-)
Cheers,
Björn
$ sudo flashrom --programmer internal -c "W39V040FA" -w IGC1B.BIN
flashrom v0.9.9-rc1-r1942 on Linux 4.4.0-112-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Calibrating delay loop... OK.
Found chipset "Intel ICH8M".
Enabling flash write... OK.
Found Winbond flash chip "W39V040FA" (512 kB, FWH) mapped at physical
address 0x00000000fff80000.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff,
Found=0x49, failed byte count from 0x00000000-0x00000fff: 0x463
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
FAILED at 0x00000000! Expected=0xff, Found=0x49, failed byte count from
0x00000000-0x0000ffff: 0x463
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
FAILED at 0x00000000! Expected=0xff, Found=0x49, failed byte count from
0x00000000-0x0007ffff: 0x60915
ERASE FAILED!
Looking for another erase function.
No usable erase functions left.
FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
Reading current flash chip contents... done.
Good, writing to the flash chip apparently didn't do anything.
This means we have to add special support for your board, programmer or
flash
chip. Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org, thanks!
-------------------------------------------------------------------------------
You may now reboot or simply leave the machine running.
