February 2025 - flashrom-gerrit

[L] Change in flashrom[main]: spidriver: Add support for the Excamera Labs SPIDriver programmer
by Simon Arlott (Code Review) 14 Feb '25

14 Feb '25

Attention is currently required from: Anastasia Klimchuk, Peter Marheine. Hello Anastasia Klimchuk, Peter Marheine, I'd like you to reexamine a change. Please visit https://review.coreboot.org/c/flashrom/+/86411?usp=email to look at the new patch set (#2). Change subject: spidriver: Add support for the Excamera Labs SPIDriver programmer ...................................................................... spidriver: Add support for the Excamera Labs SPIDriver programmer This is a SPI hardware interface with a display (https://spidriver.com/), connected as an FT230X USB serial device at a fixed baud rate of 460800. Firmware: https://github.com/jamesbowman/spidriver Protocol: https://github.com/jamesbowman/spidriver/blob/master/protocol.md Most of the implementation is copied from the Bus Pirate programmer. Tested with a SPIDriver v2 by reading FM25Q128A flash memory on Linux. Change-Id: I07b23c1146d4ad3606b54a1e8dc8030cf4ebf57b Signed-off-by: Simon Arlott <flashrom(a)octiron.net> --- M doc/classic_cli_manpage.rst M include/programmer.h M meson.build M meson_options.txt M programmer_table.c A spidriver.c M test_build.sh 7 files changed, 364 insertions(+), 4 deletions(-) git pull ssh://review.coreboot.org:29418/flashrom refs/changes/11/86411/2 -- To view, visit https://review.coreboot.org/c/flashrom/+/86411?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: newpatchset Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I07b23c1146d4ad3606b54a1e8dc8030cf4ebf57b Gerrit-Change-Number: 86411 Gerrit-PatchSet: 2 Gerrit-Owner: Simon Arlott Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Attention: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Attention: Peter Marheine <pmarheine(a)chromium.org>

1 0

[L] Change in flashrom[main]: spidriver: Add support for the Excamera Labs SPIDriver programmer
by Simon Arlott (Code Review) 14 Feb '25

14 Feb '25

Simon Arlott has uploaded this change for review. ( https://review.coreboot.org/c/flashrom/+/86411?usp=email ) Change subject: spidriver: Add support for the Excamera Labs SPIDriver programmer ...................................................................... spidriver: Add support for the Excamera Labs SPIDriver programmer This is a SPI hardware interface with a display (https://spidriver.com/), connected as an FT230X USB serial device at a fixed baud rate of 460800. Firmware: https://github.com/jamesbowman/spidriver Protocol: https://github.com/jamesbowman/spidriver/blob/master/protocol.md Most of the implementation is copied from the Bus Pirate programmer. Tested with a SPIDriver v2 by reading FM25Q128A flash memory on Linux. Change-Id: I07b23c1146d4ad3606b54a1e8dc8030cf4ebf57b Signed-off-by: Simon Arlott <flashrom(a)octiron.net> --- M doc/classic_cli_manpage.rst M include/programmer.h M meson.build M meson_options.txt M programmer_table.c A spidriver.c M test_build.sh 7 files changed, 364 insertions(+), 4 deletions(-) git pull ssh://review.coreboot.org:29418/flashrom refs/changes/11/86411/1 diff --git a/doc/classic_cli_manpage.rst b/doc/classic_cli_manpage.rst index 4f2e68e..c23a0db 100644 --- a/doc/classic_cli_manpage.rst +++ b/doc/classic_cli_manpage.rst @@ -356,6 +356,7 @@ * ``mediatek_i2c_spi`` (for SPI flash ROMs attached to some Mediatek display devices accessible over I2C) * ``dirtyjtag_spi`` (for SPI flash ROMs attached to DirtyJTAG-compatible devices) * ``asm106x`` (for SPI flash ROMs attached to asm106x PCI SATA controllers) + * ``spidriver`` (for SPI flash ROMs attached to an Excamera Labs SPIDriver) Some programmers have optional or mandatory parameters which are described in detail in the **PROGRAMMER-SPECIFIC INFORMATION** section. Support for some programmers can be disabled at compile time. @@ -1404,6 +1405,26 @@ mechanism in the driver to positively identify that a given I2C bus is actually connected to a supported device. +spidriver programmer +^^^^^^^^^^^^^^^^^^^^ + +A required ``dev`` parameter specifies the SPIDriver device node and an optional ``mode`` parameter specifies the mode +of the SPI bus. The parameter delimiter is a comma. Syntax is:: + + flashrom -p spidriver:dev=/dev/device,mode=0 + +where ``mode`` can be ``0``, ``1``, ``2`` or ``3``. The default is mode 0. +Setting the SPI mode requires version 2 of the device firmware. + +An optional A and/or B parameter specifies the state of the SPIDriver A and B pins. +This may be used to drive the A or B pins high or low before a transfer. +Syntax is:: + + flashrom -p spidriver:a=state,b=state + +where ``state`` can be ``high`` or ``low``. The default ``state`` is ``high``. + + EXAMPLES -------- @@ -1482,7 +1503,7 @@ * needs TCP access to the network or userspace access to a serial port -* buspirate_spi +* buspirate_spi, spidriver * needs userspace access to a serial port @@ -1503,7 +1524,7 @@ * have to be run as superuser/root * need raw access permission -* serprog, buspirate_spi, dediprog, usbblaster_spi, ft2232_spi, pickit2_spi, ch341a_spi, digilent_spi, dirtyjtag_spi +* serprog, buspirate_spi, dediprog, usbblaster_spi, ft2232_spi, pickit2_spi, ch341a_spi, digilent_spi, dirtyjtag_spi, spidriver * can be run as normal user on most operating systems if appropriate device permissions are set diff --git a/include/programmer.h b/include/programmer.h index e0630b8..56165bb 100644 --- a/include/programmer.h +++ b/include/programmer.h @@ -98,6 +98,7 @@ extern const struct programmer_entry programmer_satasii; extern const struct programmer_entry programmer_serprog; extern const struct programmer_entry programmer_stlinkv3_spi; +extern const struct programmer_entry programmer_spidriver; extern const struct programmer_entry programmer_usbblaster_spi; extern const struct programmer_entry programmer_dirtyjtag_spi; diff --git a/meson.build b/meson.build index 6c8d3d3..5a4062f 100644 --- a/meson.build +++ b/meson.build @@ -542,6 +542,12 @@ 'srcs' : files('serprog.c', 'serial.c', custom_baud_c), 'flags' : [ '-DCONFIG_SERPROG=1' ], }, + 'spidriver' : { + 'systems' : systems_serial, + 'groups' : [ group_serial, group_external ], + 'srcs' : files('spidriver.c', 'serial.c', custom_baud_c), + 'flags' : [ '-DCONFIG_SPIDRIVER=1' ], + }, 'stlinkv3_spi' : { 'deps' : [ libusb1 ], 'groups' : [ group_usb, group_external ], diff --git a/meson_options.txt b/meson_options.txt index 87456a9..3b9bea1 100644 --- a/meson_options.txt +++ b/meson_options.txt @@ -14,7 +14,8 @@ 'gfxnvidia', 'internal', 'it8212', 'jlink_spi', 'linux_mtd', 'linux_spi', 'mediatek_i2c_spi', 'mstarddc_spi', 'ni845x_spi', 'nic3com', 'nicintel', 'nicintel_eeprom', 'nicintel_spi', 'nicnatsemi', 'nicrealtek', 'ogp_spi', 'parade_lspcon', 'pickit2_spi', 'pony_spi', 'raiden_debug_spi', - 'rayer_spi', 'realtek_mst_i2c_spi', 'satamv', 'satasii', 'serprog', 'stlinkv3_spi', 'usbblaster_spi', + 'rayer_spi', 'realtek_mst_i2c_spi', 'satamv', 'satasii', 'serprog', 'spidriver', 'stlinkv3_spi', + 'usbblaster_spi', ], description: 'Active programmers') option('llvm_cov', type : 'feature', value : 'disabled', description : 'build for llvm code coverage') option('man-pages', type : 'feature', value : 'auto', description : 'build the man-page for classic_cli') diff --git a/programmer_table.c b/programmer_table.c index 79acd77..6d28dd1 100644 --- a/programmer_table.c +++ b/programmer_table.c @@ -179,6 +179,10 @@ #if CONFIG_DIRTYJTAG_SPI == 1 &programmer_dirtyjtag_spi, #endif + +#if CONFIG_SPIDRIVER == 1 + &programmer_spidriver, +#endif }; const size_t programmer_table_size = ARRAY_SIZE(programmer_table); diff --git a/spidriver.c b/spidriver.c new file mode 100644 index 0000000..bafc0aa --- /dev/null +++ b/spidriver.c @@ -0,0 +1,326 @@ +/* + * This file is part of the flashrom project. + * + * Copyright (C) 2009, 2010, 2011, 2012 Carl-Daniel Hailfinger + * Copyright 2025 Simon Arlott + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +/* Website: https://spidriver.com/ + * Protocol: https://github.com/jamesbowman/spidriver/blob/master/protocol.md + */ + +#include <assert.h> +#include <stdio.h> +#include <strings.h> +#include <string.h> +#include <stdbool.h> +#include <stdlib.h> +#include <ctype.h> +#include <unistd.h> +#include "flash.h" +#include "programmer.h" +#include "spi.h" + +static int buspirate_serialport_setup(char *dev) +{ + /* 460800bps, 8 databits, no parity, 1 stopbit */ + sp_fd = sp_openserport(dev, 460800); + if (sp_fd == SER_INV_FD) + return 1; + return 0; +} + +static int spidriver_sendrecv(unsigned char *buf, unsigned int writecnt, + unsigned int readcnt) +{ + unsigned int i; + int ret = 0; + + msg_pspew("%s: write %i, read %i ", __func__, writecnt, readcnt); + if (!writecnt && !readcnt) { + msg_perr("Zero length command!\n"); + return 1; + } + if (writecnt) + msg_pspew("Sending"); + for (i = 0; i < writecnt; i++) + msg_pspew(" 0x%02x", buf[i]); + if (writecnt) + ret = serialport_write(buf, writecnt); + if (ret) + return ret; + if (readcnt) + ret = serialport_read(buf, readcnt); + if (ret) + return ret; + if (readcnt) + msg_pspew(", receiving"); + for (i = 0; i < readcnt; i++) + msg_pspew(" 0x%02x", buf[i]); + msg_pspew("\n"); + return 0; +} + +/* Sending multiple commands too quickly usually fails, so use echo to wait for + * each command to complete before sending the next one. + */ +static int spidriver_send_command(const struct flashctx *flash, unsigned int writecnt, + unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr) +{ + int ret = 0; + + { + unsigned char buf[1 + 2]; + unsigned int i = 0; + + /* Assert CS# */ + buf[i++] = 's'; + + /* Echo */ + buf[i++] = 'e'; + buf[i++] = 'S'; + + if ((ret = spidriver_sendrecv(buf, i, 1))) { + msg_perr("Communication error after writing %u reading %u\n", writecnt, readcnt); + return SPI_GENERIC_ERROR; + } + + if (buf[0] != 'S') { + msg_perr("Communication error, unexpected select echo response %u\n", buf[0]); + return SPI_GENERIC_ERROR; + } + } + + while (writecnt > 0) { + unsigned char buf[1 + 64 + 2]; + unsigned int i = 0; + unsigned int len = writecnt > 64 ? 64 : writecnt; + + /* Write */ + i = 0; + buf[i++] = 0xc0 - 1 + len; + memcpy(&buf[i], writearr, len); + i += len; + + /* Echo */ + buf[i++] = 'e'; + buf[i++] = 'W'; + writearr += len; + writecnt -= len; + + if ((ret = spidriver_sendrecv(buf, i, 1))) { + msg_perr("Communication error writing %u\n", len); + return SPI_GENERIC_ERROR; + } + + if (buf[0] != 'W') { + msg_perr("Communication error, unexpected write echo response %u\n", buf[0]); + return SPI_GENERIC_ERROR; + } + } + + while (readcnt > 0) { + unsigned char buf[1 + 64]; + unsigned int i = 0; + unsigned int len = readcnt > 64 ? 64 : readcnt; + + /* Read and write */ + i = 0; + buf[i++] = 0x80 - 1 + len; + memset(&buf[i], 0, len); + i += len; + + if ((ret = spidriver_sendrecv(buf, i, len))) { + msg_perr("Communication error reading %u\n", len); + return SPI_GENERIC_ERROR; + } + + memcpy(readarr, buf, len); + readarr += len; + readcnt -= len; + } + + { + unsigned char buf[1 + 2]; + unsigned int i = 0; + + /* De-assert CS# */ + buf[i++] = 'u'; + + /* Echo */ + buf[i++] = 'e'; + buf[i++] = 'U'; + + if ((ret = spidriver_sendrecv(buf, i, 1))) { + msg_perr("Communication error after writing %u reading %u\n", writecnt, readcnt); + return SPI_GENERIC_ERROR; + } + + if (buf[0] != 'U') { + msg_perr("Communication error, unexpected unselect echo response %u\n", buf[0]); + return SPI_GENERIC_ERROR; + } + } + + return ret; +} + +static struct spi_master spi_master_spidriver = { + .features = SPI_MASTER_4BA, + .max_data_read = MAX_DATA_READ_UNLIMITED, + .max_data_write = MAX_DATA_WRITE_UNLIMITED, + .command = spidriver_send_command, + .read = default_spi_read, + .write_256 = default_spi_write_256, + .shutdown = serialport_shutdown, +}; + +static int buspirate_spi_init(const struct programmer_cfg *cfg) +{ + char *tmp; + char *dev; + unsigned long fw_version = 0; + int ret = 0; + long mode = 0; + bool a = true; + bool b = true; + + dev = extract_programmer_param_str(cfg, "dev"); + if (dev && !strlen(dev)) { + free(dev); + dev = NULL; + } + if (!dev) { + msg_perr("No serial device given. Use flashrom -p spidriver:dev=/dev/ttyUSB0\n"); + return 1; + } + + tmp = extract_programmer_param_str(cfg, "mode"); + if (tmp) { + mode = strtol(tmp, NULL, 10); + if (mode < 0 || mode > 3) { + msg_perr("Invalid SPI mode %ld\n", mode); + return 1; + } + } + free(tmp); + + tmp = extract_programmer_param_str(cfg, "a"); + if (tmp) { + if (strcasecmp("high", tmp) == 0) + ; /* Default */ + else if (strcasecmp("low", tmp) == 0) + a = false; + else + msg_perr("Invalid A state, driving high by default\n"); + } + free(tmp); + + tmp = extract_programmer_param_str(cfg, "b"); + if (tmp) { + if (strcasecmp("high", tmp) == 0) + ; /* Default */ + else if (strcasecmp("low", tmp) == 0) + b = false; + else + msg_perr("Invalid B state, driving high by default\n"); + } + free(tmp); + + ret = buspirate_serialport_setup(dev); + free(dev); + if (ret) + return ret; + + /* Largest message is: 1 byte command (tx), 80 byte response plus 1 for + * string null termination (rx). + */ + unsigned char buf[80 + 1]; + + /* Flush any in-progress transfer with 64 zero bytes. */ + memset(buf, 0, 64); + if ((ret = spidriver_sendrecv(buf, 64, 0))) + goto init_err_cleanup_exit; + + default_delay(1400); /* Enough time to receive 64 bytes at 460800bps */ + sp_flush_incoming(); + + memset(buf, 0, 81); + buf[0] = '?'; + if ((ret = spidriver_sendrecv(buf, 1, 80))) + goto init_err_cleanup_exit; + + /* [spidriver2 AAAAAAAA 000000002 5.190 000 21.9 1 1 1 ffff 0 ] */ + /* <version> <serial> <uptime> ^^^^^ ^^^ ^^^^ ^ ^ ^ ^^^^ ^ */ + /* (seconds) | | | | | | | | */ + /* | | | | | | | ` SPI mode (0-3) */ + /* | | | | | | ` CCITT CRC */ + /* | | | | | ` Chip select */ + /* | | | | ` "B" signal */ + /* | | | ` "A" signal */ + /* | | ` Temperature */ + /* | ` Current */ + /* ` Voltage */ + if (buf[0] != '[' || buf[79] != ']' || !strcmp((char*)&buf[1], "spidriver")) { + msg_perr("Invalid status response: %s\n", buf); + ret = 1; + goto init_err_cleanup_exit; + } + + msg_pdbg("Status: %s\n", buf); + msg_pdbg("Detected SPIDriver hardware "); + + if (!strchr("0123456789", buf[10])) { + msg_pdbg("(unknown version number format)"); + } else { + fw_version = strtoul((char*)&buf[10], &tmp, 10); + msg_pdbg("v%lu", fw_version); + } + msg_pdbg("\n"); + + /* De-assert CS#, configure A and B signals */ + buf[0] = 'u'; + buf[1] = 'a'; + buf[2] = a ? 1 : 0; + buf[3] = 'b'; + buf[4] = b ? 1 : 0; + msg_pdbg("Raising CS#\n"); + msg_pdbg("Driving A %s\n", a ? "high" : "low"); + msg_pdbg("Driving B %s\n", b ? "high" : "low"); + if ((ret = spidriver_sendrecv(buf, 5, 0))) + goto init_err_cleanup_exit; + + if (fw_version >= 1) { + /* Set SPI mode */ + buf[0] = 'm'; + buf[1] = mode & 0xFF; + if ((ret = spidriver_sendrecv(buf, 1, 0))) + goto init_err_cleanup_exit; + } else if (mode != 0) { + msg_perr("SPI mode %ld not supported by version 1 hardware", mode); + ret = 1; + goto init_err_cleanup_exit; + } + + return register_spi_master(&spi_master_spidriver, NULL); + +init_err_cleanup_exit: + serialport_shutdown(NULL); + return ret; +} + +const struct programmer_entry programmer_spidriver = { + .name = "spidriver", + .type = OTHER, + .devs.note = "SPIDriver\n", + .init = buspirate_spi_init, +}; diff --git a/test_build.sh b/test_build.sh index 968f259..4619618 100755 --- a/test_build.sh +++ b/test_build.sh @@ -11,7 +11,8 @@ gfxnvidia internal it8212 jlink_spi linux_mtd linux_spi parade_lspcon \ mediatek_i2c_spi mstarddc_spi nic3com nicintel nicintel_eeprom nicintel_spi \ nicnatsemi nicrealtek ogp_spi pickit2_spi pony_spi raiden_debug_spi rayer_spi \ - realtek_mst_i2c_spi satamv satasii serprog stlinkv3_spi usbblaster_spi asm106x" + realtek_mst_i2c_spi satamv satasii serprog spidriver stlinkv3_spi usbblaster_spi\ + asm106x" if [ "$(basename "${CC}")" = "ccc-analyzer" ] || [ -n "${COVERITY_OUTPUT}" ]; then -- To view, visit https://review.coreboot.org/c/flashrom/+/86411?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I07b23c1146d4ad3606b54a1e8dc8030cf4ebf57b Gerrit-Change-Number: 86411 Gerrit-PatchSet: 1 Gerrit-Owner: Simon Arlott

1 0

[S] Change in flashrom[main]: flashchips: Add Macronix MX77U25650FZ4I42
by Anastasia Klimchuk (Code Review) 13 Feb '25

13 Feb '25

Attention is currently required from: Dolan Liu, Nikolai Artemiev, Stefan Reinauer. Anastasia Klimchuk has posted comments on this change by Dolan Liu. ( https://review.coreboot.org/c/flashrom/+/86348?usp=email ) Change subject: flashchips: Add Macronix MX77U25650FZ4I42 ...................................................................... Patch Set 2: (1 comment) Patchset: PS2: Hello Dolan, thank you for the patch. Could you please add link to the datasheet? Thanks! -- To view, visit https://review.coreboot.org/c/flashrom/+/86348?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I7866b2db343f4eb2bc194400ceca099d3af3b87d Gerrit-Change-Number: 86348 Gerrit-PatchSet: 2 Gerrit-Owner: Dolan Liu <liuyong5(a)huaqin.corp-partner.google.com> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Dolan Liu <liuyong5(a)huaqin.corp-partner.google.com> Gerrit-Attention: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Attention: Nikolai Artemiev <nartemiev(a)google.com> Gerrit-Comment-Date: Thu, 13 Feb 2025 04:17:55 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

[L] Change in flashrom[main]: doc: Migrate collection of docs about board enable
by Anastasia Klimchuk (Code Review) 13 Feb '25

13 Feb '25

Anastasia Klimchuk has submitted this change. ( https://review.coreboot.org/c/flashrom/+/86329?usp=email ) Change subject: doc: Migrate collection of docs about board enable ...................................................................... doc: Migrate collection of docs about board enable Collection is gathered from these docs: https://wiki.flashrom.org/Board_Enable https://wiki.flashrom.org/Board_Testing_HOWTO https://wiki.flashrom.org/Finding_Board_Enable_by_Reverse_Engineering Change-Id: I0aaa39679514f667c70ba50f6b726e8d1bd07825 Signed-off-by: Anastasia Klimchuk <aklm(a)flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/86329 Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> --- A doc/contrib_howtos/board_enable/board_testing_howto.rst A doc/contrib_howtos/board_enable/index.rst A doc/contrib_howtos/board_enable/overview.rst A doc/contrib_howtos/board_enable/reverse_engineering.rst M doc/contrib_howtos/index.rst 5 files changed, 356 insertions(+), 0 deletions(-) Approvals: build bot (Jenkins): Verified Stefan Reinauer: Looks good to me, approved diff --git a/doc/contrib_howtos/board_enable/board_testing_howto.rst b/doc/contrib_howtos/board_enable/board_testing_howto.rst new file mode 100644 index 0000000..1847156 --- /dev/null +++ b/doc/contrib_howtos/board_enable/board_testing_howto.rst @@ -0,0 +1,72 @@ +=================== +Board Testing HOWTO +=================== + +**Note the document below was migrated from old website and the content >10yrs old** +Patches to add/update documentation are very much appreciated. + +This page gives you mainly hints on how to test flashrom support on mainboards. +Testing for graphics / network / SATA cards and external programmer devices is similar but less dangerous. + +.. container:: danger, admonition + + Important information + + DO NOT ATTEMPT TO FOLLOW THESE INSTRUCTIONS UNLESS YOU KNOW WHAT YOU ARE DOING! + THIS CAN RENDER YOUR MAINBOARD TOTALLY UNUSABLE! YOU HAVE BEEN WARNED! + +* If you have a laptop/notebook/netbook, please do NOT try flashrom because interactions + with the EC on these machines might crash your machine during flashing. + flashrom tries to detect if a machine is a laptop, but not all laptops follow the standard, + so this is not 100% reliable. + +* To check whether flashrom knows about your chipset and ROM chip, run ``flashrom -p internal``. + +* If it says ``"Found chipset CHIPSETNAME..."`` and ``"CHIPNAME found at..."`` that's a good first sign. + +* To check if you can read the existing BIOS image from the chip, run ``flashrom -p internal -r backup.bin``. + Make sure that backup.bin contains a useful BIOS image (some chipsets will return 0xff for large areas + of flash without any error messages, but there might be actually large areas of 0xff in the original image as well). + +* Now the really important part, checking if *writing* an image on the chip works: + + * First, if the board has a flash socket and you have spare chips, + make sure you have a backup chip containing the original BIOS. + Also, you should have verified that it actually boots your system successfully. + Put away that backup chip somewhere safe and insert a chip which you can safely + overwrite (e.g. an empty one you bought). + + * If that is not possible make sure you have some other way for complete recovery, + e.g. an external programmer that can do :doc:`/user_docs/in_system` on the board in question. + + * Then write an image onto the chip, which is different from what's on the chip right now: + ``flashrom -p internal -w new.bin``. If the image is equal you will get a notice since r1680. + If this works and flashrom reports "VERIFIED" your board is supported by flashrom. + + * If not, you might try to enable the "Enable BIOS Update" or "Write-protect BIOS" + or similar options in your BIOS menu first, or set a jumper on your board + (this is highly board-dependent). Also, you might have to use the flashrom --mainboard + switch for some boards. + + * If none of the above helps (but flashrom still *does* detect your chipset and ROM chip), + there's quite likely a board-specific initialization required in flashrom, + which is non-trivial to add (e.g. toggling certain custom GPIO lines etc). + In that case, contact us as we may be able to help. + + * If you can't risk a write on a given chip and if the chip is SPI, the following guidelines may help: + + * Try probing. + + * For ICH/VIA SPI, lockdown can mean probe works, but write/erase or even read doesn't. + It can also mean that probe does not work, but write/read/erase (or any subset thereof) would work. + For all other SPI chipsets, there is no such lockdown, so you can issue any erase/write/read command. + + * However, some SPI chips have a WP# pin which causes the block protection bits to become readonly. + Now if flashrom has a generic block protection checker for your chip, we're able to figure out + if write/erase is possible. Basically, you can check if you need a board enable + by setting all block protection bits, then unsetting them. If either of the operations fail, + you need a board enable. If they succeed, erase and write are guaranteed to work. + +Please tell us about your results by sending the output of flashrom commands you ran, +the exact board manufacturer and model name, and all of your observations and test results +to the flashrom :ref:`mailing list`. diff --git a/doc/contrib_howtos/board_enable/index.rst b/doc/contrib_howtos/board_enable/index.rst new file mode 100644 index 0000000..d6808e4 --- /dev/null +++ b/doc/contrib_howtos/board_enable/index.rst @@ -0,0 +1,15 @@ +======================= +Board enable collection +======================= + +The term "board enable" describes mainboard specific code to make +flash rom write access possible on this mainboard. + +Patches to add/update documentation are very much appreciated. + +.. toctree:: + :maxdepth: 1 + + overview + board_testing_howto + reverse_engineering diff --git a/doc/contrib_howtos/board_enable/overview.rst b/doc/contrib_howtos/board_enable/overview.rst new file mode 100644 index 0000000..98e1748 --- /dev/null +++ b/doc/contrib_howtos/board_enable/overview.rst @@ -0,0 +1,161 @@ +===================== +Board Enable Overview +===================== + +**Note the document below was migrated from old website and the content >10yrs old** +Patches to add/update documentation are very much appreciated. + +The term "board enable" describes mainboard specific code to make flash rom +write access possible on this mainboard. Usually this means programming some +directly programmable output pin (usually called general purpose I/O or GPIO for short) +of the chipset that is connect to a write protect input of the BIOS ROM chip to release write protection. + +How to find the board enable procedure on your board +==================================================== + +The reverse engineering method at the end is preferred because it has a bit lower risk. + +Try & Error method on GPIO pins +------------------------------- + +The following is a mail from Ron: + +we just had the need to find a flash write enable on some servers. +These are Dell S1850s and we're tired of having a non-Linux-based Flash tool, +and, still worse, one to which we do not have source. Flashrom would be great, +save that it can't get the flash to write. We decided to see if it was the classic +GPIO-enabled FLASH write pin, which is the standard it seems in PC hardware. + +In this note I am just describing a program that I wrote long ago at LANL +and have used from time to time when I could not get the info I needed on enabling FLASH write. + +One thing we have found over the past 10 years: the single most common write enable control +is a GPIO attached to a southbridge. Don't know why it always seems to be this way, but there it is. + +This leads to a simple strategy to test for a GPIO enable, and to find which one it is. + +First, we find the southbridge, which in this case is an ICH5. +The GPIO programming on this part is little changed from earlier parts. + +Then we find the pci function which has the GPIOs. It's usually the LPC bridge. + +So for ICH5: + +00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) + +it's that one. + +So, to make it easy, rather than look at the BAR for the GPIO, just ``cat /proc/ioports`` and find this:: + + 0880-08bf : 0000:00:1f.0 + 0880-08bf : pnp 00:06 + +OK, we are about ready to go. The base address of the GPIOs is 0x880. +If you're paranoid confirm it with setpci:: + + [root@tn4 ~]# setpci -s 0:1f.0 58.l + 00000881 + [root@tn4 ~]# + +You need to look up the IO space mappings of SOME of the registers, +but for this simple program, not ALL. In fact all we're going to do is +read in the GPIO data level register, complement it, write it out, +then run flashrom to see if it works. But, you ask: + +* what if you read inputs and write them out nothing, so don't worry. They're inputs. +* you change GPIO pins that do some other thing well, it gets harder in that case. + For instance, some laptops use a GPIO pin to enable DRAM power. + Don't worry, you'll find out if they do. + +In that case, you'll have to do 32 boot/test cycles in the worst case, +instead of the five we do here. It actually can be instructive on a laptop +to change output GPIO levels and see what happens, so this is a fun test to do anyway. + +First, though, do this: ``flashrom -r factory.img`` + +Then ``emacs factory.img`` , (Go into OVRWRT mode!) and look for a string like this:: + + F2 = Setup + +I changed it to:: + + F2 = FIXup + +I may have used some other F-based words, as time went on, but that's another story. + +You want to make sure that if you really do rewrite it that it is easy to tell! +With this change, as soon as the BIOS splash screen comes up, you will know. + +OK, some code: Just set a few things up we think we'll need.:: + + #include <stdio.h> + #include <sys/io.h> + + #define LVL 0xc + +LVL is the level register for the GPIO. Now let's go to work.:: + + int main(int argc, char *argv[]) + { + unsigned long gpioport = 0x880; + unsigned long gpioval; + iopl(3); + /* first simple test: read in all GPIOs, complement them, + * output them, see if flashrom works */ + gpioval = inl(gpioport + LVL); + printf("GPIO is 0x%x (default 0x1f1f0000)\n", gpioval); + /* invert */ + gpioval = ~gpioval; + printf("GPIO will be set to 0x%x \n", gpioval); + outl(gpioval, gpioport + LVL); + gpioval = inl(gpioport + LVL); + printf("GPIO is 0x%x \n", gpioval); + } + +OK, call this program 'one'. At this point, you want to try a flashrom run. +As it happens this works and is sufficient to allow us to use flashrom! + +How to finish the task? It's actually a fairly simple newtonian search. + +First try ``gpioval ^= 0xffff0000;`` + +If that works, then try 0xff000000, etc. etc. Even if you get it wrong, +which I did, it still doesn't take long to find it. + +Warning, though: each time you try, be sure to change the FIXup string in the rom image, +to be very very sure that you really did rewrite it. You need to be careful about this step. + +Anyway, hope that is a little useful. It really is a very simple process to find a GPIO enable. +That's one reason that vendors are going to make this much, much harder on future systems. +GPIO enables are not a security feature, in spite of what you may have heard; +they are really accident protection in case some piece of software goes insane +and starts writing to random memory locations. + +Reverse Engineering your BIOS +----------------------------- + +Reverse engineering the BIOS is more straight-forward than just poking around all GPIO pins, +but in itself a quite advanced topic, so it is explained in detail in :doc:`reverse_engineering`. +It basically is about analyzing what the BIOS or the vendor tool does to update the flash rom. + +How to add the board enable to flashrom +======================================= + +First, find out whether the board enable method you found out is already used for another mainboard. +In the case that it is just raising or lowering one GPIO pin, it could be quite possible that this is the case. +As we don't like code duplication, reuse that function. If it is named something like "board_vendor_model" +but really just changes a single pin (board_epox_ep_bx3 is an example in r803), rename it to what it does, +which would be intel_piix4_gpo22_raise in this case. Add a comment to the function that it also works on your board. + +If you don't find a function that does what you want, write it yourself, +also trying to reuse codes for parts of what you have to do. +Add a comment mentioning the board name and the involved chips in this case too. + +After having written an enable function, you just need to add it to the board enable table +(board_pciids_enables). This table maps PCI IDs found on the board to the correct enabling functions. +Be sure to write a good match (which mostly means that you have to choose onboard chips +that have vendor-assigned subsystem IDs that are unique for each board that vendor produced). +If a unique match is not possible at all, provide vendor and model name (short form, usually lower case only) +as "coreboot IDs" for use with the "-m" option, which means that the board won't be autodetected +but can be selected by hand. The board name and vendor name following the coreboot ID strings are freeform +and should disply vendor and model name in their preferred form. diff --git a/doc/contrib_howtos/board_enable/reverse_engineering.rst b/doc/contrib_howtos/board_enable/reverse_engineering.rst new file mode 100644 index 0000000..c188d55 --- /dev/null +++ b/doc/contrib_howtos/board_enable/reverse_engineering.rst @@ -0,0 +1,107 @@ +=========================================== +Finding Board Enable by Reverse Engineering +=========================================== + +**Note the document below was migrated from old website and the content >10yrs old** +Patches to add/update documentation are very much appreciated. + +Finding the board enable code inside the flash rom seems like looking for a needle in a haystack, +but using the right search method might be as easy as finding a magnetic needle using a strong magnet. +This page explains approaches to find the board enable code in different vendor BIOSes. + +Useful Tools +============ + +For free/open source reverse engineering tools, take a look at objdump and ndisasm. + +For objdump, use:: + + objdump -b binary -m i386 -M i8086,intel --disassemble-all datafile.bin + +(you might want to leave off the "intel" option if you prefer the AT&T assembler syntax) + +But as all free tools we know of are not comparable to the commercial tool `IDA Pro <http://www.hex-rays.com/idapro/>`_ +which has free-as-in-beer version for non-commercial use `IDA 4.9 Freeware <http://www.hex-rays.com/idapro/idadownfreeware.htm>`_ +which has all features needed for BIOS analysis, it should be mentioned here, too. + +General Hints +============= + +* Get an lspci of that board before you start. Best way is to request it from the board owner, + but you might find it on Google. Everest Reports of systems include an hexdump of config space at the end. + +* Get used to the binary PCI address specification: Device/function ID is combined into one byte, + the device ID (0..31) is multiplied by eight and added/ored with the function ID (0..7). + Most PCI addresses in the BIOS have the resulting byte hardcoded. + So if this byte is 0xF9 for example, it is 1f.1 in lspci syntax. + +* In/Out to fixed I/O addresses above 0x400 is usually accessing GPIO pins. + The base address can usually be found in PCI config space, but many BIOS vendors hard-code + the address as they know what address their own BIOS configures the GPIO address to. + Typical base values are 0x400 or 0x800 on Intel ICH and 0x4400 on nVidia MCP. + Check the GPIO setting function for the chipset on the board early to recognize patterns + in the assembly code (you *did* get the lspci before you started, + so you can easily look up which chipset and which GPIO method is used, didn't you?) + +Vendor-specific Hints +===================== + +Award BIOS +---------- + +First, you need the runtime BIOS, this is the 128KB thats available at the addresses E0000-FFFFF +when the system is running. You can either obtain it by dumping from a running system, +or by running "lha x bios.bin" on a BIOS image as it gets written to the chip. + +From the 128KB you only need the second half (the f-segment). In this segment, look for the text "AWDFLASH". +This signature is followed by eleven 16-bit procedure offsets (all these procedures reside in the segment F000). +The second procedure offset points to the board/chipset enable function. +The third procedure offset points to the board/chipset disable function. + +Useful hints: + +* PCI register manipulation is common. If you find a procedure that outputs something to port CF8, + it accesses PCI configuration space. If a second out instruction follows, it is a PCI config write, + if an in instruction follows, it's a PCI config read. In AWARD BIOS code, + the Device/Function ID is passed in CH, the config space address in CL. Bus number + (if used at all, check the procedure called) in BH or BL. Data is exchanged via AL/AX/EAX + +AMI BIOS +-------- + +Get the runtime F-segment of the BIOS. Currently there is no automated extraction method +available than dumping from a running machine. Flashing is handled through Int 16 +(entry point at F000:E82E, look for AH=E0, usually catched in the very beginning), +but can also be found in a different way. For each similar group of flash chips, +there is a call table with three 16 bit offsets for identifying, erasing and writing the chip. +In most AMI biosses, this table is quite closely followed by a pointer to the flash chip name +and a list of strings containing all flash chip names in this group. The identification procedure +adjusts the pointer to point to the right string. Finding flashing procedures can be done by searching +for magic constants like 0x2AA, 0xAAA, 0x2AAA and looking at the code. All low-level-flashing code +for one group is quite close together, so poking around to find the main entry points is feasible. + +There is a table at some other place that (amongs other data) contains the offset +of the call table for each group. The offset of this table is referenced in the generic flashing code +that tends to be shortly before the group-specific code. Usually, on detection the address of one group +call table is stored in a "current group" pointer, which in the running system points to one +of the group entries, too. There will be a function that references this current group pointer +and calls the erase function [bx+2] (maybe via a looping helper function) and the write function +[bx+4] in quick succession. The function called before the erase function is the flash enable function. + +If you go the forward route, trace Int 16, AX=E025 which should call the erase procedure. + +Useful hints: + +* PCI access in AMI commonly uses a bit fiddling function. This function takes the bus number in DH, + the device/function number in DL, a bit mask in BH, bits to be set in BL, and the config space address in AH. + It clears all bits set in BH and sets the bit set in BL. It returns the old value (all bits) in AL, + and sets the zero flag if all bits in BH were already clear. This function is wrapped by a generic bit setting + and a generic bit clearing function. These functions take a bit mask (usually only one bit set) in AL. + The bit setting function calls the bit manipulation function with BH=0 and BL=AL, + the bit clearing function calls the bit manipulation function with BH=AL and BL=0. + +FOSDEM presentation +=================== + +There was a talk at FOSDEM 2010 about reverse engineering board enables. +The `slides are here <http://people.freedesktop.org/~libv/flash_enable_bios_reverse_engineering_(…>`_ diff --git a/doc/contrib_howtos/index.rst b/doc/contrib_howtos/index.rst index 3df2fac..bbdb9a7 100644 --- a/doc/contrib_howtos/index.rst +++ b/doc/contrib_howtos/index.rst @@ -8,6 +8,7 @@ how_to_mark_chip_tested how_to_add_unit_test laptops_and_ec + board_enable/index ../how_to_add_docs ../how_to_support_flashrom -- To view, visit https://review.coreboot.org/c/flashrom/+/86329?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I0aaa39679514f667c70ba50f6b726e8d1bd07825 Gerrit-Change-Number: 86329 Gerrit-PatchSet: 4 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

[M] Change in flashrom[main]: doc: Migrate doc about raspberry pi
by Anastasia Klimchuk (Code Review) 13 Feb '25

13 Feb '25

Anastasia Klimchuk has submitted this change. ( https://review.coreboot.org/c/flashrom/+/86312?usp=email ) Change subject: doc: Migrate doc about raspberry pi ...................................................................... doc: Migrate doc about raspberry pi Old doc: https://wiki.flashrom.org/RaspberryPi Change-Id: Ie3b7f2ed31f0b756815de055a2c58602263dac66 Signed-off-by: Anastasia Klimchuk <aklm(a)flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/86312 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> --- M doc/user_docs/index.rst A doc/user_docs/raspberry_pi.rst 2 files changed, 57 insertions(+), 0 deletions(-) Approvals: build bot (Jenkins): Verified Stefan Reinauer: Looks good to me, approved diff --git a/doc/user_docs/index.rst b/doc/user_docs/index.rst index e03789e..7c56a28 100644 --- a/doc/user_docs/index.rst +++ b/doc/user_docs/index.rst @@ -12,6 +12,7 @@ misc_intel in_system msi_jspi1 + raspberry_pi misc_notes .. Keep misc notes last diff --git a/doc/user_docs/raspberry_pi.rst b/doc/user_docs/raspberry_pi.rst new file mode 100644 index 0000000..db0e75f --- /dev/null +++ b/doc/user_docs/raspberry_pi.rst @@ -0,0 +1,56 @@ +=========== +RaspberryPi +=========== + +`RaspberryPi <http://www.raspberrypi.org/faqs>`_ is a cheap single-board computer developed in the UK +by the Raspberry Pi Foundation with the intention of stimulating the teaching of basic computer science in schools. +It can run a fully-functional GNU/Linux distribution and exposes SPI, I2C and several GPIOs on its expansion header. + +Prerequisites +============= + +Use latest Raspbian (or any other distribution with a recent kernel). +Run the following commands (or make sure these kernel modules are loaded successfully):: + + modprobe spi_bcm2835 # If that fails you may wanna try the older spi_bcm2708 module instead + modprobe spidev + +Connecting the flash chip +========================= + +To learn more about the RPi's expansion header refer to http://elinux.org/Rpi_Low-level_peripherals . +If you use one of the first A or B models, please make sure to not draw more than 50mA from the 3.3V pin. +Official numbers for newer models are hard to find but they use a switching regulator +that should provide a much higher margin. If the flash chip is still placed in a foreign circuit +(e.g. soldered to a PC mainboard) please refer to :doc:`/user_docs/in_system` for further details. + +========== ======================= +RPi header SPI flash +========== ======================= +25 GND +24 /CS +23 SCK +21 DO +19 DI +17 VCC 3.3V (+ /HOLD, /WP) +========== ======================= + +.. container:: danger, admonition + + Always connect all input pins of integrated circuits (not only flash chips). + +In general the other pins (usually pin 3 is /WP and pin 7 is /HOLD) should be connected to Vcc +unless they are required to be floating or connected to GND (both extremely uncommon for SPI flash chips). +Please consult the datasheet for the flash chip in question. + +If your flash chip is detected but your read/write/verify operations tend to fail, try to add decoupling capacitors (one 100nF and one 4.7uF ceramic capacitor is preferred) close to the flash chip's power pin. + +Running flashrom +================ + +Flashrom uses the Linux-native SPI driver, which is implemented by flashrom's linux_spi programmer. +To use the RaspberryPi with flashrom, you have to specify that programmer. You should always tell +it at what speed the SPI bus should run; you specify that with the spispeed parameter (given in kHz). +You also have to specify the Linux SPI device, e.g.:: + + flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1000 -- To view, visit https://review.coreboot.org/c/flashrom/+/86312?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: merged Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: Ie3b7f2ed31f0b756815de055a2c58602263dac66 Gerrit-Change-Number: 86312 Gerrit-PatchSet: 2 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

[M] Change in flashrom[main]: libflashrom: Update the API for progress callback
by Sergii Dmytruk (Code Review) 12 Feb '25

12 Feb '25

Attention is currently required from: Anastasia Klimchuk, Peter Marheine, Richard Hughes. Sergii Dmytruk has posted comments on this change by Anastasia Klimchuk. ( https://review.coreboot.org/c/flashrom/+/86031?usp=email ) Change subject: libflashrom: Update the API for progress callback ...................................................................... Patch Set 5: (1 comment) File include/libflashrom.h: https://review.coreboot.org/c/flashrom/+/86031/comment/ec2c2ef3_24e76356?us… : PS2, Line 90: * @deprecated Use flashrom_set_progress_callback_v1 instead > I wrote all the code to handle two callbacks, with v2 callback having priority (still have the code […] That doesn't strike me as a problem. There could still be a pointer to a client-managed progress state along with the internal state, just need to copy data into the former before invoking v1 callback. Overall, a more convenient callback just doesn't seem to me like a good enough reason for breaking any compatibility. On the other hand, repology.org shows only a single `libflashrom` package. -- To view, visit https://review.coreboot.org/c/flashrom/+/86031?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: Ia8cc0461c449b7e65888a64cdc594c55b81eae7a Gerrit-Change-Number: 86031 Gerrit-PatchSet: 5 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Reviewer: Richard Hughes <richard(a)hughsie.com> Gerrit-Reviewer: Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Richard Hughes <richard(a)hughsie.com> Gerrit-Attention: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Attention: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Comment-Date: Wed, 12 Feb 2025 16:56:57 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Anastasia Klimchuk <aklm(a)chromium.org> Comment-In-Reply-To: Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com>

1 0

[M] Change in flashrom[main]: doc: autogenerate a list of authors
by Anastasia Klimchuk (Code Review) 12 Feb '25

12 Feb '25

Attention is currently required from: Peter Marheine. Anastasia Klimchuk has posted comments on this change by Peter Marheine. ( https://review.coreboot.org/c/flashrom/+/86350?usp=email ) Change subject: doc: autogenerate a list of authors ...................................................................... Patch Set 5: (2 comments) This change is ready for review. Patchset: PS5: This is so awesome, Peter thank you so much!! <3 Having a Hall of Fame page, is one of my dreams coming true! :) File doc/collect-authors.sh: https://review.coreboot.org/c/flashrom/+/86350/comment/b5356d3a_78b3c038?us… : PS5, Line 22: git --no-pager shortlog --summary \ : --group=author --group="trailer:Co-Authored-by" --group="trailer:Reviewed-by" I have two thoughts, if it's possible to do: 1) ordering by # of commits DESC 2) if we could have two sections , Authors and Reviewers Thank you so much! -- To view, visit https://review.coreboot.org/c/flashrom/+/86350?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I1e9634a90e84262aafd80590deba9875f4b71a3c Gerrit-Change-Number: 86350 Gerrit-PatchSet: 5 Gerrit-Owner: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Reviewer: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Comment-Date: Wed, 12 Feb 2025 03:19:52 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No

1 0

[S] Change in flashrom[main]: flashchips: Add Macronix MX77U25650FZ4I42
by Dolan Liu (Code Review) 11 Feb '25

11 Feb '25

Dolan Liu has uploaded this change for review. ( https://review.coreboot.org/c/flashrom/+/86348?usp=email ) Change subject: flashchips: Add Macronix MX77U25650FZ4I42 ...................................................................... flashchips: Add Macronix MX77U25650FZ4I42 Add initial support for Macronix MX77U25650F Bug=N/A TEST=sudo emerge flashrom and futility bios image via servo Change-Id: I7866b2db343f4eb2bc194400ceca099d3af3b87d --- M flashchips/macronix.c M include/flashchips.h 2 files changed, 39 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/flashrom refs/changes/48/86348/1 diff --git a/flashchips/macronix.c b/flashchips/macronix.c index a66598b..745014d 100644 --- a/flashchips/macronix.c +++ b/flashchips/macronix.c @@ -2865,6 +2865,44 @@ { .vendor = "Macronix", + .name = "MX77U25650F", + .bustype = BUS_SPI, + .manufacture_id = MACRONIX_ID, + .model_id = MACRONIX_MX77U25650F, + .total_size = 32768, + .page_size = 256, + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_CFGR | FEATURE_4BA, + .tested = TEST_OK_PREW, + .probe = PROBE_SPI_RDID, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 8192} }, + .block_erase = SPI_BLOCK_ERASE_20, + }, { + .eraseblocks = { {32 * 1024, 1024} }, + .block_erase = SPI_BLOCK_ERASE_52, + }, { + .eraseblocks = { {64 * 1024, 512} }, + .block_erase = SPI_BLOCK_ERASE_D8, + }, { + .eraseblocks = { {32 * 1024 * 1024, 1} }, + .block_erase = SPI_BLOCK_ERASE_60, + }, { + .eraseblocks = { {32 * 1024 * 1024, 1} }, + .block_erase = SPI_BLOCK_ERASE_C7, + } + }, + .printlock = SPI_PRETTYPRINT_STATUS_REGISTER_BP3_SRWD, /* bit6 is quad enable */ + .unlock = SPI_DISABLE_BLOCKPROTECT_BP3_SRWD, + .write = SPI_CHIP_WRITE256, + .read = SPI_CHIP_READ, /* Fast read (0x0B) supported */ + .voltage = {1650, 2000}, + }, + + { + .vendor = "Macronix", .name = "MX77U51250F", .bustype = BUS_SPI, .manufacture_id = MACRONIX_ID, diff --git a/include/flashchips.h b/include/flashchips.h index 556729c..2ff4661 100644 --- a/include/flashchips.h +++ b/include/flashchips.h @@ -550,6 +550,7 @@ #define MACRONIX_MX25L6495F 0x9517 #define MACRONIX_MX25L3255E 0x9e16 #define MACRONIX_MX77L25650F 0x7519 +#define MACRONIX_MX77U25650F 0x7539 #define MACRONIX_MX77U51250F 0x753A #define MACRONIX_MX25L3239E 0x2536 -- To view, visit https://review.coreboot.org/c/flashrom/+/86348?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I7866b2db343f4eb2bc194400ceca099d3af3b87d Gerrit-Change-Number: 86348 Gerrit-PatchSet: 1 Gerrit-Owner: Dolan Liu <liuyong5(a)huaqin.corp-partner.google.com>

1 0

[M] Change in flashrom[main]: libflashrom: Update the API for progress callback
by Anastasia Klimchuk (Code Review) 10 Feb '25

10 Feb '25

Attention is currently required from: Peter Marheine, Richard Hughes, Sergii Dmytruk. Anastasia Klimchuk has posted comments on this change by Anastasia Klimchuk. ( https://review.coreboot.org/c/flashrom/+/86031?usp=email ) Change subject: libflashrom: Update the API for progress callback ...................................................................... Patch Set 5: (2 comments) File include/libflashrom.h: https://review.coreboot.org/c/flashrom/+/86031/comment/53344892_d198fc7e?us… : PS2, Line 90: * @deprecated Use flashrom_set_progress_callback_v1 instead I wrote all the code to handle two callbacks, with v2 callback having priority (still have the code locally). But then I realised there is one line which is not backwards compatible and I don't want to change it back :\ Apart from v2 API being easier to use, there is one more point: in old API client needed to own progress state and allocate memory for it, which doesn't seem right. user_data is fine, but entire progress state should not be owned by the client. So I changed progress_state in flash context not to be a pointer anymore... which breaks the clever way of using old API by keeping the pointer in global state. line 70 in base version of libflashrom.c is not possible to do anymore. > It depends on how stable the API is supposed to be. I was trying to recall conversations about this, because I don't know whether there were any official promises. I don't see promises in libflashrom.h, checked old website, nothing specific. I found prior art: https://ticket.coreboot.org/issues/381 , so the versioning question was raised almost 3yr ago, and still open So I can't find any promises about API being stable, but also don't want to return progress_state to a pointer owned by the client. I was fine to keep the old code and keep two callbacks , but now this situation with progress state seems too much. I can also make a post on the mailing list (before or after this patch) to ask if there are users of old callback, and are they fine to rebuild with v2 ? File libflashrom.c: https://review.coreboot.org/c/flashrom/+/86031/comment/403329f0_7a32a590?us… : PS5, Line 70: flashctx->progress_state = progress_state; This line is no longer possible , with the change in line 625 in include/flash.h -- To view, visit https://review.coreboot.org/c/flashrom/+/86031?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: Ia8cc0461c449b7e65888a64cdc594c55b81eae7a Gerrit-Change-Number: 86031 Gerrit-PatchSet: 5 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Reviewer: Richard Hughes <richard(a)hughsie.com> Gerrit-Reviewer: Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Richard Hughes <richard(a)hughsie.com> Gerrit-Attention: Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com> Gerrit-Attention: Peter Marheine <pmarheine(a)chromium.org> Gerrit-Comment-Date: Mon, 10 Feb 2025 11:57:29 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Anastasia Klimchuk <aklm(a)chromium.org> Comment-In-Reply-To: Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com>

1 0

[L] Change in flashrom[main]: doc: Migrate collection of docs about board enable
by Stefan Reinauer (Code Review) 10 Feb '25

10 Feb '25

Attention is currently required from: Anastasia Klimchuk. Stefan Reinauer has posted comments on this change by Anastasia Klimchuk. ( https://review.coreboot.org/c/flashrom/+/86329?usp=email ) Change subject: doc: Migrate collection of docs about board enable ...................................................................... Patch Set 3: Code-Review+2 -- To view, visit https://review.coreboot.org/c/flashrom/+/86329?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: flashrom Gerrit-Branch: main Gerrit-Change-Id: I0aaa39679514f667c70ba50f6b726e8d1bd07825 Gerrit-Change-Number: 86329 Gerrit-PatchSet: 3 Gerrit-Owner: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Reviewer: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Attention: Anastasia Klimchuk <aklm(a)chromium.org> Gerrit-Comment-Date: Sun, 09 Feb 2025 22:26:33 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

flashrom-gerrit February 2025