Gpio 88 toggle is used as write protection disable/enable now
and we need that to happen at the initialization of programmer.
Background:
The RTD devices has an interesting implementation where the
flag we need to flash is `aa aa aa ff ff`. However, after reset,
the boot firmware of RTD device will overwrite this flag value to
`aa aa aa ff aa`. Given this evidence, the root cause would be
that the boot firmware is doing something with protection enable
by itself. This explains why the message
'Block protection cannot be disabled' is shown since the block
protection is called before write operation.
BUG=b:147402710,b:152558985,b:178766553
BRANCH=none
TEST=flashrom -p realtek_mst_i2c_spi:bus=x,reset-mcu=1,enter-isp=1 -w
image.bin
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Change-Id: I237bf9f8aa0fcbb904e7f0c09c74fd179e8c70c1
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49785
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The return value for reset function can not be guaranteed when
reset success. There is no way to check if reset success or not.
BUG=b:147402710,b:152558985
BRANCH=none
TEST=builds
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Change-Id: Ia6200f7150db4368c26d8dfe779a9e85184b1b06
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49786
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Be explicit to mask the first byte after the shifts as
highlighted by Angel Pons.
BUG=none
BRANCH=none
TEST=builds
Change-Id: I7d1215678094d709e79b8f8c96aa3810586cd72e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Spotted-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48974
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Shiyu Sun <sshiyu@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the PAGE_SIZE to 128 as fix r/w on different devices,
also fix the write page mapping for it.
BUG=b:147402710
TEST=build and run flashrom to read&write on multiple devices
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Change-Id: Ifcdd3548519eb37440e67fcf6206279cff05b159
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48840
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Check ISP mode before doing reset and add waiting
after the enter ISP mode command.
BUG=None
TEST=build and run mst commands
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Change-Id: Ib1ab8370eb6335a77bb293fc98a8ab7be465db4f
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48662
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This is needed to avoid attempt entering ISP mode multiple
times. The ISP mode can only exit after a reset, so once the
reset MCU parameter is set to 0, the device will not able to
exit from ISP mode and hence shouldn't enter ISP again on
the next operation.
Without exit ISP mode, the device data, like firmware version,
will not show the correct value, this param will also help
to identify this situation.
BUG=b:152558985,b:148745673
BRANCH=none
TEST=build and run:
$ flashrom -p realtek_mst_i2c_spi:bus=x,reset-mcu=0,enter-isp=1 \
-l layout -i PARTITION1:fw -w
$ flashrom -p realtek_mst_i2c_spi:bus=x,reset-mcu=0,enter-isp=0 \
-l layout -i FLAG1:flag -w
then either reset computer to allow update to take effect, or:
$ flashrom -p realtek_mst_i2c_spi:bus=x,reset-mcu=1,enter-isp=0 \
--flash-size
to trigger the update.
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Change-Id: I58931ac8b42ab55829f102d243aea6fcfd632e3e
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46623
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Here we provide a helper function to allow indexing MCU configuration
registers. The 0x9F port allows access to these MCU configuration
registers followed by the high and then low bytes of the register
address we wish to index written into 0xF5 or 0xF4 respectively, a
read or write can then be made via 0xF5.
For the configuration of GPIO pins on the chip, there are two relevant
register address, 0x104F for pin direction (sink input or push-pull
in-out) configuration and 0xFE3F for pin data values (1 to push-pull
and 0 to sink). The reference design uses GPIO 88 to strap the
write protection pin and so we provide a function that allows the call
site to toggle this state and therefore de-assert hardware write
protection of the external spi flash.
BUG=b:152558985,b:148745673
BRANCH=none
TEST=builds && verified the write protection get disabled.
Change-Id: I1aed0086f917e31bebb51857ad5cce138158fe82
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46089
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Ensure that when bus number and reset params are specified
at the same time are both correctly parsed by get_params().
Also renames the goto err cleanup path to make it clear.
Change-Id: Icb45b1ab39181b0f1a2dec1cce549d30db984936
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Spotted-by: Shiyu Sun <sshiyu@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/45944
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Modify the spi master as to not automatically reset the
MCU on tear-down unless explicitly stated by a param.
Change-Id: Ib70bf7399e7541f30b6905cdb950a6fb7b74ae18
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/45674
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove MCU reset on init as this was only introduced
when MCU fw requirements for correct flashing were unknown
however it turns out no MCU fw is required to flash and so
no MCU reset should occur upon initialization.
Change-Id: Ia03f94effc4b720964638c032bbde5acfb13960d
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/45896
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Turns out the MST likely doesn't need these so-called defaults
to be written for the purposes of spi flashing.
BUG=b:152558985,b:148745673
BRANCH=none
TEST=builds
Change-Id: Ieb938cf0805b22692d61db23795208c9be962b60
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/41124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Chip erasures take much longer than sector and bank
erasures. Allow the wait loop helper to multiply the
max timeout in this very specific case while quickly
timeout for other ops that are expected to be shorter.
V.2: Fix nonsense fall though warn-err
BUG=b:152558985,b:148745673
BRANCH=none
TEST=flashrom -p realtek_mst_i2c_spi:bus=8 -E &&
flashrom -p realtek_mst_i2c_spi:bus=8 -w foo
(cycle)..
Change-Id: I4a36aa3101827e69eb244775d25bbb476d4bb780
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/41123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Turns out broken erasures highlighted some of the issues
in the write256 implementation. After a fair amount of
time deciphering scarce documentation details a correct
implementation was finally derived.
V.2: Rename 'start_program() -> execute_write()' to
clarify the intention and not to overload the term
'program' since the MST actually runs a 'program'
itself.
BUG=b:152558985,b:148745673
BRANCH=none
TEST=flashrom -p realtek_mst_i2c_spi:bus=8 -E &&
flashrom -p realtek_mst_i2c_spi:bus=8 -w foo &&
flashrom -p realtek_mst_i2c_spi:bus=8 -r foo &&
hexdump -C foo
Change-Id: If61ff95697f886d3301a907b76283322c39ef5c7
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/41080
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Before issuing SPI opcodes into 0x61 the top three BITS of
0x60 need to be carefully crafted. Correctly craft these
in the case of SPI erasures and document this registers
expectations. Clean up remaining debug comments while we
are here.
BUG=b:152558985,b:148745673
BRANCH=none
TEST=flashrom -p realtek_mst_i2c_spi:bus=8 -E &&
flashrom -p realtek_mst_i2c_spi:bus=8 -r foo &&
hexdump -C foo
Change-Id: Ib11ba8f63b11a1c5ebaa68deb7971648de8c2ecd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/41079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Try to document some of the register magics with plausible
names for readability.
BUG=b:152558985,b:148745673
BRANCH=none
TEST=builds
Change-Id: I97313f6f14438e4cbfc62faa7242cf6fc271f387
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/41022
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
