Hi,
I am trying to unbrick latest Acer C720 with flashrom. What I have already
done:
- Created ROM image successfully for writing with flashrom;
- Connected wires from Raspberry Pi to EEPROM chip on C720.
- Enabled kernel modules and tested with spidev_test (it returns data,
looks normal - not all 00's or FF's)
- Download latest flashrom from svn and compiled.
- Then executed: ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0
After a lot output it said to me:
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on linux_spi.
Probing for Generic unknown SPI chip (REMS), 0 kB: REMS returned 0xff 0xff.
probe_spi_rems: id1 0xff, id2 0xff
Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, 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 chip. Please include the flashrom log
file for all operations you tested (see the man page for details), and
mention
which mainboard or programmer you tested in the subject line.
Thanks for your help!
No operations were specified.
I saw that sometimes chip numbers are not entered to the flashrom source,
maybe it's the same case? I think I have read all sites I found on Google
about unbricking acer c720. What I should try next?
Some details:
- Ubuntu 14 OS on Raspberry Pi B version.
- Acer chromebook c720 (model no: zhn)
Please help me solve the issue. I am attaching complete log
command: ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0 > log
--
*Remigijus Jarmalavičius*
Hello,
Le mercredi 18 février 2015 à 01:31, Stefan Tauner a écrit:
> Coverity has brought up the following problems:
Sorry, I wasn't aware that there were coverity reports for the project.
> This patch revamps the function in various ways to fix these issues and some
> other irritating bits.
> It reduces scopes of variables where possible, pushes the code towards our
> coding standards and introduces a label-based resource cleanup at the end.
I agree, this patch does make the code easier to read, in addition to
fixing my mistakes :)
Best regards,
Alex
--
Alexandre Boeglin
email: alex (at) boeglin (dot) org
jabber: alex (at) im (dot) boeglin (dot) org
website: http://boeglin.org/
On Thu, 19 Feb 2015 01:04:34 +0300
"nicolae788 ." <nicolae788(a)gmail.com> wrote:
> Thank you very much for your response. I will check the link and hope to
> manage and enable it. One last question: if a board recognizes a 512kb chip
> is it normal to not recognize the above described ( SST 49LF008A ) 1Mb chip
> ??? I have a board with which i could do the flash procedure, it is
> fully supported by flashrom, flash chip, chipset, board, but it doesn;t
> seem to find the chip i want to flash. The original 512 Kb chip it's listed
> when i run flashrom, but when i change chips with the 1Mb one and run again
> flashrom the new chip it's not recognized...
There are different kinds of protocols involved and it is possible that
chips with the same form factor/package are not compatible.
http://flashrom.org/Technology#Communication_bus_protocol
You should state more facts and/or post logs if you need more help.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Wed, 18 Feb 2015 16:26:35 +0300
"nicolae788 ." <nicolae788(a)gmail.com> wrote:
> Hello,
>
> I am trying to write a chip SST 49LF008A in a P5W-DH board. This is not the
> original chip of the board, it's a hot flash. The flashrom properly detects
> the ICH7R chipset and the chip described above, but can only read from it
> no erase or write. The problem is that it does not enable the TBL pin on
> the chip, it stays low. I checked if the pin can be enabled by using the
> onboard flash utility from whitin the original BIOS of this board an i get
> a high on that pin ( +3.3V ) so it means that the chipset it's doing the
> work if properly enabled.
> […]
> Can someone please instruct me on how to proceed further? Thank you very
> much for your kindness.
>
Hi,
as the name suggests a board enable is rather board-specific. It is
usually required to toggle a GPIO pin of the southbridge that is
connected to the TBL or #WP pin of the flash chip. What needs to be
done is actually encoded in the BIOS image (not the flash tool) so it
can be recovered by reverse engineering. See
http://flashrom.org/Board_Enable for more details.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hello,
I am trying to write a chip SST 49LF008A in a P5W-DH board. This is not the
original chip of the board, it's a hot flash. The flashrom properly detects
the ICH7R chipset and the chip described above, but can only read from it
no erase or write. The problem is that it does not enable the TBL pin on
the chip, it stays low. I checked if the pin can be enabled by using the
onboard flash utility from whitin the original BIOS of this board an i get
a high on that pin ( +3.3V ) so it means that the chipset it's doing the
work if properly enabled.
I tryied specifying another board model that has the same chipset, but it
exists with a message that " no suitable boar enable found for the board
name and manufacturer...".
I tried with version 0.9.7-r1711 and 0.9.5.2-r1546 under linux. Both gave
the same results.
When it tries to erase/write to the chip i get
"erase failed at 0x00000000! expected=0xff read=0x6d, failed byte count
from 0x00000000 - 0x0000ffff: 0x837
erase failed !
Reading current flash chip contents...done. erase failed at 0x00000000!
Expected 0x0xff, Read=0x6d, failed byte count from 0x00000000 - 0x0000ffff:
0x66dc
Erase failed !
Failed !
Can someone please instruct me on how to proceed further? Thank you very
much for your kindness.
Alex.
On Tue, 17 Feb 2015 04:46:16 -0600
<Ron_Taylor(a)DELL.com> wrote:
> 0x54: 0x000f0000 FREG0: Warning: Flash Descriptor region (0x00000000-0x0000ffff) is read-only.
> 0x58: 0x07ff0200 FREG1: BIOS region (0x00200000-0x007fffff) is read-write.
The problem is that the flash descriptor regions do not cover the whole
flash chip. There is a hole between 0x10000 and 0x1fffff (and the
second half of the chip is not mapped either). The chipset does not
allow accessing these holes but flashrom does try it by default
anyway because it reads the complete chip.
With some patching of flashrom this can be avoided but there is no
ready solution as far as I know. There are some patches regarding
layout handling that might be part of a possible solution, cf.
http://patchwork.coreboot.org/project/flashrom/list/
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Tue, 17 Feb 2015 19:04:24 +0100
skrizi(a)web.de wrote:
> Hi,
> i just want to confirm that the ARM-USB-OCD (without H suffix) works too so you can check this in the supported devices.
> […]
Hello skrizi,
thanks for your report!
I have marked the ARM-USB-OCD as working OK and will commit that later
together with other small changes.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner