- flashrom - mail.coreboot.org

M25P16, erase (ok) and write (not ok)
by Raven 01 Mar '15

01 Mar '15

Hello, here are the test results for "Found Micron/Numonyx/ST flash chip "M25P16" (2048 kB, SPI)". Erase seems to work, but write fails. I tried it with an Arduino Uno (http://www.flashrom.org/Serprog/Arduino_flasher). Output is attached. Greetings

5 17

New ECS board tested
by Alex 01 Mar '15

01 Mar '15

Hi, I just tested wit success the ECS GF7050VT-M board. The flash operation was ok, the board restarted ok. Attached you have the flashrom -V output. Thank you very much for your kindness and efforts. Alex.

3 2

Intel Bay Trail read report
by Antonio Ospite 01 Mar '15

01 Mar '15

Hi, I've got a Bay Trail tablet[1] and I tested flashrom on it, see the attached report. As reported in [1] I compiled flashrom statically on my host and then executed it under Android on the target. Reading the SPI flash works fine, is it safe enough to test writing too? I ask because accessing the SPI flash physically for external programming can be a little more inconvenient for a tablet. Another question: would it be possible to use flashrom to only reset the firmware _settings_, while leaving the code untouched? Thanks, Antonio [1] http://ao2.it/110 -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?

2 4

Re: [flashrom] Add PICkit2 as an SPI programmer
by Stefan Tauner 01 Mar '15

01 Mar '15

On Sat, 14 Feb 2015 17:39:25 -0500 Justin Chevrier <jchevrier(a)gmail.com> wrote: > The patch as committed works fine here (only tested read). In > addition, I tried other voltage values (eg. 2.9V, 3.3V, 3.1V) beyond > the 3 currently supported and the hardware happily sets those voltages > as well. So we should remove the current limitation after some more testing... I'll leave this email here as an reminder. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] [PATCH] Refine version check of libpci function pci_get_dev.
by Stefan Tauner 01 Mar '15

01 Mar '15

On Mon, 26 Jan 2015 02:20:18 +0100 Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> wrote: > The way more elegant check for the header fails unfortunately on CentOS 4.9 > because PCI_LIB_VERSION is not defined at all although the domain parameter > is present. This patch jumps through the hoops via an additional check in the > Makefile to determine if the function accepts 5 parameters (new version) or > not (old version). > > Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Self-acked and committed in r1880. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Abit KN9 board enable method, lspci -nnv
by Georg Sauthoff 01 Mar '15

01 Mar '15

Hi, as discussed on IRC (#flashrom) today, current flashrom trunk fails writing the flash chip on an Abit KN9 Ultra/SLI board. Reading works, though. The failure message is: flashrom/trunk/flashrom --programmer internal -c Pm49FL004 -w M520A_23.BIN flashrom v0.9.8-rc1-r1885 on Linux 3.2.0-4-amd64 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found chipset "NVIDIA MCP55". Enabling flash write... OK. Found PMC flash chip "Pm49FL004" (512 kB, LPC, FWH) mapped at physical address 0x00000000fff80000. === This flash part has status UNTESTED for operations: ERASE WRITE 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(a)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. Thanks for your help! Reading old flash chip contents... done. Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, Found=0x49, failed byte count from 0x00000000-0x00000fff: 0x730 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x49, failed byte count from 0x00000000-0x0000ffff: 0x730 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x49, failed byte count from 0x00000000-0x0007ffff: 0x57f07 ERASE FAILED! Looking for another erase function. No usable erase functions left. FAILED! Uh oh. Erase/write failed. Checking if anything has changed. Reading current flash chip contents... done. Good, writing to the flash chip apparently didn't do anything. This means we have to add special support for your board, programmer or flash chip. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks! It fails because the chip is write protected, by default. It turns out that the board enable method for the Abit KN9 Ultra is the same as for the Abit KN8 Ultra - which is already included in flashrom (nvidia_mcp_gpio2_lower()). That means that I could successfully flash that chip multiple times with flashrom using that board enable code. For illustration, I include the ghetto-style patch I've used: @@ -2313,7 +2313,7 @@ {0x8086, 0x24d3, 0x147b, 0x1014, 0x8086, 0x2578, 0x147b, 0x1014, NULL, NULL, NULL, P3, "abit", "IC7", 0, NT, intel_ich_gpio23_raise}, {0x8086, 0x2930, 0x147b, 0x1084, 0x11ab, 0x4364, 0x147b, 0x1084, NULL, NULL, NULL, P3, "abit", "IP35", 0, OK, intel_ich_gpio16_raise}, {0x8086, 0x2930, 0x147b, 0x1083, 0x10ec, 0x8167, 0x147b, 0x1083, NULL, NULL, NULL, P3, "abit", "IP35 Pro", 0, OK, intel_ich_gpio16_raise}, - {0x10de, 0x0050, 0x147b, 0x1c1a, 0x10de, 0x0052, 0x147b, 0x1c1a, NULL, NULL, NULL, P3, "abit", "KN8 Ultra", 0, NT, nvidia_mcp_gpio2_lower}, + {0x10de, 0x0050, 0x147b, 0x1c1a, 0x10de, 0x0052, 0x147b, 0x1c1a, NULL, NULL, NULL, P3, "abit", "KN8 Ultra", 0, OK, nvidia_mcp_gpio2_lower}, {0x10de, 0x01e0, 0x147b, 0x1c00, 0x10de, 0x0060, 0x147B, 0x1c00, NULL, NULL, NULL, P3, "abit", "NF7-S", 0, OK, nvidia_mcp_gpio8_raise}, {0x10de, 0x02f0, 0x147b, 0x1c26, 0x10de, 0x0260, 0x147b, 0x1c26, NULL, NULL, NULL, P3, "abit", "NF-M2 nView", 0, OK, nvidia_mcp_gpio4_lower}, {0x1106, 0x0691, 0, 0, 0x1106, 0x3057, 0, 0, "(VA6)$", NULL, NULL, P3, "abit", "VA6", 0, OK, via_apollo_gpo4_lower}, @@ -2578,6 +2578,8 @@ */ const static struct board_match *board_match_pci_ids(enum board_match_phase phase) { + return board_matches + 7; + const struct board_match *board = board_matches; for (; board->vendor_name; board++) { Of course, for inclusion, proper PCI ids should be configured for the Abit KN9 Ultra board via that table. For that, the `lspci -nnv` output is attached. Best regards Georg -- 'There have been no suggestions that Jay-Z's fellow rapper 50 Cent could be considering a move into a different currency.' ( Rapper Jay-Z dissing the dollar. http://news.bbc.co.uk/2/hi/7097736.stm )

2 1

W836xx: Dell Latitude e6540: flashrom -V
by Steven Honeyman 28 Feb '15

28 Feb '15

flashrom v0.9.8-rc1-r1885 on Linux 3.19.0-e6540 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.3.0, GCC 4.9.2 20150204 (prerelease), little endian Command line (3 args): flashrom -V -p internal Calibrating delay loop... OS timer resolution is 1 usecs, 3258M loops per second, 10 myus = 10 us, 100 myus = 120 us, 1000 myus = 1013 us, 10000 myus = 9973 us, 4 myus = 14 us, OK. Initializing internal programmer No coreboot table found. Using Internal DMI decoder. DMI string chassis-type: "Laptop" Laptop detected via DMI. DMI string system-manufacturer: "Dell Inc." DMI string system-product-name: "Latitude E6540633B600D1/" DMI string system-version: "01" DMI string baseboard-manufacturer: "Dell Inc." DMI string baseboard-product-name: "05V0V4" DMI string baseboard-version: "A00" W836xx enter config mode worked or we were already in config mode. W836xx leave config mode had no effect. Active config mode, unknown reg 0x20 ID: 00. Please send the output of "flashrom -V -p internal" to flashrom(a)flashrom.org with W836xx: your board name: flashrom -V as the subject to help us finish support for your Super I/O. Thanks. ======================================================================== WARNING! You seem to be running flashrom on an unsupported laptop. Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See the manpage and http://www.flashrom.org/Laptops for details. If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== Aborting. Error: Programmer initialization failed.

1 0

Re: [flashrom] [PATCH RFC] Access PCI BARs through sysfs
by Ed Swierk 26 Feb '15

26 Feb '15

On Thu, Feb 26, 2015 at 4:10 AM, Patrick Georgi <pgeorgi(a)google.com> wrote: > 2015-02-26 1:57 GMT+01:00 Ed Swierk <eswierk(a)skyportsystems.com>: >> Running flashrom on a Linux system with CONFIG_STRICT_DEVMEM=y, I can now >> successfully program the SPI flash on an Intel 10G NIC using the > >> +#if !defined(__DJGPP__) && !defined(__LIBPAYLOAD__) >> +static void *pcidev_mapbar_sysfs(struct pci_dev *dev, const char *descr, int bar, off_t offset, size_t length) > Isn't that actually Linux specific, instead of non-djgpp-or-libpayload specific? I suppose that's a safe assumption, though I don't know much about any of the other platforms flashrom supports. libpci already figures out whether the platform supports sysfs. I piggyback off that logic by checking pacc->method. Here we're just deciding whether the platform uses mmap() to access physical address space. I followed the same approach used in physmap.c, since pcidev_mapbar_sysfs() is doing the same thing as sys_physmap_rw_uncached(), just with a PCI resource file instead of /dev/mem. But I can switch to #if IS_LINUX if you think that's clearer. We can revisit that if and when some other sprouts a similar mmapped sysfs interface to PCI resources. --Ed

1 0

[PATCH RFC] Access PCI BARs through sysfs
by Ed Swierk 26 Feb '15

26 Feb '15

Various kernel options are known to interfere with flashrom's attempts to access physical memory through /dev/mem. Some (like CONFIG_STRICT_DEVMEM) are important security measures that cannot be disabled without recompiling the kernel, and are likely to be used more widely over time. However, complete access to physical memory is unnecessary if the SPI interface can be accessed by mapping a BAR resource file in the PCI device directory in sysfs. I added a function pcidev_mapbar() that maps a PCI BAR resource through sysfs if possible; otherwise it falls back to the existing pcidev_mapbar()/rphysmap() method. I modified several programmers to call pcidev_mapbar(). I also removed the rget_io_perms() call, since obtaining IO privileges is unnecessary when using the sysfs access method (the whole point of the patch!). Instead, rget_io_perms() is now called automatically by pcidev_init() only when using some access method other than sysfs. Several programmers (like satamv) require access to other memory or IO regions as well as PCI BARs. There's little point in converting these, since the programmer still requires IO privileges. And the it8212 programmer tries to enable the ROM BAR before accessing it; I have no idea if sysfs can handle dynamically-appearing BARs, so I left that programmer alone. Running flashrom on a Linux system with CONFIG_STRICT_DEVMEM=y, I can now successfully program the SPI flash on an Intel 10G NIC using the nicintel_spi programmer. I have not tested any other programmers or system configurations. Signed-off-by: Ed Swierk <eswierk(a)skyportsystems.com> Index: drkaiser.c =================================================================== --- drkaiser.c (revision 1885) +++ drkaiser.c (working copy) @@ -59,27 +59,20 @@ int drkaiser_init(void) { struct pci_dev *dev = NULL; - uint32_t addr; - if (rget_io_perms()) - return 1; - dev = pcidev_init(drkaiser_pcidev, PCI_BASE_ADDRESS_2); if (!dev) return 1; - addr = pcidev_readbar(dev, PCI_BASE_ADDRESS_2); - if (!addr) + /* Map 128kB flash memory window. */ + drkaiser_bar = pcidev_mapbar(dev, "Dr. Kaiser PC-Waechter flash memory", + PCI_BASE_ADDRESS_2, 0, DRKAISER_MEMMAP_SIZE); + if (drkaiser_bar == ERROR_PTR) return 1; /* Write magic register to enable flash write. */ rpci_write_word(dev, PCI_MAGIC_DRKAISER_ADDR, PCI_MAGIC_DRKAISER_VALUE); - /* Map 128kB flash memory window. */ - drkaiser_bar = rphysmap("Dr. Kaiser PC-Waechter flash memory", addr, DRKAISER_MEMMAP_SIZE); - if (drkaiser_bar == ERROR_PTR) - return 1; - max_rom_decode.parallel = 128 * 1024; register_par_master(&par_master_drkaiser, BUS_PARALLEL); Index: gfxnvidia.c =================================================================== --- gfxnvidia.c (revision 1885) +++ gfxnvidia.c (working copy) @@ -82,21 +82,12 @@ struct pci_dev *dev = NULL; uint32_t reg32; - if (rget_io_perms()) - return 1; - dev = pcidev_init(gfx_nvidia, PCI_BASE_ADDRESS_0); if (!dev) return 1; - uint32_t io_base_addr = pcidev_readbar(dev, PCI_BASE_ADDRESS_0); - if (!io_base_addr) - return 1; - - io_base_addr += 0x300000; - msg_pinfo("Detected NVIDIA I/O base address: 0x%x.\n", io_base_addr); - - nvidia_bar = rphysmap("NVIDIA", io_base_addr, GFXNVIDIA_MEMMAP_SIZE); + nvidia_bar = pcidev_mapbar(dev, "NVIDIA", PCI_BASE_ADDRESS_0, 0, + GFXNVIDIA_MEMMAP_SIZE); if (nvidia_bar == ERROR_PTR) return 1; Index: nicintel.c =================================================================== --- nicintel.c (revision 1885) +++ nicintel.c (working copy) @@ -62,32 +62,19 @@ int nicintel_init(void) { struct pci_dev *dev = NULL; - uintptr_t addr; - /* Needed only for PCI accesses on some platforms. - * FIXME: Refactor that into get_mem_perms/rget_io_perms/get_pci_perms? - */ - if (rget_io_perms()) - return 1; - /* FIXME: BAR2 is not available if the device uses the CardBus function. */ dev = pcidev_init(nics_intel, PCI_BASE_ADDRESS_2); if (!dev) return 1; - addr = pcidev_readbar(dev, PCI_BASE_ADDRESS_2); - if (!addr) - return 1; - - nicintel_bar = rphysmap("Intel NIC flash", addr, NICINTEL_MEMMAP_SIZE); + nicintel_bar = pcidev_mapbar(dev, "Intel NIC flash", PCI_BASE_ADDRESS_2, + 0, NICINTEL_MEMMAP_SIZE); if (nicintel_bar == ERROR_PTR) return 1; - addr = pcidev_readbar(dev, PCI_BASE_ADDRESS_0); - if (!addr) - return 1; - - nicintel_control_bar = rphysmap("Intel NIC control/status reg", addr, NICINTEL_CONTROL_MEMMAP_SIZE); + nicintel_control_bar = pcidev_mapbar(dev, "Intel NIC control/status reg", PCI_BASE_ADDRESS_0, + 0, NICINTEL_CONTROL_MEMMAP_SIZE); if (nicintel_control_bar == ERROR_PTR) return 1; Index: nicintel_eeprom.c =================================================================== --- nicintel_eeprom.c (revision 1885) +++ nicintel_eeprom.c (working copy) @@ -295,18 +295,12 @@ int nicintel_ee_init(void) { - if (rget_io_perms()) - return 1; - struct pci_dev *dev = pcidev_init(nics_intel_ee, PCI_BASE_ADDRESS_0); if (!dev) return 1; - uint32_t io_base_addr = pcidev_readbar(dev, PCI_BASE_ADDRESS_0); - if (!io_base_addr) - return 1; - - nicintel_eebar = rphysmap("Intel Gigabit NIC w/ SPI EEPROM", io_base_addr, MEMMAP_SIZE); + nicintel_eebar = pcidev_mapbar(dev, "Intel Gigabit NIC w/ SPI EEPROM", PCI_BASE_ADDRESS_0, + 0, MEMMAP_SIZE); nicintel_pci = dev; if (dev->device_id != UNPROG_DEVICE) { uint32_t eec = pci_mmio_readl(nicintel_eebar + EEC); Index: nicintel_spi.c =================================================================== --- nicintel_spi.c (revision 1885) +++ nicintel_spi.c (working copy) @@ -187,23 +187,16 @@ struct pci_dev *dev = NULL; uint32_t tmp; - if (rget_io_perms()) - return 1; - dev = pcidev_init(nics_intel_spi, PCI_BASE_ADDRESS_0); if (!dev) return 1; - uint32_t io_base_addr = pcidev_readbar(dev, PCI_BASE_ADDRESS_0); - if (!io_base_addr) - return 1; - if (dev->device_id < 0x10d8) { - nicintel_spibar = rphysmap("Intel Gigabit NIC w/ SPI flash", io_base_addr, - MEMMAP_SIZE); + nicintel_spibar = pcidev_mapbar(dev, "Intel Gigabit NIC w/ SPI flash", + PCI_BASE_ADDRESS_0, 0, MEMMAP_SIZE); } else { - nicintel_spibar = rphysmap("Intel 10 Gigabit NIC w/ SPI flash", io_base_addr + 0x10000, - MEMMAP_SIZE); + nicintel_spibar = pcidev_mapbar(dev, "Intel 10 Gigabit NIC w/ SPI flash", + PCI_BASE_ADDRESS_0, 0x10000, MEMMAP_SIZE); } if (nicintel_spibar == ERROR_PTR) return 1; Index: ogp_spi.c =================================================================== --- ogp_spi.c (revision 1885) +++ ogp_spi.c (working copy) @@ -125,18 +125,11 @@ } free(type); - if (rget_io_perms()) - return 1; - dev = pcidev_init(ogp_spi, PCI_BASE_ADDRESS_0); if (!dev) return 1; - uint32_t io_base_addr = pcidev_readbar(dev, PCI_BASE_ADDRESS_0); - if (!io_base_addr) - return 1; - - ogp_spibar = rphysmap("OGP registers", io_base_addr, 4096); + ogp_spibar = pcidev_mapbar(dev, "OGP registers", PCI_BASE_ADDRESS_0, 0, 4096); if (ogp_spibar == ERROR_PTR) return 1; Index: pcidev.c =================================================================== --- pcidev.c (revision 1885) +++ pcidev.c (working copy) @@ -25,6 +25,12 @@ #include "programmer.h" #include "hwaccess.h" +#if !defined(__DJGPP__) && !defined(__LIBPAYLOAD__) +#include <fcntl.h> +#include <errno.h> +#include <sys/mman.h> +#endif + struct pci_access *pacc; enum pci_bartype { @@ -174,6 +180,15 @@ pci_init(pacc); /* Initialize the PCI library */ if (register_shutdown(pcidev_shutdown, NULL)) return 1; +#if !defined(__DJGPP__) && !defined(__LIBPAYLOAD__) + if (pacc->method != PCI_ACCESS_SYS_BUS_PCI) { +#else + if (1) { +#endif + /* Acquire IO permissions if SYS_BUS_PCI access method is unavailable. */ + if (rget_io_perms()) + return 1; + } pci_scan_bus(pacc); /* We want to get the list of devices */ return 0; } @@ -252,6 +267,73 @@ return found_dev; } +#if !defined(__DJGPP__) && !defined(__LIBPAYLOAD__) +static void *pcidev_mapbar_sysfs(struct pci_dev *dev, const char *descr, int bar, off_t offset, size_t length) +{ + void *addr; + static char path[PATH_MAX]; + static char *file; + int fd; + + + switch (bar) { + case PCI_BASE_ADDRESS_0: + file = "resource0"; + break; + case PCI_BASE_ADDRESS_1: + file = "resource1"; + break; + case PCI_BASE_ADDRESS_2: + file = "resource2"; + break; + case PCI_BASE_ADDRESS_3: + file = "resource3"; + break; + case PCI_BASE_ADDRESS_4: + file = "resource4"; + break; + case PCI_BASE_ADDRESS_5: + file = "resource5"; + break; + case PCI_ROM_ADDRESS: + file = "rom"; + break; + default: + msg_perr("Error accessing %s: invalid PCI bar 0x%x\n", descr, bar); + return MAP_FAILED; + } + snprintf(path, PATH_MAX, "%s/devices/%04x:%02x:%02x.%d/%s", pci_get_param(pacc, "sysfs.path"), + dev->domain, dev->bus, dev->dev, dev->func, file); + + fd = open(path, O_RDWR | O_SYNC); + if (fd < 0) { + msg_perr("Error accessing %s: open(%s): %s\n", descr, path, strerror(errno)); + return MAP_FAILED; + } + + addr = mmap(NULL, length, PROT_WRITE | PROT_READ, MAP_SHARED, fd, offset); + if (addr == MAP_FAILED) { + msg_perr("Error accessing %s: mmap(%s): %s\n", descr, path, strerror(errno)); + return MAP_FAILED; + } + + return addr; +} +#endif + +void *pcidev_mapbar(struct pci_dev *dev, const char *descr, int bar, off_t offset, size_t length) +{ +#if !defined(__DJGPP__) && !defined(__LIBPAYLOAD__) + if (pacc->method == PCI_ACCESS_SYS_BUS_PCI) + return pcidev_mapbar_sysfs(dev, descr, bar, offset, length); +#endif + + uint32_t baraddr = pcidev_readbar(dev, bar); + if (!baraddr) + return MAP_FAILED; + return rphysmap(descr, baraddr + offset, length); +} + enum pci_write_type { pci_write_type_byte, pci_write_type_word, Index: programmer.h =================================================================== --- programmer.h (revision 1885) +++ programmer.h (working copy) @@ -187,6 +187,7 @@ int pci_init_common(void); uintptr_t pcidev_readbar(struct pci_dev *dev, int bar); struct pci_dev *pcidev_init(const struct dev_entry *devs, int bar); +void *pcidev_mapbar(struct pci_dev *dev, const char *descr, int bar, off_t offset, size_t length); /* rpci_write_* are reversible writes. The original PCI config space register * contents will be restored on shutdown. */ Index: satasii.c =================================================================== --- satasii.c (revision 1885) +++ satasii.c (working copy) @@ -71,12 +71,7 @@ int satasii_init(void) { struct pci_dev *dev = NULL; - uint32_t addr; - uint16_t reg_offset; - if (rget_io_perms()) - return 1; - dev = pcidev_init(satas_sii, PCI_BASE_ADDRESS_0); if (!dev) return 1; @@ -84,21 +79,14 @@ id = dev->device_id; if ((id == 0x3132) || (id == 0x3124)) { - addr = pcidev_readbar(dev, PCI_BASE_ADDRESS_0); - if (!addr) - return 1; - reg_offset = 0x70; + sii_bar = pcidev_mapbar(dev, "SATA SiI registers", + PCI_BASE_ADDRESS_0, 0x70, SATASII_MEMMAP_SIZE); } else { - addr = pcidev_readbar(dev, PCI_BASE_ADDRESS_5); - if (!addr) - return 1; - reg_offset = 0x50; + sii_bar = pcidev_mapbar(dev, "SATA SiI registers", + PCI_BASE_ADDRESS_5, 0x50, SATASII_MEMMAP_SIZE); } - - sii_bar = rphysmap("SATA SiI registers", addr, SATASII_MEMMAP_SIZE); if (sii_bar == ERROR_PTR) return 1; - sii_bar += reg_offset; /* Check if ROM cycle are OK. */ if ((id != 0x0680) && (!(pci_mmio_readl(sii_bar) & (1 << 26))))

2 1

New flashrom logo
by Stefan Tauner 25 Feb '15

25 Feb '15

Hello, we have used two logos in the past for flashrom. The one most are familiar with is actually a generic icon stemming from coreboot's "Related Tools" section, i.e.: http://www.coreboot.org/images/a/ae/Chip_tools.png This is not only set up as the "Mediawiki" icon on flashrom.org but is also used on our Twitter account and other sites like openhub (https://www.openhub.net/p/flashrom) The second logo was specifically designed for this purpose and was used at various occasions in presentation slides and on marketing materials (e.g. posters). Namely http://3.bp.blogspot.com/_PTt3TWYKjnQ/TI_oZ3cqvaI/AAAAAAAAALY/eLvM6K16Glw/s… (the one described as "Different style of bolt" on http://kmacphail.blogspot.de/2010/09/flashrom-logos.html) I think that one is way lesser known since even I was not really aware about the fact that it kind of the "official" logo at the moment. I am not too happy with either. The hammer logo has grown dear to me... the hammer perfectly symbolizes the force we have to exert to get some systems to work and the logo as such is very recognizable. But... I only have it in very low quality... is there a better source for it? It also does not represent our generally gentle and cautious approach when dealing with hardware and our focus on stability. The DIP logo on the other hand is available in SVG (at least Carl-Daniel has it AFAIK), but it looks a bit inanimate. The major problems I have with it are that it is not even nearly rectangular and it is very complex. There is the text with the lightning bolt replacing the h character and the DIP32 chip. Both is ok for posters and other big displays but sucks for other uses where simple, rectangular icons are required. I have spent the last weekend with playing around with Blender and its freestyle renderer that is able to output SVG directly. I have managed to render a 3D model of a SOIC8 chip that way as a base for a possible new logo. It required some cleanup afterwards but it looks way better than everything I could draw by hand ;) I have made two logos that I think are worth sharing. They are quite similar and the only major difference is the orientation of the chip... I have created 3 versions of each: one fully colored, one with outlines only and a two-colored simple version (e.g. for PCB silkscreens). I have attached the Inkscape SVGs as well as 96 pixel-wide PNG exports. I have not decided on an appropriate license... probably something similar to how the coreboot hare is licensed. What do you think about my suggestions and the whole matter? I would love to see proposals for alternatives as well! -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

3 2

Re: [flashrom] [coreboot] New flashrom logo
by Stefan Tauner 24 Feb '15

24 Feb '15

On Mon, 23 Feb 2015 00:50:46 +0100 Peter Stuge <peter(a)stuge.se> wrote: > I don't get the description but the result is as I meant. I agree > that it is much less recognizable. Worth a shot. Maybe rotate a bit > less. logo with half of the rotation attached (15° instead of 30° backwards). -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

issue with using a flashrom with Dediprog (SF100) programmer
by Ansbacher, Nadav 23 Feb '15

23 Feb '15

Hi, We're using flashrom app with a Dediprog (SF100) programmer. Our OS is SLES11. Sometimes, I'm getting the "Dediprog_BAD" log after disconnecting and reconnecting the SF100, I'm getting the "dediprog_GOOD" log. Any idea? Nadav --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [flashrom] [coreboot] New flashrom logo
by Stefan Tauner 22 Feb '15

22 Feb '15

On Sun, 22 Feb 2015 02:16:57 +0100 Peter Stuge <peter(a)stuge.se> wrote: > either make the > lightning bolt smaller or perhaps just remove it, because the > connection between lightning and memory chips isn't so obvious. Removing it (without replacement) is not an option... that would make it simply a chip icon. That by no means qualifies as a good logo for a software project :) The logo's background idea does not have to be obvious (i.e. if one doesn't know it is related to flashrom, one does not necessarily need to derive that relationship), but it should be recognizable and clear once you know it to make the whole logo<->project relation memorable... and I really think that a flash and a rom/chip qualifies to represent flashrom in such a way :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] [coreboot] New flashrom logo
by Stefan Tauner 22 Feb '15

22 Feb '15

On Sun, 22 Feb 2015 02:26:19 +0100 Peter Stuge <peter(a)stuge.se> wrote: > Peter Stuge wrote: > > Stefan Tauner wrote: > > > What do you think about my suggestions and the whole matter? > > > > soic8_30degrees is really good. I would only suggest to perhaps > > rotate > > clockwise > > > around the X axis a little bit, > > to view the chip more from the side, rather than from above. I am not sure where your X axis and origin is, but I have rotated it 30° "back" around the Y axis now :) Is that what you meant? That makes the flash look a bit stupid and makes the whole thing way less recognizable IMHO. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

[PATCH v2] Added support to control the GPIOs in the ft222_spi driver from the command line
by Reggie McMurtrey 22 Feb '15

22 Feb '15

Quick Test --- flashrom.8.tmpl | 17 ++++++++++++ ft2232_spi.c | 81 ++++++++++++++++++++++++++++++++++++++++++++------------- 2 files changed, 80 insertions(+), 18 deletions(-) diff --git a/flashrom.8.tmpl b/flashrom.8.tmpl index 8b5f98c..40d8d84 100644 --- a/flashrom.8.tmpl +++ b/flashrom.8.tmpl @@ -681,6 +681,23 @@ parameter with the .B " flashrom \-p ft2232_spi:divisor=div" .sp syntax. +.sp +If the ft2232_spi device has been integrated into a custom board, or you are using a breakout cable +like the C232HM cable from FTDI you can control the upper bits of the port ( bits 7-4 ) via the +.sp +.B " flashrom \-p ft2232_spi:gpio_dir=dir,gpio_value=value" +.sp +syntax where +.B dir +is a mask defining the directions of the port's upper bits. +.B value +is the value of the bits for the port. Only bits defined as outputs with the +.B dir +argument are affected. For example +.B gpio_dir=0xf0,gpio_value=0x80 +would set the four upper bits of the port as outputs with bit 7 as high, and bits 6 through 4 as +low. This could be useful for controlling write protects, muxing options, or other in +circuit programming related features. .SS .BR "serprog " programmer A mandatory parameter specifies either a serial diff --git a/ft2232_spi.c b/ft2232_spi.c index 4e23797..75cb772 100644 --- a/ft2232_spi.c +++ b/ft2232_spi.c @@ -93,6 +93,9 @@ const struct dev_entry devs_ft2232spi[] = { */ static uint8_t cs_bits = 0x08; static uint8_t pindir = 0x0b; +static uint8_t gpio_dir = 0x00; +static uint8_t gpio_value = 0x00; +static uint8_t adapter_mask = 0x00; static struct ftdi_context ftdic_context; static const char *get_ft2232_devicename(int ft2232_vid, int ft2232_type) @@ -204,10 +207,11 @@ int ft2232_spi_init(void) ft2232_type = AMONTEC_JTAGKEY_PID; channel_count = 2; /* JTAGkey(2) needs to enable its output via Bit4 / GPIOL0 - * value: 0x18 OE=high, CS=high, DI=low, DO=low, SK=low - * dir: 0x1b OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x18; - pindir = 0x1b; + * value: 0x10 OE=high, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) + * dir: 0x10 OE=output, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) */ + gpio_dir = 0x10; + gpio_value = 0x10; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "picotap")) { ft2232_vid = GOEPEL_VID; ft2232_type = GOEPEL_PICOTAP_PID; @@ -224,8 +228,9 @@ int ft2232_spi_init(void) /* In its default configuration it is a jtagkey clone */ ft2232_type = FTDI_FT2232H_PID; channel_count = 2; - cs_bits = 0x18; - pindir = 0x1b; + gpio_dir = 0x10; + gpio_value = 0x10; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "openmoko")) { ft2232_vid = FIC_VID; ft2232_type = OPENMOKO_DBGBOARD_PID; @@ -235,10 +240,11 @@ int ft2232_spi_init(void) ft2232_type = OLIMEX_ARM_OCD_PID; channel_count = 2; /* arm-usb-ocd(-h) has an output buffer that needs to be enabled by pulling ADBUS4 low. - * value: 0x08 #OE=low, CS=high, DI=low, DO=low, SK=low - * dir: 0x1b #OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x08; - pindir = 0x1b; + * value: 0x00 #OE=low, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) + * dir: 0x10 #OE=output, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) */ + gpio_dir = 0x10; + gpio_value = 0x00; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_PID; @@ -248,8 +254,9 @@ int ft2232_spi_init(void) ft2232_type = OLIMEX_ARM_OCD_H_PID; channel_count = 2; /* See arm-usb-ocd */ - cs_bits = 0x08; - pindir = 0x1b; + gpio_dir = 0x10; + gpio_value = 0x00; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny-h")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_H_PID; @@ -262,6 +269,38 @@ int ft2232_spi_init(void) } free(arg); + arg = extract_programmer_param("gpio_dir"); + if (arg && strlen(arg)) { + unsigned int temp = 0; + char *endptr; + temp = strtoul(arg, &endptr, 16); + if (*endptr || temp > 0xFF) { + msg_perr("Error: Invalid GPIO direction mask \"%s\".\n" + "Valid values are between 0x0 and 0xff (the lower four bits are ignored).\n", arg); + free(arg); + return -2; + } else { + gpio_dir = ((uint32_t) temp & (0xf0 & ~adapter_mask)) | gpio_dir; + } + } + free(arg); + + arg = extract_programmer_param("gpio_value"); + if (arg && strlen(arg)) { + unsigned int temp = 0; + char *endptr; + temp = strtoul(arg, &endptr, 16); + if (*endptr || temp > 0xFF) { + msg_perr("Error: Invalid GPIO value mask \"%s\".\n" + "Valid values are between 0x0 and 0xff (the lower four bits are ignored).\n", arg); + free(arg); + return -2; + } else { + gpio_value = ((uint32_t) temp & (0xf0 & ~adapter_mask)) | gpio_value; + } + } + free(arg); + arg = extract_programmer_param("port"); if (arg) { switch (toupper((unsigned char)*arg)) { @@ -391,9 +430,11 @@ int ft2232_spi_init(void) } msg_pdbg("Set data bits\n"); + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[0] = SET_BITS_LOW; - buf[1] = cs_bits; - buf[2] = pindir; + buf[1] = cs_bits | gpio_value; + buf[2] = pindir | gpio_dir; if (send_buf(ftdic, buf, 3)) { ret = -8; goto ftdi_err; @@ -446,9 +487,11 @@ static int ft2232_spi_send_command(struct flashctx *flash, * operations. */ msg_pspew("Assert CS#\n"); + msg_pspew("Value: 0x%02x\n", ~cs_bits & gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[i++] = SET_BITS_LOW; - buf[i++] = 0 & ~cs_bits; /* assertive */ - buf[i++] = pindir; + buf[i++] = ~cs_bits & gpio_value; /* assertive */ + buf[i++] = pindir | gpio_dir; if (writecnt) { buf[i++] = MPSSE_DO_WRITE | MPSSE_WRITE_NEG; @@ -487,9 +530,11 @@ static int ft2232_spi_send_command(struct flashctx *flash, } msg_pspew("De-assert CS#\n"); + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[i++] = SET_BITS_LOW; - buf[i++] = cs_bits; - buf[i++] = pindir; + buf[i++] = cs_bits | gpio_value; + buf[i++] = pindir | gpio_dir; ret = send_buf(ftdic, buf, i); failed |= ret; if (ret) -- 1.9.1

1 0

Re: [flashrom] [PATCH] Added support to control the GPIOs in the ft222_spi driver from the command line
by Stefan Tauner 21 Feb '15

21 Feb '15

On Sat, 21 Feb 2015 15:19:42 -0600 Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote: > Not sure why patch seems mangled. I looked at the mailing list archive to > see what happened and it shows up ok there. I was informed I should have > bumped the subject to [PATCH v2]. I'll make sure to do that in the > future. I'll be glad to post patch again if needed. Focus on the line breaks and number of tabs/spaces after the + signs... clearly some kind of mangling happened. > > Programmer inits don't seem to have any specific meaning other than > pass/fail. Why -2 then? :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] [PATCH] Added support to control the GPIOs in the ft222_spi driver from the command line
by Stefan Tauner 21 Feb '15

21 Feb '15

On Sat, 21 Feb 2015 09:34:23 -0600 Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote: > Thanks for the feedback Stefan, Trying again :) Thanks, but the patch got mangled by your email client apparently. BTW I am not sure what -2 means in programmer inits from the top of my head... if there is a macro name for that please use it. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] [PATCH] Added support to control the GPIOs in the ft222_spi driver from the command line
by Antony Pavlov 21 Feb '15

21 Feb '15

On Sat, 21 Feb 2015 09:34:23 -0600 Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote: > Thanks for the feedback Stefan, Trying again :) You have submitted version 2 of your patch. So please note this fact in the Subject. E.g. use "[PATCH v2]" instead of "[PATCH]" in the message's subject. You can use git-format-patch '--subject-prefix' option or just edit subject by hand. > > Signed-off-by: Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> > > --- > flashrom.8.tmpl | 17 ++++++++++++ > ft2232_spi.c | 81 > ++++++++++++++++++++++++++++++++++++++++++++------------- > 2 files changed, 80 insertions(+), 18 deletions(-) > > diff --git a/flashrom.8.tmpl b/flashrom.8.tmpl > index 8b5f98c..40d8d84 100644 > --- a/flashrom.8.tmpl > +++ b/flashrom.8.tmpl > @@ -681,6 +681,23 @@ parameter with the > .B " flashrom \-p ft2232_spi:divisor=div" > .sp > syntax. > +.sp > +If the ft2232_spi device has been integrated into a custom board, or you > are using a breakout cable > +like the C232HM cable from FTDI you can control the upper bits of the port > ( bits 7-4 ) via the > +.sp > +.B " flashrom \-p ft2232_spi:gpio_dir=dir,gpio_value=value" > +.sp > +syntax where > +.B dir > +is a mask defining the directions of the port's upper bits. > +.B value > +is the value of the bits for the port. Only bits defined as outputs with > the > +.B dir > +argument are affected. For example > +.B gpio_dir=0xf0,gpio_value=0x80 > +would set the four upper bits of the port as outputs with bit 7 as high, > and bits 6 through 4 as > +low. This could be useful for controlling write protects, muxing options, > or other in > +circuit programming related features. > .SS > .BR "serprog " programmer > A mandatory parameter specifies either a serial > diff --git a/ft2232_spi.c b/ft2232_spi.c > index 4e23797..75cb772 100644 > --- a/ft2232_spi.c > +++ b/ft2232_spi.c > @@ -93,6 +93,9 @@ const struct dev_entry devs_ft2232spi[] = { > */ > static uint8_t cs_bits = 0x08; > static uint8_t pindir = 0x0b; > +static uint8_t gpio_dir = 0x00; > +static uint8_t gpio_value = 0x00; > +static uint8_t adapter_mask = 0x00; > static struct ftdi_context ftdic_context; > > static const char *get_ft2232_devicename(int ft2232_vid, int ft2232_type) > @@ -204,10 +207,11 @@ int ft2232_spi_init(void) > ft2232_type = AMONTEC_JTAGKEY_PID; > channel_count = 2; > /* JTAGkey(2) needs to enable its output via Bit4 / GPIOL0 > - * value: 0x18 OE=high, CS=high, DI=low, DO=low, SK=low > - * dir: 0x1b OE=output, CS=output, DI=input, DO=output, SK=output */ > - cs_bits = 0x18; > - pindir = 0x1b; > + * value: 0x10 OE=high, Reserved (CS), Reserved (DI), Reserved (DO), > Reserved (SK) > + * dir: 0x10 OE=output, Reserved (CS), Reserved (DI), Reserved (DO), > Reserved (SK) */ > + gpio_dir = 0x10; > + gpio_value = 0x10; > + adapter_mask = 0x10; > } else if (!strcasecmp(arg, "picotap")) { > ft2232_vid = GOEPEL_VID; > ft2232_type = GOEPEL_PICOTAP_PID; > @@ -224,8 +228,9 @@ int ft2232_spi_init(void) > /* In its default configuration it is a jtagkey clone */ > ft2232_type = FTDI_FT2232H_PID; > channel_count = 2; > - cs_bits = 0x18; > - pindir = 0x1b; > + gpio_dir = 0x10; > + gpio_value = 0x10; > + adapter_mask = 0x10; > } else if (!strcasecmp(arg, "openmoko")) { > ft2232_vid = FIC_VID; > ft2232_type = OPENMOKO_DBGBOARD_PID; > @@ -235,10 +240,11 @@ int ft2232_spi_init(void) > ft2232_type = OLIMEX_ARM_OCD_PID; > channel_count = 2; > /* arm-usb-ocd(-h) has an output buffer that needs to be enabled by > pulling ADBUS4 low. > - * value: 0x08 #OE=low, CS=high, DI=low, DO=low, SK=low > - * dir: 0x1b #OE=output, CS=output, DI=input, DO=output, SK=output */ > - cs_bits = 0x08; > - pindir = 0x1b; > + * value: 0x00 #OE=low, Reserved (CS), Reserved (DI), Reserved (DO), > Reserved (SK) > + * dir: 0x10 #OE=output, Reserved (CS), Reserved (DI), Reserved (DO), > Reserved (SK) */ > + gpio_dir = 0x10; > + gpio_value = 0x00; > + adapter_mask = 0x10; > } else if (!strcasecmp(arg, "arm-usb-tiny")) { > ft2232_vid = OLIMEX_VID; > ft2232_type = OLIMEX_ARM_TINY_PID; > @@ -248,8 +254,9 @@ int ft2232_spi_init(void) > ft2232_type = OLIMEX_ARM_OCD_H_PID; > channel_count = 2; > /* See arm-usb-ocd */ > - cs_bits = 0x08; > - pindir = 0x1b; > + gpio_dir = 0x10; > + gpio_value = 0x00; > + adapter_mask = 0x10; > } else if (!strcasecmp(arg, "arm-usb-tiny-h")) { > ft2232_vid = OLIMEX_VID; > ft2232_type = OLIMEX_ARM_TINY_H_PID; > @@ -262,6 +269,38 @@ int ft2232_spi_init(void) > } > free(arg); > > + arg = extract_programmer_param("gpio_dir"); > + if (arg && strlen(arg)) { > + unsigned int temp = 0; > + char *endptr; > + temp = strtoul(arg, &endptr, 16); > + if (*endptr || temp > 0xFF) { > + msg_perr("Error: Invalid GPIO direction mask \"%s\".\n" > + "Valid values are between 0x0 and 0xff (the lower four bits are > ignored).\n", arg); > + free(arg); > + return -2; > + } else { > + gpio_dir = ((uint32_t) temp & (0xf0 & ~adapter_mask)) | gpio_dir; > + } > + } > + free(arg); > + > + arg = extract_programmer_param("gpio_value"); > + if (arg && strlen(arg)) { > + unsigned int temp = 0; > + char *endptr; > + temp = strtoul(arg, &endptr, 16); > + if (*endptr || temp > 0xFF) { > + msg_perr("Error: Invalid GPIO value mask \"%s\".\n" > + "Valid values are between 0x0 and 0xff (the lower four bits are > ignored).\n", arg); > + free(arg); > + return -2; > + } else { > + gpio_value = ((uint32_t) temp & (0xf0 & ~adapter_mask)) | gpio_value; > + } > + } > + free(arg); > + > arg = extract_programmer_param("port"); > if (arg) { > switch (toupper((unsigned char)*arg)) { > @@ -391,9 +430,11 @@ int ft2232_spi_init(void) > } > > msg_pdbg("Set data bits\n"); > + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); > + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); > buf[0] = SET_BITS_LOW; > - buf[1] = cs_bits; > - buf[2] = pindir; > + buf[1] = cs_bits | gpio_value; > + buf[2] = pindir | gpio_dir; > if (send_buf(ftdic, buf, 3)) { > ret = -8; > goto ftdi_err; > @@ -446,9 +487,11 @@ static int ft2232_spi_send_command(struct flashctx > *flash, > * operations. > */ > msg_pspew("Assert CS#\n"); > + msg_pspew("Value: 0x%02x\n", ~cs_bits & gpio_value); > + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); > buf[i++] = SET_BITS_LOW; > - buf[i++] = 0 & ~cs_bits; /* assertive */ > - buf[i++] = pindir; > + buf[i++] = ~cs_bits & gpio_value; /* assertive */ > + buf[i++] = pindir | gpio_dir; > > if (writecnt) { > buf[i++] = MPSSE_DO_WRITE | MPSSE_WRITE_NEG; > @@ -487,9 +530,11 @@ static int ft2232_spi_send_command(struct flashctx > *flash, > } > > msg_pspew("De-assert CS#\n"); > + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); > + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); > buf[i++] = SET_BITS_LOW; > - buf[i++] = cs_bits; > - buf[i++] = pindir; > + buf[i++] = cs_bits | gpio_value; > + buf[i++] = pindir | gpio_dir; > ret = send_buf(ftdic, buf, i); > failed |= ret; > if (ret) > -- > 1.9.1 > > > On Sat, Feb 21, 2015 at 4:20 AM, Stefan Tauner < > stefan.tauner(a)alumni.tuwien.ac.at> wrote: > > > On Fri, 20 Feb 2015 18:21:09 -0600 > > Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote: > > > > > This is my first time submitting a patch to a project, so let me know > > > if I have done something wrong here. > > > > > > > > > I commonly use the C232HM cable from FTDI to program various parts of > > > boards I design. This one cable allows me to program SPI, I2C, and > > > JTAG parts. Simply adding some muxes to the design I have a single > > > header to attach this cable to. The patch below allows control of the > > > muxes from the GPIOL3-GPIOL0 signals on the cable and disable write > > > protection. I figured other people may like this capability if they > > > are using a similar breakout cable of have designed the ft2232 chip > > > into their design. > > > > > > Signed-off-by: Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> > > > > > > @@ -262,6 +269,18 @@ int ft2232_spi_init(void) > > > } > > > free(arg); > > > > > > + arg = extract_programmer_param("gpio_dir"); > > > + if (arg) { > > > + gpio_dir = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) > > | gpio_dir; > > > + } > > > + free(arg); > > > + > > > + arg = extract_programmer_param("gpio_value"); > > > + if (arg) { > > > + gpio_value = (strtoul(arg, 0, 16) & (0xf0 & > > ~adapter_mask)) | gpio_value; > > > + } > > > + free(arg); > > > + > > > arg = extract_programmer_param("port"); > > > if (arg) { > > > switch (toupper((unsigned char)*arg)) { > > > > Hello Reggie, > > > > thanks for your patch! I had no time to review it in detail but we > > definitely want some error/wrong input handling for the parameter > > parsing above. There are various similar checks throughout the code > > base that you may wanna look at... not all are perfect yet though. If > > you have any doubts then please refer to the strtol(3) manpage. > > > > A more detailed review will follow when that's fixed. > > -- > > Kind regards/Mit freundlichen Grüßen, Stefan Tauner > > -- -- Best regards, Antony Pavlov

1 0

Re: [flashrom] [PATCH] Added support to control the GPIOs in the ft222_spi driver from the command line
by Stefan Tauner 21 Feb '15

21 Feb '15

On Fri, 20 Feb 2015 18:21:09 -0600 Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote: > This is my first time submitting a patch to a project, so let me know > if I have done something wrong here. > > > I commonly use the C232HM cable from FTDI to program various parts of > boards I design. This one cable allows me to program SPI, I2C, and > JTAG parts. Simply adding some muxes to the design I have a single > header to attach this cable to. The patch below allows control of the > muxes from the GPIOL3-GPIOL0 signals on the cable and disable write > protection. I figured other people may like this capability if they > are using a similar breakout cable of have designed the ft2232 chip > into their design. > > Signed-off-by: Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> > > @@ -262,6 +269,18 @@ int ft2232_spi_init(void) > } > free(arg); > > + arg = extract_programmer_param("gpio_dir"); > + if (arg) { > + gpio_dir = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) | gpio_dir; > + } > + free(arg); > + > + arg = extract_programmer_param("gpio_value"); > + if (arg) { > + gpio_value = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) | gpio_value; > + } > + free(arg); > + > arg = extract_programmer_param("port"); > if (arg) { > switch (toupper((unsigned char)*arg)) { Hello Reggie, thanks for your patch! I had no time to review it in detail but we definitely want some error/wrong input handling for the parameter parsing above. There are various similar checks throughout the code base that you may wanna look at... not all are perfect yet though. If you have any doubts then please refer to the strtol(3) manpage. A more detailed review will follow when that's fixed. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

[PATCH] Added support to control the GPIOs in the ft222_spi driver from the command line
by Reggie McMurtrey 21 Feb '15

21 Feb '15

This is my first time submitting a patch to a project, so let me know if I have done something wrong here. I commonly use the C232HM cable from FTDI to program various parts of boards I design. This one cable allows me to program SPI, I2C, and JTAG parts. Simply adding some muxes to the design I have a single header to attach this cable to. The patch below allows control of the muxes from the GPIOL3-GPIOL0 signals on the cable and disable write protection. I figured other people may like this capability if they are using a similar breakout cable of have designed the ft2232 chip into their design. Signed-off-by: Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> *--- flashrom.8.tmpl | 17 ++++++++++++++++ ft2232_spi.c | 61 ++++++++++++++++++++++++++++++++++++++++----------------- 2 files changed, 60 insertions(+), 18 deletions(-) diff --git a/flashrom.8.tmpl b/flashrom.8.tmpl index 8b5f98c..40d8d84 100644 --- a/flashrom.8.tmpl +++ b/flashrom.8.tmpl @@ -681,6 +681,23 @@ parameter with the .B " flashrom \-p ft2232_spi:divisor=div" .sp syntax. +.sp +If the ft2232_spi device has been integrated into a custom board, or you are using a breakout cable +like the C232HM cable from FTDI you can control the upper bits of the port ( bits 7-4 ) via the +.sp +.B " flashrom \-p ft2232_spi:gpio_dir=dir,gpio_value=value" +.sp +syntax where +.B dir +is a mask defining the directions of the port's upper bits. +.B value +is the value of the bits for the port. Only bits defined as outputs with the +.B dir +argument are affected. For example +.B gpio_dir=0xf0,gpio_value=0x80 +would set the four upper bits of the port as outputs with bit 7 as high, and bits 6 through 4 as +low. This could be useful for controlling write protects, muxing options, or other in +circuit programming related features. .SS .BR "serprog " programmer A mandatory parameter specifies either a serial diff --git a/ft2232_spi.c b/ft2232_spi.c index 4e23797..c7a78fe 100644 --- a/ft2232_spi.c +++ b/ft2232_spi.c @@ -93,6 +93,9 @@ const struct dev_entry devs_ft2232spi[] = { */ static uint8_t cs_bits = 0x08; static uint8_t pindir = 0x0b; +static uint8_t gpio_dir = 0x00; +static uint8_t gpio_value = 0x00; +static uint8_t adapter_mask = 0x00; static struct ftdi_context ftdic_context; static const char *get_ft2232_devicename(int ft2232_vid, int ft2232_type) @@ -204,10 +207,11 @@ int ft2232_spi_init(void) ft2232_type = AMONTEC_JTAGKEY_PID; channel_count = 2; /* JTAGkey(2) needs to enable its output via Bit4 / GPIOL0 - * value: 0x18 OE=high, CS=high, DI=low, DO=low, SK=low - * dir: 0x1b OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x18; - pindir = 0x1b; + * value: 0x10 OE=high, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) + * dir: 0x10 OE=output, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) */ + gpio_dir = 0x10; + gpio_value = 0x10; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "picotap")) { ft2232_vid = GOEPEL_VID; ft2232_type = GOEPEL_PICOTAP_PID; @@ -224,8 +228,9 @@ int ft2232_spi_init(void) /* In its default configuration it is a jtagkey clone */ ft2232_type = FTDI_FT2232H_PID; channel_count = 2; - cs_bits = 0x18; - pindir = 0x1b; + gpio_dir = 0x10; + gpio_value = 0x10; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "openmoko")) { ft2232_vid = FIC_VID; ft2232_type = OPENMOKO_DBGBOARD_PID; @@ -235,10 +240,11 @@ int ft2232_spi_init(void) ft2232_type = OLIMEX_ARM_OCD_PID; channel_count = 2; /* arm-usb-ocd(-h) has an output buffer that needs to be enabled by pulling ADBUS4 low. - * value: 0x08 #OE=low, CS=high, DI=low, DO=low, SK=low - * dir: 0x1b #OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x08; - pindir = 0x1b; + * value: 0x00 #OE=low, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) + * dir: 0x10 #OE=output, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) */ + gpio_dir = 0x10; + gpio_value = 0x00; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_PID; @@ -248,8 +254,9 @@ int ft2232_spi_init(void) ft2232_type = OLIMEX_ARM_OCD_H_PID; channel_count = 2; /* See arm-usb-ocd */ - cs_bits = 0x08; - pindir = 0x1b; + gpio_dir = 0x10; + gpio_value = 0x00; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny-h")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_H_PID; @@ -262,6 +269,18 @@ int ft2232_spi_init(void) } free(arg); + arg = extract_programmer_param("gpio_dir"); + if (arg) { + gpio_dir = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) | gpio_dir; + } + free(arg); + + arg = extract_programmer_param("gpio_value"); + if (arg) { + gpio_value = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) | gpio_value; + } + free(arg); + arg = extract_programmer_param("port"); if (arg) { switch (toupper((unsigned char)*arg)) { @@ -391,9 +410,11 @@ int ft2232_spi_init(void) } msg_pdbg("Set data bits\n"); + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[0] = SET_BITS_LOW; - buf[1] = cs_bits; - buf[2] = pindir; + buf[1] = cs_bits | gpio_value; + buf[2] = pindir | gpio_dir; if (send_buf(ftdic, buf, 3)) { ret = -8; goto ftdi_err; @@ -446,9 +467,11 @@ static int ft2232_spi_send_command(struct flashctx *flash, * operations. */ msg_pspew("Assert CS#\n"); + msg_pspew("Value: 0x%02x\n", ~cs_bits & gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[i++] = SET_BITS_LOW; - buf[i++] = 0 & ~cs_bits; /* assertive */ - buf[i++] = pindir; + buf[i++] = ~cs_bits & gpio_value; /* assertive */ + buf[i++] = pindir | gpio_dir; if (writecnt) { buf[i++] = MPSSE_DO_WRITE | MPSSE_WRITE_NEG; @@ -487,9 +510,11 @@ static int ft2232_spi_send_command(struct flashctx *flash, } msg_pspew("De-assert CS#\n"); + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[i++] = SET_BITS_LOW; - buf[i++] = cs_bits; - buf[i++] = pindir; + buf[i++] = cs_bits | gpio_value; + buf[i++] = pindir | gpio_dir; ret = send_buf(ftdic, buf, i); failed |= ret; if (ret) -- 1.9.1*

1 0

Re: [flashrom] Unknown SPI chip on Google Falco with linux_spi
by David Hendricks 19 Feb '15

19 Feb '15

The ID bytes are reading as FF's. Double check your connections <http://flashrom.org/RaspberryPi> and ensure that the C720 is completely powered off (disconnect both the battery and the AC power). On Wed, Feb 18, 2015 at 9:09 PM, Remigijus Jarmalavičius < remigijus(a)jarmalavicius.lt> wrote: > Hi, > > I am trying to unbrick latest Acer C720 with flashrom. What I have already > done: > > > - Created ROM image successfully for writing with flashrom; > - Connected wires from Raspberry Pi to EEPROM chip on C720. > - Enabled kernel modules and tested with spidev_test (it returns data, > looks normal - not all 00's or FF's) > - Download latest flashrom from svn and compiled. > - Then executed: ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0 > > After a lot output it said to me: > > Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on > linux_spi. > Probing for Generic unknown SPI chip (REMS), 0 kB: REMS returned 0xff > 0xff. probe_spi_rems: id1 0xff, id2 0xff > Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI). > === > This flash part has status NOT WORKING for operations: PROBE READ ERASE > WRITE > 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(a)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. > Thanks for your help! > No operations were specified. > > I saw that sometimes chip numbers are not entered to the flashrom source, > maybe it's the same case? I think I have read all sites I found on Google > about unbricking acer c720. What I should try next? > > Some details: > > > - Ubuntu 14 OS on Raspberry Pi B version. > - Acer chromebook c720 (model no: zhn) > > Please help me solve the issue. I am attaching complete log > command: ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0 > log > > > > -- > > *Remigijus Jarmalavičius* > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Unknown SPI chip on Google Falco with linux_spi
by Remigijus Jarmalavičius 19 Feb '15

19 Feb '15

Hi, I am trying to unbrick latest Acer C720 with flashrom. What I have already done: - Created ROM image successfully for writing with flashrom; - Connected wires from Raspberry Pi to EEPROM chip on C720. - Enabled kernel modules and tested with spidev_test (it returns data, looks normal - not all 00's or FF's) - Download latest flashrom from svn and compiled. - Then executed: ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0 After a lot output it said to me: Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on linux_spi. Probing for Generic unknown SPI chip (REMS), 0 kB: REMS returned 0xff 0xff. probe_spi_rems: id1 0xff, id2 0xff Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI). === This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE 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(a)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. Thanks for your help! No operations were specified. I saw that sometimes chip numbers are not entered to the flashrom source, maybe it's the same case? I think I have read all sites I found on Google about unbricking acer c720. What I should try next? Some details: - Ubuntu 14 OS on Raspberry Pi B version. - Acer chromebook c720 (model no: zhn) Please help me solve the issue. I am attaching complete log command: ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0 > log -- *Remigijus Jarmalavičius*

1 0

Re: [flashrom] [PATCH] Fix a number of problems in mstarddc_spi.c.
by Alexandre Boeglin 19 Feb '15

19 Feb '15

Hello, Le mercredi 18 février 2015 à 01:31, Stefan Tauner a écrit: > Coverity has brought up the following problems: Sorry, I wasn't aware that there were coverity reports for the project. > This patch revamps the function in various ways to fix these issues and some > other irritating bits. > It reduces scopes of variables where possible, pushes the code towards our > coding standards and introduces a label-based resource cleanup at the end. I agree, this patch does make the code easier to read, in addition to fixing my mistakes :) Best regards, Alex -- Alexandre Boeglin email: alex (at) boeglin (dot) org jabber: alex (at) im (dot) boeglin (dot) org website: http://boeglin.org/

2 1

[commit] r1885 - trunk
by repository service 19 Feb '15

19 Feb '15

Author: stefanct Date: Thu Feb 19 00:28:30 2015 New Revision: 1885 URL: http://flashrom.org/trac/flashrom/changeset/1885 Log: Fix a number of problems in mstarddc_spi.c. Coverity has brought up the following problems: mstarddc_spi_send_command(): - CID 1270702: bad comparison of malloced pointer 'cmd'. - CID 1270701: a NULL pointer dereference possible because of above. Simply checking the return value of malloc in a valid way fixes both problems. mstarddc_spi_init(): - CID 1270699 and 1270700: Memory leak of i2c_device. This patch revamps the function in various ways to fix these issues and some other irritating bits. It reduces scopes of variables where possible, pushes the code towards our coding standards and introduces a label-based resource cleanup at the end. Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Alexandre Boeglin <alex(a)boeglin.org> Modified: trunk/mstarddc_spi.c Modified: trunk/mstarddc_spi.c ============================================================================== --- trunk/mstarddc_spi.c Wed Feb 11 23:30:30 2015 (r1884) +++ trunk/mstarddc_spi.c Thu Feb 19 00:28:30 2015 (r1885) @@ -74,37 +74,37 @@ /* Returns 0 upon success, a negative number upon errors. */ int mstarddc_spi_init(void) { - char *i2c_device; - char *i2c_address; - char *noreset; + int ret = 0; // Get device, address from command-line - i2c_device = extract_programmer_param("dev"); - if (i2c_device && strlen(i2c_device)) { - if ((i2c_address = strchr(i2c_device, ':'))) { + char *i2c_device = extract_programmer_param("dev"); + if (i2c_device != NULL && strlen(i2c_device) > 0) { + char *i2c_address = strchr(i2c_device, ':'); + if (i2c_address != NULL) { *i2c_address = '\0'; i2c_address++; } - if (!i2c_address || !strlen(i2c_address)) { + if (i2c_address == NULL || strlen(i2c_address) == 0) { msg_perr("Error: no address specified.\n" "Use flashrom -p mstarddc_spi:dev=/dev/device:address.\n"); - return -1; + ret = -1; + goto out; } - mstarddc_addr = strtol(i2c_address, NULL, 16); + mstarddc_addr = strtol(i2c_address, NULL, 16); // FIXME: error handling } else { msg_perr("Error: no device specified.\n" "Use flashrom -p mstarddc_spi:dev=/dev/device:address.\n"); - return -1; + ret = -1; + goto out; } - msg_pinfo("Info: Will try to use device %s and address 0x%02x.\n", - i2c_device, mstarddc_addr); + msg_pinfo("Info: Will try to use device %s and address 0x%02x.\n", i2c_device, mstarddc_addr); // Get noreset=1 option from command-line - if ((noreset = extract_programmer_param("noreset")) - && noreset[0] == '1') + char *noreset = extract_programmer_param("noreset"); + if (noreset != NULL && noreset[0] == '1') mstarddc_doreset = 0; - msg_pinfo("Info: WILL %sreset the device at the end.\n", - mstarddc_doreset ? "" : "NOT "); + free(noreset); + msg_pinfo("Info: Will %sreset the device at the end.\n", mstarddc_doreset ? "" : "NOT "); // Open device if ((mstarddc_fd = open(i2c_device, O_RDWR)) < 0) { switch (errno) { @@ -119,16 +119,17 @@ i2c_device); break; default: - msg_perr("Error opening %s: errno %d.\n", - i2c_device, errno); + msg_perr("Error opening %s: %s.\n", i2c_device, strerror(errno)); } - return -1; + ret = -1; + goto out; } // Set slave address if (ioctl(mstarddc_fd, I2C_SLAVE, mstarddc_addr) < 0) { msg_perr("Error setting slave address 0x%02x: errno %d.\n", mstarddc_addr, errno); - return -1; + ret = -1; + goto out; } // Enable ISP mode uint8_t cmd[5] = { 'M', 'S', 'T', 'A', 'R' }; @@ -141,7 +142,8 @@ msg_perr("Error enabling ISP mode: errno %d & %d.\n" "Please check that device (%s) and address (0x%02x) are correct.\n", enable_err, errno, i2c_device, mstarddc_addr); - return -1; + ret = -1; + goto out; } } // Register shutdown function @@ -149,7 +151,9 @@ // Register programmer register_spi_master(&spi_master_mstarddc); - return 0; +out: + free(i2c_device); + return ret; } /* Returns 0 upon success, a negative number upon errors. */ @@ -160,9 +164,8 @@ unsigned char *readarr) { int ret = 0; - uint8_t *cmd; - - if ((cmd = malloc((writecnt + 1) * sizeof(uint8_t))) < 0) { + uint8_t *cmd = malloc((writecnt + 1) * sizeof(uint8_t)); + if (cmd == NULL) { msg_perr("Error allocating memory: errno %d.\n", errno); ret = -1; }

1 0

Re: [flashrom] Asus P5W-DH board enable problem
by Stefan Tauner 19 Feb '15

19 Feb '15

On Thu, 19 Feb 2015 01:04:34 +0300 "nicolae788 ." <nicolae788(a)gmail.com> wrote: > Thank you very much for your response. I will check the link and hope to > manage and enable it. One last question: if a board recognizes a 512kb chip > is it normal to not recognize the above described ( SST 49LF008A ) 1Mb chip > ??? I have a board with which i could do the flash procedure, it is > fully supported by flashrom, flash chip, chipset, board, but it doesn;t > seem to find the chip i want to flash. The original 512 Kb chip it's listed > when i run flashrom, but when i change chips with the 1Mb one and run again > flashrom the new chip it's not recognized... There are different kinds of protocols involved and it is possible that chips with the same form factor/package are not compatible. http://flashrom.org/Technology#Communication_bus_protocol You should state more facts and/or post logs if you need more help. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom