bigbigmdm
Add send raw commands and/or cheatsheet menu
Description
So I was trying to flash a 16MB winbond rom but i couldn't get it to do it.
Now external sources said that the approach is to send a WREN command to let the chip set the WEL flag which the opcode of the command is 0x06 so it would be cool on those edge cases where the user changes the WEL flag on the properties panel it silently sends that command or having a list of known commands to execute.
flashrom got it although never told me. Since flashrom poked the rom chip IMSprog now can write to it (although said WELflag is still cleared).
I don't really exactly what did flashrom that forced that chip to cooperate but threre's that.
Also Just something off topic before I go: if I get time to do it I'll do the Spanish translation for you guys so my homies can use it :)
Usage tips
- Please use the 👍 reaction to show that you are interested into this.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this.
- Subscribe to receive notifications on status change and new comments, you can do also without add comment.
Hello, @alejandro-alzate ! Any programmer sends a WREN command before starting to write. IMSProg sets WREN DIASBLE at the end of the write. For complicated cases with chip locking there is a panel for working with status registers - [ctrl]+P. In this menu, set all bits of the first status register to zeros and write data to the register. Then repeat the chip write operation.
Wait it does? That's weird that chip wouldn't budge, it was read only (I followed your BP3 & BP4 advice on the readme to read it), but when i just listed it with flashrom, IMSProg would now write it. That's weird, I might have let slipped a bug?
This is very strange. Do you connect the chip to the programmer directly or with alligator clip?
Direct. I took the chip off of the board.
Just this morning tested the alligator with other chip on another board and that did caused issues. The 3.3v was enough to power the processor so it conflicted the SPI bus..
So from now on bare metal connection it is...
This is correct. Can you post a screenshot of the registers from IMSProg?
Uh that's gonna be a though one i soldered the thing on the board, But I remember that i had to clear only BP3 (BP4 was already clear), and WEL was never active before flashrom poked at it.
I think i saw it on 1 after the flashrom incident...
But here is my bash history with the flashrom nonsense
2000 pip install spidev
2001 sudo apt-get install bossa-cli
2002 ls /dev/spidev*
2003 modprobe spidev
2004 sudo modprobe spidev
2005 ls /dev/spidev*
2006 uname -r
2007 lsmod | grep spidev
2008 sudo modprobe spi_bcm2835
2009 sudo modprobe spidev
2010 sudo apt-get install build-essential libncurses5-dev bison flex libssl-dev
2011 dmesg | grep spi
2012 zcat /proc/config.gz | grep SPI
2013 CONFIG_SPI_MASTER=y
2014 CONFIG_SPI_SPIDEV=y
2015 ls /dev/spidev*
2016 sudo flashrom -p list
2017 sudo flashrom --programmer=ch431a_spilist
2018 sudo flashrom --programmer=ch431a_spi list
2019 sudo flashrom --programmer=ch341a_spi list
2020 sudo flashrom --programmer=ch341a_spi --help list
2021 flashrom
2022 sudo flashrom --programmer=ch341a_spi
2023 sudo flashrom -L
2024 sudo flashrom -p ch341a_spi
2025 dmesg | grep ch34
2026 cd Desktop/ROMS/HIKVISION/DS-7208HQHI-K1/
2027 ls
2028 sudo flashrom -p ch341a_spi -w ~/Downloads/digicap.dav
2029 binwalk ~/Downloads/digicap.dav
2030 sudo apt install binwalk
2031 binwalk ~/Downloads/digicap.dav
2032 binwalk backup.bin
2033 binwalk -e ~/Downloads/digicap.dav
2034 ls
2035 sudo apt-get install squashfs-tools
2036 mksquashfs _digicap.dav.extracted/ repacked.sqsh
2037 ls
2038 ll
2039 dd if=/dev/zero bs=1M count=1 >> repacked.sqsh
2040 zcat backup.bin > decompressed_file
2041 sudo flashrom -p ch341a_spi -w repacked.sqsh
2042 sudo flashrom -p ch341a_spi -w _digicap.dav.extracted/6C.cramfs
2043 history
2044 cp _digicap.dav.extracted/6C.cramfs ../cramfs.bin
2045 dd if=/dev/zero bs=1M count=1 >> ../cramfs.bin
2046 mv ../cramfs.bin .
2047 ls
2048 ll
2049 ghex cramfs.bin
2050 ghex cramfs.bin&
2051 watch -n .3 ll
2052 which ll
2053 $(which ll)
2054 nano ~/.bashrc
2055 watch -n .3 ls -alF
2056 sudo flashrom -p ch341a_spi -w cramfs.bin
2057 history
Winbond
25Q128JVSQ
From what I can make out (even rubbing chalk helped little).
IMS prog says that is a WINBOND 25Q128BV which...
Seems off...
Is this fella here (UF1)
@alejandro-alzate , thanks! I tested IMSProg with Winbond 25Q16, 25Q32, 25Q64 and 25Q256 chips.
So i just have bad luck and got exactly the chip that is not on your test subjects huh? I'm going to the hassle of heating the air gun thingy again, I'll give you those registers.
Here are the flags:
And a failed macro shot of the chip itself:
Please no need to torture the chip and PCB. I will look up the difference between the chips on datasheets.
Please no need to torture the chip and PCB. I will look up the difference between the chips on datasheets.
Too late mate :/
At least this is like the third time and I have it still with all pads... I updated my comment above with what you asked for.
@bigbigmdm How did it went your quest invoking the ancient runes of the datasheets? Does the discrepancy in the part number matters?
Hi, @alejandro-alzate ! Datasheet: I can't find any difference between these chips. Are you using the latest version of IMSProg (v1.4.3)? I don't understand - The write-protect bits BP3 and BP0 are set to one. This includes the write-protect area of the chip. Are these bits not getting set to zero?
Indeed 1.4.3 In fact I compiled it not knowing there was a ppa out there.
Before any write attempt
First Write attempt with IMS
Doing auto mode, for the first time froze the program which is weird. but the active light is on on the programmer. And refuses to do anything.
Oop! wait i tried to do the flashrom thing and failed miserably
flashrom v1.2 on Linux 5.15.0-119-generic (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).
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on ch341a_spi.
Reading old flash chip contents...
cb_in: error: LIBUSB_TRANSFER_TIMED_OUT
cb_in: error: LIBUSB_TRANSFER_TIMED_OUT
ch341a_spi_spi_send_command: Failed to read 4100 bytes
FAILED.
alejandro@lenovo:~$
But went smooth after doing the almighty "run the command again" trick.
flashrom v1.2 on Linux 5.15.0-119-generic (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).
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on ch341a_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip...
Warning: Chip content is identical to the requested image.
Erase/write done.
After flashrom touches it this are the flags seems like BP3 and BP0 got cleared by flashrom.
Now both manual write and auto works like nothing happened
Here's auto:
Here's manual:
Just writing because seeing the bar fill feels like seeing paint dry to be honest.
I hope eeprom tech don't suffer the same flaw that ssd tech (limited writes, memory cell corroding) Because all of those test I'm sure they're beating the heck outta the poor chip. But at least doesn't heat like ssd drives do.
I have a feeling that writing to the status register 0 is not happening. Can you write ones into it, then reading, then write zeros and read?
Something funny is going on:
What is on zeros won't change at all.
What is on ones refuses to change to zeros.
Did I cooked the chip?
Screencap zipped bc github can't cope with MKV and vlc won't transcode the video to mp4 correctly 2024-09-02 11-45-06.mkv.zip
Then don't. I think this problem will arise again. And then I'll fix it.
I mean I gave up trying to fix this board some time ago (Clearing DVR password by reflashing the firmware), but i'll help if you need some other tests...
It could be wrong detected, it could be W25Q128FV with security registers(FV),
with maybe some power problems(DRV1,DRV0).
But in IMS chip database there is difference between 256FV and 128BV with algorithms and also 4byte addressing(winbond addressing not detected on 128FV, says no).
Try W25Q256FV with SIZE: 16 M, winbond addressing is not set, chip not in IMS database or correctly detected on first attempt, need to manually select from menu. FV has security registers and size should be setup.
After writing, sometimes it could not reflashed, need replug it, WEL is 1, but chip has a lot of manuals and diffs between 256FV and 128FV could cause it, or something else. Probably cause is tempering with detection menu...
Sorry. I tested all the new versions with a bunch of chips, including the W25Q256FVBF chip.
I don't have any issues with this chip.
Did you connect directly to the chip or use crocodile clips?
PCB adapter, honestly you can close this one, unless anyone else have this issue I don't see real value into making you waste time here.
Mostly since with your evidence I suspect that chip was acting funny, and outside of that I fixed the DVR with other means, in other words close it at your own discretion, and please excuse me for wasting your time.
Chip W25Q128FV is not correctly identified as FV, could have own menu entry and correctly identified, but that could be other bug filled, but this issue may be present also here. Otherwise chip cumbercome explorations are in tinny space area not so funny... tin caps ware watching and cooked chips with watt delivery ATTR in .
lsusb
udevadm info /dev/bus/usb/number1/number2 --attribute-walk
could be problem with some cooking, flashrom may be present for some chips mb delivery., cooks media watching on channel list