flashrom August 2014

flashrom@flashrom.org

34 participants
110 discussions

Try add support for SST45LF010
by The Raven 16 Nov '14

16 Nov '14

Hello, i have an SST45LF010 chip here (from a nvidia graphic card) and try to add support for it. The log show me this: Probing for SST SST25LF020A, 256 kB: probe_spi_rems: id1 0x5f, id2 0xdf Probing for SST SST25LF040A, 512 kB: probe_spi_res2: id1 0xff, id2 0xff Probing for SST SST25LF080(A), 1024 kB: probe_spi_res2: id1 0xff, id2 0xff Probing for SST SST25VF512A, 64 kB: probe_spi_rems: id1 0x5f, id2 0xdf Probing for SST SST25VF010, 128 kB: probe_spi_rems: id1 0x5f, id2 0xdf Probing for SST SST25VF020, 256 kB: probe_spi_rems: id1 0x5f, id2 0xdf Probing for SST SST25VF020B, 256 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff Probing for SST SST25VF040, 512 kB: probe_spi_rems: id1 0x5f, id2 0xdf Probing for SST SST25VF040B, 512 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff Probing for SST SST25VF040B.REMS, 512 kB: probe_spi_rems: id1 0x5f, id2 0xdf Probing for SST SST25VF080B, 1024 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff Probing for SST SST25VF016B, 2048 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff Probing for SST SST25VF032B, 4096 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff Probing for SST SST25VF064C, 8192 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff Probing for SST SST25WF512, 64 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff Probing for SST SST25WF010, 128 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff Probing for SST SST25WF020, 256 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff Probing for SST SST25WF040, 512 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff Probing for SST SST25WF080, 1024 kB: RDID byte 1 parity violation. probe_spi_rdid_generic: id1 0x7fff, id2 0xff So it looks that it works similar to the "SST25VF010". But it has (always) an ID of 0x5F! Normally SST chips have 0xBF. In the datasheet i can also see that this chip should have 0xBF. Looks strange to me. Why i get this strange ID? Is this possible? Thx

2 4

[PATCH] Add support for AMD Bolton chipset
by Martin Roth 31 Aug '14

31 Aug '14

Add support for AMD's Bolton chipset. The SPI controller on the bolton chipset uses the same 3-bit speed settings as yangtze, but is otherwise the same as the hudson chips. Note that the Bolton RRG doesn't specify a speed setting for the bit setting of 0b111, so I'm assuming that it's the same setting as yangtze. Signed-off-by: Martin Roth <martin.roth(a)se-eng.com>

3 4

[commit] r1848 - trunk
by repository service 31 Aug '14

31 Aug '14

Author: stefanct Date: Sun Aug 31 02:09:21 2014 New Revision: 1848 URL: http://flashrom.org/trac/flashrom/changeset/1848 Log: Introduce generic shutdown_free() and remove redundant internal_shutdown(). The former will be useful in cases where cleanup equals a simple call to free(). Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Modified: trunk/flash.h trunk/flashrom.c trunk/internal.c Modified: trunk/flash.h ============================================================================== --- trunk/flash.h Sun Aug 31 01:39:51 2014 (r1847) +++ trunk/flash.h Sun Aug 31 02:09:21 2014 (r1848) @@ -54,6 +54,7 @@ #define PRIuCHIPSIZE PRIu32 int register_shutdown(int (*function) (void *data), void *data); +int shutdown_free(void *data); void *programmer_map_flash_region(const char *descr, uintptr_t phys_addr, size_t len); void programmer_unmap_flash_region(void *virt_addr, size_t len); void programmer_delay(unsigned int usecs); Modified: trunk/flashrom.c ============================================================================== --- trunk/flashrom.c Sun Aug 31 01:39:51 2014 (r1847) +++ trunk/flashrom.c Sun Aug 31 02:09:21 2014 (r1848) @@ -373,6 +373,12 @@ static int check_block_eraser(const struct flashctx *flash, int k, int log); +int shutdown_free(void *data) +{ + free(data); + return 0; +} + /* Register a function to be executed on programmer shutdown. * The advantage over atexit() is that you can supply a void pointer which will * be used as parameter to the registered function upon programmer shutdown. Modified: trunk/internal.c ============================================================================== --- trunk/internal.c Sun Aug 31 01:39:51 2014 (r1847) +++ trunk/internal.c Sun Aug 31 02:09:21 2014 (r1848) @@ -158,11 +158,6 @@ enum chipbustype internal_buses_supported = BUS_NONE; -static int internal_shutdown(void *data) -{ - return 0; -} - int internal_init(void) { #if __FLASHROM_LITTLE_ENDIAN__ @@ -237,8 +232,6 @@ if (rget_io_perms()) return 1; - if (register_shutdown(internal_shutdown, NULL)) - return 1; /* Default to Parallel/LPC/FWH flash devices. If a known host controller * is found, the host controller init routine sets the

