flashrom July 2011

flashrom@flashrom.org

50 participants
275 discussions

[PATCH] Warn about unhandled one-time programmable memory
by Daniel Lenski 13 Aug '11

13 Aug '11

Added feature bit FEATURE_UNHANDLED_OTP, and a warning for chips like AMIC A25L032 and A25LQ032 which contain small regions of one-time programmable memory that flashrom can neither read, nor write, nor erase. Signed-off-by: Daniel Lenski <dlenski(a)gmail.com> --- flash.h | 1 + flashchips.c | 2 ++ flashrom.c | 8 ++++++++ 3 files changed, 11 insertions(+), 0 deletions(-) diff --git a/flash.h b/flash.h index 6f0d7c0..6db4c48 100644 --- a/flash.h +++ b/flash.h @@ -85,6 +85,7 @@ enum chipbustype { #define FEATURE_ADDR_SHIFTED (1 << 5) #define FEATURE_WRSR_EWSR (1 << 6) #define FEATURE_WRSR_WREN (1 << 7) +#define FEATURE_UNHANDLED_OTP (1 << 8) #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | FEATURE_WRSR_WREN) struct flashchip { diff --git a/flashchips.c b/flashchips.c index efd7599..07b9635 100644 --- a/flashchips.c +++ b/flashchips.c @@ -817,6 +817,7 @@ struct flashchip flashchips[] = { .model_id = AMIC_A25L032, .total_size = 4096, .page_size = 256, + .feature_bits = FEATURE_UNHANDLED_OTP, .tested = TEST_UNTESTED, .probe = probe_spi_rdid, .probe_timing = TIMING_ZERO, @@ -852,6 +853,7 @@ struct flashchip flashchips[] = { .model_id = AMIC_A25LQ032, .total_size = 4096, .page_size = 256, + .feature_bits = FEATURE_UNHANDLED_OTP, .tested = TEST_UNTESTED, .probe = probe_spi_rdid, .probe_timing = TIMING_ZERO, diff --git a/flashrom.c b/flashrom.c index 2690151..a7471a6 100644 --- a/flashrom.c +++ b/flashrom.c @@ -1434,6 +1434,14 @@ void check_chip_supported(struct flashchip *flash) "Thanks for your help!\n" "===\n"); } + if (flash->feature_bits & FEATURE_UNHANDLED_OTP) { + msg_cinfo("===\n" + "This flash part contains a region of one-time programmable memory\n" + "which flashrom cannot read, and may never be able to write or\n" + "erase. flashrom may not be able to completely backup and rewrite\n" + "the contents of this chip.\n" + "===\n"); + } } int main(int argc, char *argv[]) -- 1.7.0.4

2 1

Message levels and content
by Carl-Daniel Hailfinger 12 Aug '11

12 Aug '11

Hi, it has become quite obvious that there are different views about how much output flashrom should provide at default verbosity. I'd like to keep line count down, but at the same time I acknowledge that long-running operations need some user feedback. Those goals are not easily reconcilable and there will be some friction. Others would like to upgrade the message levels of quite a few messages and introduce a separate quiet mode which is less verbose than default mode. Given that this dicussion revolves around the UI and different people expect different things, I don't want to "solve" this by decree. Instead, I hope for consensus. We definitely need to reach a decision, but maybe we can do this with the help of use cases and by examining typical flashrom output. I'm sure there is some low-hanging fruit where the message content/level can be adjusted and where people agree on the changes. Regards, Carl-Daniel -- http://www.hailfinger.org/

3 8

Problems with flashrom
by Benjamin Z. Gregorian 11 Aug '11

11 Aug '11

Hi Guys I run into trouble using flashrom. first I downloaded the ROM to flash then I downloaded flashrom and run the following command ---------- sudo flashrom ---------- Result: flashrom v0.9.1-r946 No coreboot table found. Found chipset "Intel ICH7/ICH7R", enabling flash write... OK. This chipset supports the following protocols: FWH. Calibrating delay loop... OK. Found chip "SST SST49LF004A/B" (512 KB, FWH) at physical address 0xfff80000. No operations were specified. --------- I assumed that flashrom can burn my BIOS (since there was no warning given) Then I tried --------- sudo flashrom -wv Desktop/Downloads/P5LD2-2002.ROM --------- Result was that two opperations are not permittet or so After studying the man page I ran the following command --------- sudo flashrom -w Desktop/Downloads/P5LD2-2002.ROM --------- and got panic!!!!!!! -------- flashrom v0.9.1-r946 No coreboot table found. Found chipset "Intel ICH7/ICH7R", enabling flash write... OK. This chipset supports the following protocols: FWH. Calibrating delay loop... OK. Found chip "SST SST49LF004A/B" (512 KB, FWH) at physical address 0xfff80000. Flash image seems to be a legacy BIOS. Disabling checks. Writing flash chip... Erasing flash chip... ERASE FAILED at 0x000002c8! Expected=0xff, Read=0x4c, failed byte count from 0x00000000-0x00000fff: 0xd12 ERASE FAILED! ERASE FAILED at 0x000002c8! Expected=0xff, Read=0x4c, failed byte count from 0x00000000-0x0000ffff: 0xfc2b ERASE FAILED! FAILED! ERASE FAILED! FAILED! Your flash chip is in an unknown state. Get help on IRC at irc.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! ----------------------------------- PLEASE ADVICE what to do next. LOOKING EAGERLY FORWARD to YOUR REPLY Regards Benjamin -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

5 6

[PATCH] add support for AT49F040
by David Borg 10 Aug '11

10 Aug '11

Hi, I was adding support for the AT49F040 parallel flash chip, but have some questions. This chip has a boot block which once locked cannot be erased / rewritten. Should I add erase functions for both cases? Currently the erase function handles unlocked chips only. In addition, the datasheet specifies no command timings, is the timing something I can infer from the read / program cycle characteristics tables? Regards, David Signed-off-by: David Borg <borg.db(a)gmail.com> datasheet: http://pdf1.alldatasheet.com/datasheet-pdf/view/56184/ATMEL/AT49F040.html Index: flashchips.c =================================================================== --- flashchips.c (revision 1145) +++ flashchips.c (working copy) @@ -1985,6 +1985,29 @@ }, { + .vendor = "Atmel", + .name = "AT49F040", + .bustype = CHIP_BUSTYPE_PARALLEL, + .manufacture_id = ATMEL_ID, + .model_id = AT_49F040, + .total_size = 512, + .page_size = 512, + .feature_bits = FEATURE_EITHER_RESET | FEATURE_ADDR_FULL, + .tested = TEST_UNTESTED, + .probe = probe_jedec, + .probe_timing = TIMING_ZERO, /* Datasheet has no timing info specified */ + .block_erasers = + { + { + .eraseblocks = { {512 * 1024, 1} }, + .block_erase = erase_chip_block_jedec, + } + }, + .write = write_jedec_1, + .read = read_memmapped, + }, + + { .vendor = "EMST", .name = "F49B002UA", .bustype = CHIP_BUSTYPE_PARALLEL, Index: flashchips.h =================================================================== --- flashchips.h (revision 1145) +++ flashchips.h (working copy) @@ -174,6 +174,7 @@ #define AT_49F020 0x0B #define AT_49F002N 0x07 /* for AT49F002(N) */ #define AT_49F002NT 0x08 /* for AT49F002(N)T */ +#define AT_49F040 0x13 #define CATALYST_ID 0x31 /* Catalyst */

3 2

Re: [flashrom] [PATCH 8/8] Added (N) to the name of MX29F002B/T devices.
by Idwer Vollering 07 Aug '11

07 Aug '11

2011/3/15 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>: > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Idwer Vollering <vidwer(a)gmail.com> But *only* if the probe/read/erase/write status is not affected. > --- > flashchips.c | 4 ++-- > flashchips.h | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/flashchips.c b/flashchips.c > index 7cb7d39..97aafef 100644 > --- a/flashchips.c > +++ b/flashchips.c > @@ -4209,7 +4209,7 @@ struct flashchip flashchips[] = { > > { > .vendor = "Macronix", > - .name = "MX29F002B", > + .name = "MX29F002(N)B", > .bustype = CHIP_BUSTYPE_PARALLEL, > .manufacture_id = MACRONIX_ID, > .model_id = MACRONIX_MX29F002B, > @@ -4240,7 +4240,7 @@ struct flashchip flashchips[] = { > > { > .vendor = "Macronix", > - .name = "MX29F002T", > + .name = "MX29F002(N)T", > .bustype = CHIP_BUSTYPE_PARALLEL, > .manufacture_id = MACRONIX_ID, > .model_id = MACRONIX_MX29F002T, > diff --git a/flashchips.h b/flashchips.h > index 9b08d25..9782188 100644 > --- a/flashchips.h > +++ b/flashchips.h > @@ -361,8 +361,8 @@ > #define MACRONIX_MX25L3235D 0x5E16 /* MX25L3225D/MX25L3235D/MX25L3237D */ > #define MACRONIX_MX29F001B 0x19 > #define MACRONIX_MX29F001T 0x18 > -#define MACRONIX_MX29F002B 0x34 /* Same as MX29F002NB */ > -#define MACRONIX_MX29F002T 0xB0 /* Same as MX29F002NT */ > +#define MACRONIX_MX29F002B 0x34 /* Same as MX29F002NB; N has reset pin n/c. */ > +#define MACRONIX_MX29F002T 0xB0 /* Same as MX29F002NT; N has reset pin n/c. */ > #define MACRONIX_MX29F004B 0x46 > #define MACRONIX_MX29F004T 0x45 > #define MACRONIX_MX29F022T 0x36 /* Same as MX29F022NT */ > -- > 1.7.1 > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom >

2 2

flashrom support for EP-9NPA7I
by Stefan Tauner 07 Aug '11

07 Aug '11

hello clr! you have missed carl-daniel or vice-versa one time and you never came back after that. i have dug up some info about the predecessor of your board i.e. 8NPA7I. the board enable that was executed on your machine by mistake is not complete (not even for the 8NPA7I) so it is expected to not work for you. i have not reverse engineered your bios (update tool), so i am not sure at all that the attached patch would help and not reboot/ruin/ignite your machine. but if you are brave you can try it. PS: this patch is not for merge, because we have no idea what 0x92 really does imho. but we could incorporate this into a board enable function, if it really works or do you (fellow flashrom dev) think it is ok to just merge it as is? PPS: this is just a port of http://patchwork.coreboot.org/patch/2125/ -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

3 6

ck804 enable improvement
by Jonathan A. Kollasch 06 Aug '11

06 Aug '11

Hi, Attached is a proposed patch for improving the ck804 chipset enable. Comments? Jonathan Kollasch

3 3

Re: [flashrom] FAILED update new bios but OK to flash OLD bios - P5N-E SLI
by Stefan Tauner 06 Aug '11

06 Aug '11

On Fri, 22 Jul 2011 10:38:45 +0200 Joël Obrecht <joel.obrecht(a)gmail.com> wrote: > Hi Joshua, > I'm sorry I looked a bit around but I guess I need some more explanations > for using / installing that patch. May I have to replace the data in source > files ? Where ? > Anyway, I tried again with last svn, failed again, I joined the verbose > output. > Joël hello joël! i am not entirely sure how your building process works, but you basically need to apply joshua's patch on top of a current source snapshot before compiling it. lets say you have the source in your current working directory. you can then fetch and apply the patch by: wget http://patchwork.coreboot.org/patch/2125/raw/ -O p5ne.patch patch < p5ne.patch after that you have to recompile it. it should print something like "Disabling flash write protection for P5N-E" when run then. it is possible that it does not work yet. please dont reboot if flashrom tells you that and report back (you can get even faster reponses on IRC, if that's an issue btw). -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 1

[PATCH] Confirm EN29LV800 bus, timing, and page size
by TJ 02 Aug '11

02 Aug '11

Uncertain values now confirmed. If you're happy with the new EN29LV800 code I'll submit a combined patch with a Signed-off-by tag. --- flashchips.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/flashchips.c b/flashchips.c index b5be180..10b8dea 100644 --- a/flashchips.c +++ b/flashchips.c @@ -2166,15 +2166,15 @@ struct flashchip flashchips[] = { { .vendor = "EON", .name = "EN29LV800(B)(C)B", - .bustype = CHIP_BUSTYPE_UNKNOWN, + .bustype = CHIP_BUSTYPE_PARALLEL, .manufacture_id = EON_ID, .model_id = EN_29LV800B, .total_size = 1024, - .page_size = 1024, // TODO: check this + .page_size = 1024, .feature_bits = FEATURE_ADDR_AAA | FEATURE_EITHER_RESET, .tested = TEST_UNTESTED, .probe = probe_jedec, - .probe_timing = TIMING_ZERO, /* TODO: check Datasheet has no timing info specified */ + .probe_timing = TIMING_ZERO, .erase = NULL, .block_erasers = { @@ -2198,15 +2198,15 @@ struct flashchip flashchips[] = { { .vendor = "EON", .name = "EN29LV800(B)(C)T", - .bustype = CHIP_BUSTYPE_UNKNOWN, + .bustype = CHIP_BUSTYPE_PARALLEL, .manufacture_id = EON_ID, .model_id = EN_29LV800T, .total_size = 1024, - .page_size = 1024, // TODO: check this + .page_size = 1024, .feature_bits = FEATURE_ADDR_AAA | FEATURE_EITHER_RESET, .tested = TEST_UNTESTED, .probe = probe_jedec, - .probe_timing = TIMING_ZERO, /* TODO: check Datasheet has no timing info specified */ + .probe_timing = TIMING_ZERO, .erase = NULL, .block_erasers = { -- 1.6.3.3

4 5

AAI on SST25VF016B
by Noé Rubinstein 01 Aug '11

01 Aug '11

Hi, I was looking for some way to decrease the flashing time with Flashrom for a 2MB SST SST25VF016B chip with a Dediprog SF100 programmer. After taking a look at the datasheet, stefanct suggested to try to change the write function for SST25VF016B to spi_aai_write, instead of spi_chip_write_1. (I had tried changing it to spi_chip_write_256 some time ago. Unsurprisingly, the results were not so good) I did some benchmark by writing random data on a chip already filled with random data. I attached the results. I've run the benchmark two times and got similar results on the two runs. In short: - with spi_aai_write, writing takes 56 minutes and seems to work reliably - with spi_chip_write_1, writing takes 143 minutes I also ran the test with -VV but the log is so big I can't possibly send it to the mailing list. Here it is: http://neetwork.net/up/misc/bench_vv I also attached the patch I applied to Flashrom's trunk. -- Noé Rubinstein Proformatique (groupe Avencall) - XiVO IPBX OpenHardware 10 bis, rue Lucien VOILIN - 92800 Puteaux

4 5

← Newer
1
2
3
4
5
6
7
8
9
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom July 2011