Hi,
I have an Spansion/ Cypress FL256SAIF00 (http://www.cypress.com/file/177966/download) , I'd like to write to.
I added the diff to recognize the chip, but I believe I did something wrong- can you help?
Regards, Michael!
Hi Micheal,
On 13.03.2018 13:28, Michael Fuckner wrote:
Hi,
I have an Spansion/ Cypress FL256SAIF00
is that the marking on the chip's package? It doesn't match the ordering information in the datasheet. If the 00 at the end match the zeros in the datasheet, this chip should have 64KiB sectors.
(http://www.cypress.com/file/177966/download) , I'd like to write to.
I added the diff to recognize the chip, but I believe I did something wrong- can you help?
From your log: flashrom p1.0-22-g0bfa819-dirty on Linux 4.9.69-v7+ (armv7l)
You seem to still be on the staging branch. We have moved development to a master branch by now and abandoned staging. You should rebase on master (where some changes regarding 4-byte addressing were merged).
Your patch:
--- flashchips.c.bak 2018-03-13 12:37:25.414679416 +0100 +++ flashchips.c 2018-03-13 13:00:00.084703756 +0100 @@ -12047,6 +12047,48 @@ .voltage = {2700, 3600}, },
{.vendor = "Spansion",.name = "S25FL256S......0", /* hybrid: 32 (top or bottom) 4 kB sub-sectors + 64 kB sectors */.bustype = BUS_SPI,.manufacture_id = SPANSION_ID,.model_id = SPANSION_S25FL256,.total_size = 32768,.page_size = 256,/* supports 4B addressing */
As the chip is >16MiB, 4-byte addressing (4BA) is mandatory and you have to enable it below.
/* OTP: 1024B total, 32B reserved; read 0x4B; write 0x42 */.feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP,
You have to set at least FEATURE_4BA_NATIVE. The chip also supports an extended address register and a 4BA mode with legacy instructions; but the commands differ from what is already implemented for other chips. If you don't want to look into it, I can provide a patch in case you would agree to test it?
FEATURE_4BA_NATIVE and a native erase block function below should already work with linux_spi.
.tested = TEST_OK_PREW,.probe = probe_spi_rdid,.probe_timing = TIMING_ZERO,.block_erasers = {{/* This chip supports erasing of the 32 so-called "parameter sectors" with* opcode 0x20. Trying to access an address outside these 4kB blocks does* have no effect on the memory contents, but sets a flag in the SR..eraseblocks = {{4 * 1024, 32},{64 * 1024, 254} // inaccessible},.block_erase = spi_block_erase_20,}, { */.eraseblocks = { { 128 * 1024, 256} },.block_erase = spi_block_erase_d8,
The datasheet and the comment above suggest this would be 64KiB sectors not 128KiB? any reference for the 128?
If you want to try FEATURE_4BA_NATIVE, you'd have to use `spi_block_erase_dc` here (native 4BA version of d8).
Nico
}, {.eraseblocks = { { 32768 * 1024, 1} },.block_erase = spi_block_erase_60,}, {.eraseblocks = { { 32768 * 1024, 1} },.block_erase = spi_block_erase_c7,}},.printlock = spi_prettyprint_status_register_bp2_ep_srwd, /* TODO: SR2 and many others */.unlock = spi_disable_blockprotect_bp2_srwd, /* TODO: various other locks */.write = spi_chip_write_256, /* Multi I/O supported */.read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */.voltage = {2700, 3600},},{ .vendor = "Spansion", .name = "S25FL129P......0", /* hybrid: 32 (top or bottom) 4 kB sub-sectors + 64 kB sectors */
Hi Nico,
On 03/13/2018 04:06 PM, Nico Huber wrote:
Hi Micheal,
You seem to still be on the staging branch. We have moved development to a master branch by now and abandoned staging. You should rebase on master (where some changes regarding 4-byte addressing were merged).
OK, does this look better: flashrom p1.0-22-g0bfa819 on Linux 4.14.24-v7+ (armv7l)?
Your patch:
...
You have to set at least FEATURE_4BA_NATIVE. The chip also supports an extended address register and a 4BA mode with legacy instructions; but the commands differ from what is already implemented for other chips. If you don't want to look into it, I can provide a patch in case you would agree to test it?
yes, please!
FEATURE_4BA_NATIVE and a native erase block function below should already work with linux_spi.
The datasheet and the comment above suggest this would be 64KiB sectors not 128KiB? any reference for the 128?
wild guess- double almost every value found?
Thank you, Michael!
You seem to still be on the staging branch. We have moved development to a master branch by now and abandoned staging. You should rebase on master (where some changes regarding 4-byte addressing were merged).
OK, does this look better: flashrom p1.0-22-g0bfa819 on Linux 4.14.24-v7+ (armv7l)?
No, that looks like the same revision but with your local changes removed. If you never checked out master before, this would do:
$ git fetch origin master $ git checkout master
Not needed for the tests below, though.
You have to set at least FEATURE_4BA_NATIVE. The chip also supports an extended address register and a 4BA mode with legacy instructions; but the commands differ from what is already implemented for other chips. If you don't want to look into it, I can provide a patch in case you would agree to test it?
yes, please!
According to the datasheet the chip supports 4-byte addresses in three ways. To test each of them I've added the features step-by-step [1,2,3]. Flashrom decides which way to use by the programmer's features. Your linux_spi programmer should support all ways.
Please check out, build and test each commit individually with a write of random data (new random data each time, otherwise flashrom would bail out), e.g.
$ git fetch https://review.coreboot.org/flashrom refs/changes/32/25132/2 $ git checkout FETCH_HEAD $ make $ dd bs=1M count=32 if=/dev/urandom of=random1.rom $ ./flashrom -p linux_spi... -w random.rom -o logfile1.txt
$ git fetch https://review.coreboot.org/flashrom refs/changes/33/25133/3 $ git checkout FETCH_HEAD $ make $ ...
$ git fetch https://review.coreboot.org/flashrom refs/changes/34/25134/3 $ git checkout FETCH_HEAD $ make $ ...
Nico
[1] https://review.coreboot.org/#/c/flashrom/+/25132/ [2] https://review.coreboot.org/#/c/flashrom/+/25133/ [3] https://review.coreboot.org/#/c/flashrom/+/25134/
Hi,
I believe this looks good, doesn't it? (and the BMC the chip is used for is booting again). Thank you!
Regards, Michael!
On 03/13/2018 06:45 PM, Nico Huber wrote:
You seem to still be on the staging branch. We have moved development to a master branch by now and abandoned staging. You should rebase on master (where some changes regarding 4-byte addressing were merged).
OK, does this look better: flashrom p1.0-22-g0bfa819 on Linux 4.14.24-v7+ (armv7l)?
No, that looks like the same revision but with your local changes removed. If you never checked out master before, this would do:
$ git fetch origin master $ git checkout master
Not needed for the tests below, though.
You have to set at least FEATURE_4BA_NATIVE. The chip also supports an extended address register and a 4BA mode with legacy instructions; but the commands differ from what is already implemented for other chips. If you don't want to look into it, I can provide a patch in case you would agree to test it?
yes, please!
According to the datasheet the chip supports 4-byte addresses in three ways. To test each of them I've added the features step-by-step [1,2,3]. Flashrom decides which way to use by the programmer's features. Your linux_spi programmer should support all ways.
Please check out, build and test each commit individually with a write of random data (new random data each time, otherwise flashrom would bail out), e.g.
$ git fetch https://review.coreboot.org/flashrom refs/changes/32/25132/2 $ git checkout FETCH_HEAD $ make $ dd bs=1M count=32 if=/dev/urandom of=random1.rom $ ./flashrom -p linux_spi... -w random.rom -o logfile1.txt
$ git fetch https://review.coreboot.org/flashrom refs/changes/33/25133/3 $ git checkout FETCH_HEAD $ make $ ...
$ git fetch https://review.coreboot.org/flashrom refs/changes/34/25134/3 $ git checkout FETCH_HEAD $ make $ ...
Nico
[1] https://review.coreboot.org/#/c/flashrom/+/25132/ [2] https://review.coreboot.org/#/c/flashrom/+/25133/ [3] https://review.coreboot.org/#/c/flashrom/+/25134/
-
Michael Fuckner -
Nico Huber