1 0

Re: [flashrom] [PATCH] Refine physical address mapping of flash chips.
by Stefan Tauner 30 Aug '14

30 Aug '14

On Wed, 20 Aug 2014 01:15:43 +0200 Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> wrote: > + msg_pdbg2("Successfully mapped flash chip \"%s\" at physical address 0x%0*" PRIxPTR ".\n", > + fill_flash->chip->name, PRIxPTR_WIDTH, fill_flash->physical_memory); > + Forgot to remove these lines, please ignore. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 2

[commit] r1847 - trunk
by repository service 30 Aug '14

30 Aug '14

Author: stefanct Date: Sun Aug 31 01:39:51 2014 New Revision: 1847 URL: http://flashrom.org/trac/flashrom/changeset/1847 Log: Refine physical address mapping of flash chips. - Create distinct functions for mapping and unmapping for flash chips. - Map only when needed: map before probing and unmap immediately after it. Map again when a single chip was probed successfully before taking any actual actions and clean up afterwards. - Map special function chip registers centrally together with flash space instead of within (some) probing methods after successful probes. - Save the used base addresses of the mappings in struct flashctx as well. - Do not try to (un)map the zero-sized chip definitions that are merely hacks. This also fixes the printing of wrong warnings for these chip definitions introduced in r1765. Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/82802ab.c trunk/cli_classic.c trunk/flash.h trunk/flashrom.c trunk/jedec.c Modified: trunk/82802ab.c ============================================================================== --- trunk/82802ab.c Wed Aug 20 20:56:35 2014 (r1846) +++ trunk/82802ab.c Sun Aug 31 01:39:51 2014 (r1847) @@ -83,9 +83,6 @@ if (id1 != flash->chip->manufacture_id || id2 != flash->chip->model_id) return 0; - if (flash->chip->feature_bits & FEATURE_REGISTERMAP) - map_flash_registers(flash); - return 1; } Modified: trunk/cli_classic.c ============================================================================== --- trunk/cli_classic.c Wed Aug 20 20:56:35 2014 (r1846) +++ trunk/cli_classic.c Sun Aug 31 01:39:51 2014 (r1847) @@ -481,8 +481,14 @@ ret = 1; goto out_shutdown; } + if (map_flash(&flashes[0]) != 0) { + free(flashes[0].chip); + ret = 1; + goto out_shutdown; + } msg_cinfo("Please note that forced reads most likely contain garbage.\n"); ret = read_flash_to_file(&flashes[0], filename); + unmap_flash(&flashes[0]); free(flashes[0].chip); goto out_shutdown; } @@ -525,6 +531,12 @@ if (write_it && !dont_verify_it) verify_it = 1; + /* Map the selected flash chip again. */ + if (map_flash(fill_flash) != 0) { + ret = 1; + goto out_shutdown; + } + /* FIXME: We should issue an unconditional chip reset here. This can be * done once we have a .reset function in struct flashchip. * Give the chip time to settle. @@ -532,6 +544,7 @@ programmer_delay(100000); ret |= doit(fill_flash, force, filename, read_it, write_it, erase_it, verify_it); + unmap_flash(fill_flash); out_shutdown: programmer_shutdown(); out: Modified: trunk/flash.h ============================================================================== --- trunk/flash.h Wed Aug 20 20:56:35 2014 (r1846) +++ trunk/flash.h Sun Aug 31 01:39:51 2014 (r1847) @@ -48,9 +48,9 @@ /* Types and macros regarding the maximum flash space size supported by generic code. */ typedef uint32_t chipoff_t; /* Able to store any addressable offset within a supported flash memory. */ typedef uint32_t chipsize_t; /* Able to store the number of bytes of any supported flash memory. */ -#define FL_MAX_CHIPADDR_BITS (24) -#define FL_MAX_CHIPADDR ((chipoff_t)(1ULL<<FL_MAX_CHIPADDR_BITS)-1) -#define PRIxCHIPADDR "06"PRIx32 +#define FL_MAX_CHIPOFF_BITS (24) +#define FL_MAX_CHIPOFF ((chipoff_t)(1ULL<<FL_MAX_CHIPOFF_BITS)-1) +#define PRIxCHIPOFF "06"PRIx32 #define PRIuCHIPSIZE PRIu32 int register_shutdown(int (*function) (void *data), void *data); @@ -209,8 +209,14 @@ struct flashctx { struct flashchip *chip; + /* FIXME: The memory mappings should be saved in a more structured way. */ + /* The physical_* fields store the respective addresses in the physical address space of the CPU. */ + uintptr_t physical_memory; + /* The virtual_* fields store where the respective physical address is mapped into flashrom's address + * space. A value equivalent to (chipaddr)ERROR_PTR indicates an invalid mapping (or none at all). */ chipaddr virtual_memory; - /* Some flash devices have an additional register space. */ + /* Some flash devices have an additional register space; semantics are like above. */ + uintptr_t physical_registers; chipaddr virtual_registers; struct registered_master *mst; }; @@ -252,7 +258,8 @@ /* flashrom.c */ extern const char flashrom_version[]; extern const char *chip_to_probe; -void map_flash_registers(struct flashctx *flash); +int map_flash(struct flashctx *flash); +void unmap_flash(struct flashctx *flash); int read_memmapped(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len); int erase_flash(struct flashctx *flash); int probe_flash(struct registered_master *mst, int startchip, struct flashctx *fill_flash, int force); Modified: trunk/flashrom.c ============================================================================== --- trunk/flashrom.c Wed Aug 20 20:56:35 2014 (r1846) +++ trunk/flashrom.c Sun Aug 31 01:39:51 2014 (r1847) @@ -479,6 +479,7 @@ void programmer_unmap_flash_region(void *virt_addr, size_t len) { programmer_table[programmer].unmap_flash_region(virt_addr, len); + msg_gspew("%s: unmapped 0x%0*" PRIxPTR "\n", __func__, PRIxPTR_WIDTH, (uintptr_t)virt_addr); } void chip_writeb(const struct flashctx *flash, uint8_t val, chipaddr addr) @@ -528,14 +529,6 @@ programmer_table[programmer].delay(usecs); } -void map_flash_registers(struct flashctx *flash) -{ - size_t size = flash->chip->total_size * 1024; - /* Flash registers live 4 MByte below the flash. */ - /* FIXME: This is incorrect for nonstandard flashbase. */ - flash->virtual_registers = (chipaddr)programmer_map_flash_region("flash chip registers", (0xFFFFFFFF - 0x400000 - size + 1), size); -} - int read_memmapped(struct flashctx *flash, uint8_t *buf, unsigned int start, int unsigned len) { @@ -1052,12 +1045,64 @@ return limitexceeded; } +void unmap_flash(struct flashctx *flash) +{ + if (flash->virtual_registers != (chipaddr)ERROR_PTR) { + programmer_unmap_flash_region((void *)flash->virtual_registers, flash->chip->total_size * 1024); + flash->physical_registers = 0; + flash->virtual_registers = (chipaddr)ERROR_PTR; + } + + if (flash->virtual_memory != (chipaddr)ERROR_PTR) { + programmer_unmap_flash_region((void *)flash->virtual_memory, flash->chip->total_size * 1024); + flash->physical_memory = 0; + flash->virtual_memory = (chipaddr)ERROR_PTR; + } +} + +int map_flash(struct flashctx *flash) +{ + /* Init pointers to the fail-safe state to distinguish them later from legit values. */ + flash->virtual_memory = (chipaddr)ERROR_PTR; + flash->virtual_registers = (chipaddr)ERROR_PTR; + + /* FIXME: This avoids mapping (and unmapping) of flash chip definitions with size 0. + * These are used for various probing-related hacks that would not map successfully anyway and should be + * removed ASAP. */ + if (flash->chip->total_size == 0) + return 0; + + const chipsize_t size = flash->chip->total_size * 1024; + uintptr_t base = flashbase ? flashbase : (0xffffffff - size + 1); + void *addr = programmer_map_flash_region(flash->chip->name, base, size); + if (addr == ERROR_PTR) { + msg_perr("Could not map flash chip %s at 0x%0*" PRIxPTR ".\n", + flash->chip->name, PRIxPTR_WIDTH, base); + return 1; + } + flash->physical_memory = base; + flash->virtual_memory = (chipaddr)addr; + + /* FIXME: Special function registers normally live 4 MByte below flash space, but it might be somewhere + * completely different on some chips and programmers, or not mappable at all. + * Ignore these problems for now and always report success. */ + if (flash->chip->feature_bits & FEATURE_REGISTERMAP) { + base = 0xffffffff - size - 0x400000 + 1; + addr = programmer_map_flash_region("flash chip registers", base, size); + if (addr == ERROR_PTR) { + msg_pdbg2("Could not map flash chip registers %s at 0x%0*" PRIxPTR ".\n", + flash->chip->name, PRIxPTR_WIDTH, base); + return 0; + } + flash->physical_registers = base; + flash->virtual_registers = (chipaddr)addr; + } + return 0; +} + int probe_flash(struct registered_master *mst, int startchip, struct flashctx *flash, int force) { const struct flashchip *chip; - unsigned long base = 0; - char location[64]; - uint32_t size; enum chipbustype buses_common; char *tmp; @@ -1082,9 +1127,8 @@ memcpy(flash->chip, chip, sizeof(struct flashchip)); flash->mst = mst; - size = flash->chip->total_size * 1024; - base = flashbase ? flashbase : (0xffffffff - size + 1); - flash->virtual_memory = (chipaddr)programmer_map_flash_region("flash chip", base, size); + if (map_flash(flash) != 0) + return -1; /* We handle a forced match like a real match, we just avoid probing. Note that probe_flash() * is only called with force=1 after normal probing failed. @@ -1133,8 +1177,7 @@ break; /* Not the first flash chip detected on this bus, and it's just a generic match. Ignore it. */ notfound: - programmer_unmap_flash_region((void *)flash->virtual_memory, size); - flash->virtual_memory = (chipaddr)NULL; + unmap_flash(flash); free(flash->chip); flash->chip = NULL; } @@ -1142,25 +1185,28 @@ if (!flash->chip) return -1; + + tmp = flashbuses_to_text(flash->chip->bustype); + msg_cinfo("%s %s flash chip \"%s\" (%d kB, %s) ", force ? "Assuming" : "Found", + flash->chip->vendor, flash->chip->name, flash->chip->total_size, tmp); + free(tmp); #if CONFIG_INTERNAL == 1 if (programmer_table[programmer].map_flash_region == physmap) - snprintf(location, sizeof(location), "at physical address 0x%lx", base); + msg_cinfo("mapped at physical address 0x%0*" PRIxPTR ".\n", + PRIxPTR_WIDTH, flash->physical_memory); else #endif - snprintf(location, sizeof(location), "on %s", programmer_table[programmer].name); + msg_cinfo("on %s.\n", programmer_table[programmer].name); - tmp = flashbuses_to_text(flash->chip->bustype); - msg_cinfo("%s %s flash chip \"%s\" (%d kB, %s) %s.\n", force ? "Assuming" : "Found", - flash->chip->vendor, flash->chip->name, flash->chip->total_size, tmp, location); - free(tmp); - - /* Flash registers will not be mapped if the chip was forced. Lock info - * may be stored in registers, so avoid lock info printing. - */ + /* Flash registers may more likely not be mapped if the chip was forced. + * Lock info may be stored in registers, so avoid lock info printing. */ if (!force) if (flash->chip->printlock) flash->chip->printlock(flash); + /* Get out of the way for later runs. */ + unmap_flash(flash); + /* Return position of matching chip. */ return chip - flashchips; } Modified: trunk/jedec.c ============================================================================== --- trunk/jedec.c Wed Aug 20 20:56:35 2014 (r1846) +++ trunk/jedec.c Sun Aug 31 01:39:51 2014 (r1847) @@ -166,9 +166,6 @@ if (man_id != chip->manufacture_id || dev_id != chip->model_id) return 0; - if (chip->feature_bits & FEATURE_REGISTERMAP) - map_flash_registers(flash); - return 1; } @@ -287,9 +284,6 @@ if (largeid1 != chip->manufacture_id || largeid2 != chip->model_id) return 0; - if (chip->feature_bits & FEATURE_REGISTERMAP) - map_flash_registers(flash); - return 1; }

