Project

General

Profile

Actions

Bug #553

closed

M95M02 write failure

Added by Miklos Marton 3 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Category:
-
Target version:
Start date:
08/21/2024
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
STLinkV3
Affected OS:
Linux

Description

While trying to add support for EEPROM devices (which lacks the erase capability) I came across some issues with implementing it.
The only device so far which lacks erase capability is the M95M02.

When trying to write it via force I receieve a SIGSEV and the following output:

08:17:18: Debugging /home/mm/Projektek/flashrom/flashrom -p stlinkv3_spi -c M95M02 -f -w /tmp/myfile ...
could not find '.gnu_debugaltlink' file for /lib/x86_64-linux-gnu/libcap.so.2
flashrom 1.4.0-rc2 (git:v1.4.0-rc2-1-gbd3c5f31) on Linux 6.8.0-40-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Connected to STLink V3 with bridge FW version: 5
SCK frequency set to 750 kHz
Assuming ST flash chip "M95M02" (256 kB, SPI) on stlinkv3_spi.
===
This flash part has status UNTESTED for operations: WP
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@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.
You can also try to follow the instructions here:
https://www.flashrom.org/contrib_howtos/how_to_mark_chip_tested.html
Thanks for your help!
spi_get_opcode_from_erasefn: unknown erase function (0x1). Please report this at flashrom@flashrom.org

Backtrace:


>~"#0  0x000055555558f047 in check_block_eraser (flash=flash@entry=0x7fffffffd9d0, k=k@entry=0, log=log@entry=0) at flashrom.c:489\n"
>~"#1  0x000055555558f0c7 in count_usable_erasers (flash=flash@entry=0x7fffffffd9d0) at flashrom.c:508\n"
>~"#2  0x000055555558f15f in chip_safety_check (flash=flash@entry=0x7fffffffd9d0, force=1, read_it=read_it@entry=0, write_it=write_it@entry=1, erase_it=erase_it@entry=0, verify_it=verify_it@entry=1) at flashrom.c:2019\n"
>~"#3  0x0000555555591426 in prepare_flash_access (flash=flash@entry=0x7fffffffd9d0, read_it=read_it@entry=false, write_it=write_it@entry=true, erase_it=erase_it@entry=false, verify_it=verify_it@entry=true) at flashrom.c:2121\n"
>~"#4  0x0000555555591821 in flashrom_image_write (flashrom_flashctx=flashrom_flashctx@entry=0x7fffffffd9d0, buffer=buffer@entry=0x7ffff7ea5010, buffer_len=buffer_len@entry=262144, refbuffer=refbuffer@entry=0x0) at flashrom.c:2287\n"
>~"#5  0x00005555555795d6 in do_write (flash=flash@entry=0x7fffffffd9d0, filename=0x55555565c2c0 \"/tmp/myfile\", referencefile=0x0) at cli_classic.c:535\n"
>~"#6  0x000055555557a455 in main (argc=<optimized out>, argv=<optimized out>) at cli_classic.c:1255\n"

Actions #1

Updated by Anastasia Klimchuk 3 months ago

Miklos, thank you for adding a bug! always a good idea to have a bug described , and now it can be shared.

I have two things to say:

1) If you would like to continue working on this, you can try defining an empty array for block_erasers. Look at chip with vendor "Unknown" and name "SFDP-capable chip" as an example. From the error, you've probably set something in block_erasers array, and it is detected as invalid. But empty array might work.

2) You have created this bug in coreboot project, and I can only add comments here. If you change the project to flashrom, I will be able fill in some fields (affected version, category, watchers etc)

Actions #2

Updated by Felix Singer 3 months ago

  • Project changed from coreboot to flashrom
  • Target version deleted (none)
Actions #3

Updated by Anastasia Klimchuk 3 months ago

Miklos, I found something else.
There is a feature flag FEATURE_NO_ERASE which you can set for the chip definition, and I looked for the models with this flag, to give you as example.
I found one, but it's yours M95M02 ! So it already has a definition and FEATURE_NO_ERASE set.

Let me check, maybe we need to fix check_block_eraser to be aware of the chips with FEATURE_NO_ERASE flag. I haven't been working with FEATURE_NO_ERASE before, I need to dig whether the code has changed, or maybe check_block_eraser never checked for the flag.

Actions #4

Updated by Anastasia Klimchuk 3 months ago

I found the patch which (potentially) broke FEATURE_NO_ERASE
https://review.coreboot.org/c/flashrom/+/66717
The check itself is useful, but it doesn't work for chips with FEATURE_NO_ERASE, those models need to be handled specially. Maybe we can just add a condition that this check should be skipped for FEATURE_NO_ERASE

It now makes sense to me, the model M95M02 has been added in 2019, and the patch is from 2022 (and it updates check_block_eraser code).

If you want to try quickly, you can remove lines added in 66717, but I will try to make a patch for this and post link here.

Actions #5

Updated by Anastasia Klimchuk 3 months ago

Actions #6

Updated by Anastasia Klimchuk 2 months ago

  • Status changed from New to In Progress
  • Assignee set to Anastasia Klimchuk
Actions #7

Updated by Anastasia Klimchuk 2 months ago

  • Status changed from In Progress to Resolved
  • Target version set to 1.5

The patch is submitted, so I am closing this ticket (the segfault reported in the ticket is fixed).
However, if some other bug comes up, please tell!

Actions

Also available in: Atom PDF