1 0

Re: [flashrom] failed stumpy
by Stefan Tauner 29 Aug '14

29 Aug '14

On Thu, 28 Aug 2014 21:47:32 -0700 Maison Pulaski <maisonpulaski(a)gmail.com> wrote: > Hello John (if this is John?), Hi, no, we are the flashrom mailing list. Flashrom is the tool underneath John's script that does the actual flash handling. John is subscribed to the list though and should answer in more detail soon-ish, I presume. > I got a scary warning error when trying to flash the Stumpy Rom... 25 bytes of the whole image could not be written. It is probably harmless and just because John's image differs in some write-protected regions which are benign, but without knowing exactly where the differences are you can not be sure. If you don't get a reply from John in a timely manner, I would suggest that you write your backup and we investigate it further when your laptop is in a safe state. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] failed stumpy
by John Lewis 29 Aug '14

29 Aug '14

No, this isn't me. Could you please keep to the G+ community and/or website. Flashrom is a utility used as part of the script, not written or maintained by me, so don't direct queries at Flashrom devs. On 29/08/14 05:47, Maison Pulaski wrote: > Hello John (if this is John?), > > I got a scary warning error when trying to flash the Stumpy Rom... > > "About to flash new ROM, repeat 'If this bricks my Chromebook/box, on my > head be it!' observing exact case and punctuation: If this bricks my > Chromebook/box, on my head be it! > > 1+0 records in > 1+0 records out > 4096 bytes (4.1 kB) copied, 0.00286514 s, 1.4 MB/s > flashrom v0.9.4 : cac0a4a : May 09 2014 16:55:24 UTC on Linux 3.4.0 > (x86_64), built with libpci 3.1.10, GCC 4.8.x-google 20131105 > (prerelease), little endian > VERIFY FAILED at 0x00408fbc! Expected=0x66, Read=0xff, failed byte count > from 0x00000000-0x007fffff: 0x19 > Your flash chip is in an unknown state. > Get help on IRC at irc.freenode.net <http://irc.freenode.net> (channel > #flashrom) or > mail flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> with FAILED: > your board name in the subject line! > ------------------------------------------------------------------------------- > DO NOT REBOOT OR POWEROFF! > Erasing and writing flash chip... Verifying flash... FAILED" > > So, I am not exactly sure what to do now? > > Sorry. > > I did send you a little something (92R63514PY632983E). I know that it is > not payment for services rendered and if you can't help me I totally > understand. It is just a little something for the help you have already > given. > > Thanks, > Maison Pulaski > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom >

1 0

failed stumpy
by Maison Pulaski 29 Aug '14

29 Aug '14

Hello John (if this is John?), I got a scary warning error when trying to flash the Stumpy Rom... "About to flash new ROM, repeat 'If this bricks my Chromebook/box, on my head be it!' observing exact case and punctuation: If this bricks my Chromebook/box, on my head be it! 1+0 records in 1+0 records out 4096 bytes (4.1 kB) copied, 0.00286514 s, 1.4 MB/s flashrom v0.9.4 : cac0a4a : May 09 2014 16:55:24 UTC on Linux 3.4.0 (x86_64), built with libpci 3.1.10, GCC 4.8.x-google 20131105 (prerelease), little endian VERIFY FAILED at 0x00408fbc! Expected=0x66, Read=0xff, failed byte count from 0x00000000-0x007fffff: 0x19 Your flash chip is in an unknown state. Get help on IRC at irc.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org with FAILED: your board name in the subject line! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! Erasing and writing flash chip... Verifying flash... FAILED" So, I am not exactly sure what to do now? Sorry. I did send you a little something (92R63514PY632983E). I know that it is not payment for services rendered and if you can't help me I totally understand. It is just a little something for the help you have already given. Thanks, Maison Pulaski

1 0

Re: [flashrom] [RFC] split code into sub-directories
by Carl-Daniel Hailfinger 28 Aug '14

28 Aug '14

Hi Sean, nice to see you're back. Am 28.08.2014 00:57 schrieb Sean Nelson: > Move files into a directory structure, and edit Makefiles to facilitate > future compilation granularity. For Example, compile a focused version of > flashrom for a specific coreboot motherboard. > > subversion operations: > svn mkdir {chips,programmers,libraries} > > svn move 82802ab.c chips/ > svn move at45db.c chips/ > svn move chipdrivers.h chips/ > svn move en29lv640b.c chips/ > svn move flashchips.c chips/ > svn move flashchips.h chips/ > svn move jedec.c chips/ > svn move opaque.c chips/ > svn move sfdp.c chips/ > svn move spi25.c chips/ > svn move spi25_statusreg.c chips/ > svn move spi.c chips/ > svn move spi.h chips/ > svn move sst28sf040.c chips/ > svn move sst49lfxxxc.c chips/ > svn move sst_fwhub.c chips/ > svn move stm50.c chips/ > svn move w29ee011.c chips/ > svn move w39.c chips/ > > svn move flashrom.c libraries/ > svn move helpers.c libraries/ > svn move layout.c libraries/ > svn move programmer.c libraries/ > svn move programmer.h libraries/ > svn move udelay.c libraries/ > > svn move amd_imc.c programmers/ > svn move atahpt.c programmers/ > svn move atavia.c programmers/ > svn move bitbang_spi.c programmers/ > svn move board_enable.c programmers/ > svn move buspirate_spi.c programmers/ > svn move cbtable.c programmers/ > svn move chipset_enable.c programmers/ > svn move coreboot_tables.h programmers/ > svn move dediprog.c programmers/ > svn move dmi.c programmers/ > svn move drkaiser.c programmers/ > svn move dummyflasher.c programmers/ > svn move ft2232_spi.c programmers/ > svn move gfxnvidia.c programmers/ > svn move hwaccess.c programmers/ > svn move hwaccess.h programmers/ > svn move ich_descriptors.c programmers/ > svn move ich_descriptors.h programmers/ > svn move ichspi.c programmers/ > svn move internal.c programmers/ > svn move it8212.c programmers/ > svn move it85spi.c programmers/ > svn move it87spi.c programmers/ > svn move linux_spi.c programmers/ > svn move mcp6x_spi.c programmers/ > svn move nic3com.c programmers/ > svn move nicintel.c programmers/ > svn move nicintel_eeprom.c programmers/ > svn move nicintel_spi.c programmers/ > svn move nicnatsemi.c programmers/ > svn move nicrealtek.c programmers/ > svn move ogp_spi.c programmers/ > svn move pcidev.c programmers/ > svn move physmap.c programmers/ > svn move pony_spi.c programmers/ > svn move processor_enable.c programmers/ > svn move rayer_spi.c programmers/ > svn move satamv.c programmers/ > svn move satasii.c programmers/ > svn move sb600spi.c programmers/ > svn move serial.c programmers/ > svn move serprog.c programmers/ > svn move serprog.h programmers/ > svn move usbblaster_spi.c programmers/ > svn move wbsio_spi.c programmers/ Good idea, I think we had a similar suggestion already in the past, but it went nowhere because the patch queue was too big. I would like to get the probing stuff in first, though. Rebasing that would be too painful. Regards, Carl-Daniel

1 0

[RFC] split code into sub-directories
by Sean Nelson 27 Aug '14

27 Aug '14

Move files into a directory structure, and edit Makefiles to facilitate future compilation granularity. For Example, compile a focused version of flashrom for a specific coreboot motherboard. subversion operations: svn mkdir {chips,programmers,libraries} svn move 82802ab.c chips/ svn move at45db.c chips/ svn move chipdrivers.h chips/ svn move en29lv640b.c chips/ svn move flashchips.c chips/ svn move flashchips.h chips/ svn move jedec.c chips/ svn move opaque.c chips/ svn move sfdp.c chips/ svn move spi25.c chips/ svn move spi25_statusreg.c chips/ svn move spi.c chips/ svn move spi.h chips/ svn move sst28sf040.c chips/ svn move sst49lfxxxc.c chips/ svn move sst_fwhub.c chips/ svn move stm50.c chips/ svn move w29ee011.c chips/ svn move w39.c chips/ svn move flashrom.c libraries/ svn move helpers.c libraries/ svn move layout.c libraries/ svn move programmer.c libraries/ svn move programmer.h libraries/ svn move udelay.c libraries/ svn move amd_imc.c programmers/ svn move atahpt.c programmers/ svn move atavia.c programmers/ svn move bitbang_spi.c programmers/ svn move board_enable.c programmers/ svn move buspirate_spi.c programmers/ svn move cbtable.c programmers/ svn move chipset_enable.c programmers/ svn move coreboot_tables.h programmers/ svn move dediprog.c programmers/ svn move dmi.c programmers/ svn move drkaiser.c programmers/ svn move dummyflasher.c programmers/ svn move ft2232_spi.c programmers/ svn move gfxnvidia.c programmers/ svn move hwaccess.c programmers/ svn move hwaccess.h programmers/ svn move ich_descriptors.c programmers/ svn move ich_descriptors.h programmers/ svn move ichspi.c programmers/ svn move internal.c programmers/ svn move it8212.c programmers/ svn move it85spi.c programmers/ svn move it87spi.c programmers/ svn move linux_spi.c programmers/ svn move mcp6x_spi.c programmers/ svn move nic3com.c programmers/ svn move nicintel.c programmers/ svn move nicintel_eeprom.c programmers/ svn move nicintel_spi.c programmers/ svn move nicnatsemi.c programmers/ svn move nicrealtek.c programmers/ svn move ogp_spi.c programmers/ svn move pcidev.c programmers/ svn move physmap.c programmers/ svn move pony_spi.c programmers/ svn move processor_enable.c programmers/ svn move rayer_spi.c programmers/ svn move satamv.c programmers/ svn move satasii.c programmers/ svn move sb600spi.c programmers/ svn move serial.c programmers/ svn move serprog.c programmers/ svn move serprog.h programmers/ svn move usbblaster_spi.c programmers/ svn move wbsio_spi.c programmers/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom August 2014