flashrom

flashrom@flashrom.org

5 participants
9186 discussions

[PATCH 1/7] layout: change return type and name of find_next_included_romentry
by Stefan Tauner 19 Aug '11

19 Aug '11

- rename from find_next_included_romentry to get_next_included_romentry - return a pointer to a rom_entry instead of just its index Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> --- carl-daniel noted that this makes it impossible to return other failure indications than the NULL pointer. this is correct, but i did not had any problems with it yet. it works very well this way imo. layout.c | 33 +++++++++++++++++---------------- 1 files changed, 17 insertions(+), 16 deletions(-) diff --git a/layout.c b/layout.c index d719a05..247c897 100644 --- a/layout.c +++ b/layout.c @@ -215,26 +215,28 @@ int find_romentry(char *name) return -1; } -int find_next_included_romentry(unsigned int start) +romlayout_t *get_next_included_romentry(unsigned int start) { int i; unsigned int best_start = UINT_MAX; - int best_entry = -1; + romlayout_t *best_entry = NULL; + romlayout_t *cur; /* First come, first serve for overlapping regions. */ for (i = 0; i < romimages; i++) { - if (!rom_entries[i].included) + cur = &rom_entries[i]; + if (!cur->included) continue; /* Already past the current entry? */ - if (start > rom_entries[i].end) + if (start > cur->end) continue; /* Inside the current entry? */ - if (start >= rom_entries[i].start) - return i; + if (start >= cur->start) + return cur; /* Entry begins after start. */ - if (best_start > rom_entries[i].start) { - best_start = rom_entries[i].start; - best_entry = i; + if (best_start > cur->start) { + best_start = cur->start; + best_entry = cur; } } return best_entry; @@ -243,7 +245,7 @@ int find_next_included_romentry(unsigned int start) int handle_romentries(struct flashchip *flash, uint8_t *oldcontents, uint8_t *newcontents) { unsigned int start = 0; - int entry; + romlayout_t *entry; unsigned int size = flash->total_size * 1024; /* If no layout file was specified or the layout file was empty, assume @@ -255,22 +257,21 @@ int handle_romentries(struct flashchip *flash, uint8_t *oldcontents, uint8_t *ne * The union of all included romentries is used from the new image. */ while (start < size) { - entry = find_next_included_romentry(start); + entry = get_next_included_romentry(start); /* No more romentries for remaining region? */ - if (entry < 0) { + if (entry == NULL) { memcpy(newcontents + start, oldcontents + start, size - start); break; } - if (rom_entries[entry].start > start) + if (entry->start > start) memcpy(newcontents + start, oldcontents + start, - rom_entries[entry].start - start); + entry->start - start); /* Skip to location after current romentry. */ - start = rom_entries[entry].end + 1; + start = entry->end + 1; /* Catch overflow. */ if (!start) break; } - return 0; } -- 1.7.1

1 0

[PATCH 0/7] every layout handling feature you ever wanted to see but never cared to implement
by Stefan Tauner 19 Aug '11

19 Aug '11

well the subject is a bit exaggerated and kinky, but i think layouts (not the write/read protection thingy carl-daniel wrote about lately, but the -l option) could be much more useful. especially for systems that are quite locked down (ICH/PCH...). with this patch set it is possible to - use -i and -l parameters in any order - specify a file for each image (so there is no need to create a full image beforehand) - use layout files for reading - use layout files for verifying some may need some refinements, and man page entries of course, but i wanted to post this now. first for thomas from GE because he asked for it and secondly to discuss if it is the right way to do this at all :) things to improve (either in the future or in a refined form of this patches): - reduce the footprint of the romlayout_t struct by not holding the whole strings but only references to strduped strings. - make the file parameter for -w, -r, -v optional if there are -i file names specified. - see 4/7 comments. Stefan Tauner (7): layout: change return type and name of find_next_included_romentry Add deferred -i processing layout: Add -i <image>[:<file>] support Make read before write configurable (infrastructure part) Use layout for read operations too Use layout for verify operations too (not for merge) Fix the "Use layout for verify operations too" patch in a hacky way cli_classic.c | 10 +-- flash.h | 13 +++- flashrom.c | 149 ++++++++++++++++++++++++++++++++------------ layout.c | 193 +++++++++++++++++++++++++++++++++++++++++++++------------ 4 files changed, 279 insertions(+), 86 deletions(-)

1 0

Asus Crosshair IV Extreme: flashrom -V
by Christophe Poncy 19 Aug '11

19 Aug '11

Hi, I would love to replace the bios for my mother board but I didn't find any coreboot suitable for the Asus Crosshair IV Extreme. I just wanted to let you know that I am available to test any builds in development. # Products info: AMD 890FX/SB850 Crosshair IV Extreme (ASUS mobo) http://www.asus.com/Motherboards/AMD_AM3/Crosshair_IV_Extreme/ http://www.amd.com/us/products/desktop/chipsets/8-series-integrated/Pages/a… # ./flashrom -r -L flashrom v0.9.4-r1395 on Linux 2.6.32-5-amd64 (x86_64), built with libpci 3.1.7, GCC 4.4.5, little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found chipset "AMD SB700/SB710/SB750/SB850". Enabling flash write... OK. This chipset supports the following protocols: LPC, FWH, SPI. Found Winbond flash chip "W25Q16" (2048 kB, SPI) at physical address 0xffe00000. Reading flash... done. # ./flashrom -V (results are attached) Best regards, -- Support free software! Join FSF: https://my.fsf.org/associate/support_freedom?referrer=4574

3 7

Re: [flashrom] report for Intel QM67 | Winbond W25Q64 ([PATCH] (not for merge) ichspi: print BFPR (BIOS Flash Primary Region Register))
by Stefan Tauner 19 Aug '11

19 Aug '11

On Fri, 19 Aug 2011 08:37:48 +0200 "Frei, Thomas (GE Germany)" <Thomas.Frei(a)ge.com> wrote: > Hi, > > I patched my flashrom an here is the output of the new code: > > ---snip--- > 0x00: 0x03ff0200 (BFPR) > 0x00200000-0x003fffff > ---snip--- > > Is this, what you expected? yes, it is equal to the bios region of yours: 0x58: 0x03ff0200 (FREG1: BIOS) 0x00200000-0x003fffff is read-write > > If I want to hack my flashrom: > - will it be possible to read the flash, or only to write it? for writing there is no need to hack anything. you can use the layout option for this already (please read the man page, really ;) if you can wait till tomorrow, you wont have to hack anything, because i have a patch already. if it is important please mail me directly and i can send it to you sooner. it needs a bit of work still before i can publish it. > - where will I have to change and what exactly, to have the quick, dirty and ugly hack working? > (I tried to search for "limit" and changed it to 0x3fffff and 0x7fffff - but nothing changed in behavior) there are several options. the easiest hack is probably to change the total_size field of the flash chip in question in flashchips.c around line 7978 to 4096. you need then to change the eraseblocks below that accordingly (else flashrom will detect the imbalance at startup and bail out). the first number is the block size and should stay the same for the first 3 erasers. the second one is the count of blocks and should be halved for those erasers. the last 2 are full chip erasers where you need to cut the size in half instead of the count. you can probably comment all erasers but the first away. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Fwd: output of flashrom -V
by Michael Pihlblad 19 Aug '11

19 Aug '11

---------- Forwarded message ---------- From: "Michael Pihlblad" <michael.pihlblad(a)gmail.com> Date: Aug 18, 2011 10:19 PM Subject: output of flashrom -V To: <flashrom(a)flashrom.org> Attaching output of flashrom -V regards Michael -- Michael Pihlblad Tel: 073-3561840 e-post: michael.pihlblad(a)gmail.com

1 0

Re: [flashrom] report for Intel QM67 | Winbond W25Q64 ([PATCH] (not for merge) ichspi: print BFPR (BIOS Flash Primary Region Register))
by Stefan Tauner 19 Aug '11

19 Aug '11

On Tue, 16 Aug 2011 15:06:32 +0200 "Frei, Thomas (GE Germany)" <Thomas.Frei(a)ge.com> wrote: hello thomas and thanks for your report! sorry for the lengthy mail... especially because it does not contain a real solution yet, but maybe there will be one when we are done with this thread :) > - Intel QM67 is supported but untested. the basic SPI interface of the 6 series intel chipsets is not different from the earlier series. they have changed a few things behind the curtain though, which we don't understand fully yet. that could be the cause here. > - Mainboard flash write protection is not existant i beg to differ. there is a chipset protection in place, but we don't know how it works exactly. :) > […] > > First I tried to read the flashcontent -> ERROR!!! > > I didn't try to write jet - and I will not until the read is solved. good idea, because it most certainly will fail. > Please help me - I will provide you all information you will need. that would be great, but i fear you just don't have the information we need, or if you do you would be violating an NDA. :) > flashrom v0.9.4-r1395 on Linux 2.6.34-TSW (i686), built with libpci 3.1.7, GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292], little endian > flashrom is free software, get the source code at http://www.flashrom.org > > Calibrating delay loop... OS timer resolution is 1 usecs, 1496M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 1001 us, 10000 myus = 10005 us, 4 myus = 4 us, OK. > Initializing internal programmer > No coreboot table found. > DMI string system-manufacturer: "" > DMI string system-product-name: "" > DMI string system-version: "" > DMI string baseboard-manufacturer: "" > DMI string baseboard-product-name: "" > DMI string baseboard-version: "" > DMI string chassis-type: "" > DMI chassis-type is not specific enough. > Found chipset "Intel QM67" with PCI ID 8086:1c4f. > This chipset is marked as untested. If you are using an up-to-date version > of flashrom please email a report to flashrom(a)flashrom.org including a > verbose (-V) log. Thank you! i guess you are working on a prototype for GE? in general we try to detect laptops because we don't support them very well yet. please see http://flashrom.org/Laptops for details why we care to detect them. your DMI table seems to not indicate explicitly enough if it is a laptop or not. that is not necessarily a problem in general, i just wanted to mention it in case you are involved in the firmware design. in case you know it, could you please tell us a bit about the hardware design regarding the chipset<->flash connection? main question: is the flash chip directly connected to the qm67? are there any (external) ECs involved? > Enabling flash write... > […] > BIOS Lock Enable: disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x8 > > Root Complex Register Block address = 0xfed1c000 > GCS = 0xc21: BIOS Interface Lock-Down: enabled, BOOT BIOS Straps: 0x3 (LPC) that's actually a bug. intel has changed the meaning of the bits in the GCS *again*. i'll look into it. afaics it is cosmetic only on all chipsets except ICH7, so it is not a problem for you thomas. > Top Swap : not enabled > SPIBAR = 0xfed1c000 + 0x3800 > 0x04: 0xe008 (HSFS) > HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 > WARNING: SPI Configuration Lockdown activated. this is the first sign of the real problem. FDV=1 means the descriptor in the flash is valid and FLOCKDN=1 means that we are restricted in changing most of the relevant SPI settings. this is (officially) required since at least ibex peak (5 series). alone, it is not a problem. FDOPSS=1 is an override bit (Flash Descriptor Override Pin-Strap Status), that is set by a hardware strap. is this accessible to you by a switch of some sort (e.g. jumper)? > 0x06: 0x0f00 (HSFC) > HSFC: FGO=0, FCYCLE=0, FDBC=15, SME=0 > 0x08: 0x00400000 (FADDR) > 0x50: 0x0000ffff (FRAP) > BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff 0xffff comes from the FDOPSS=1 and (should) indicate that we are allowed to access all regions of the flash (read and write). > 0x54: 0x00000000 (FREG0: Flash Descriptor) > 0x00000000-0x00000fff is read-write > 0x58: 0x03ff0200 (FREG1: BIOS) > 0x00200000-0x003fffff is read-write > 0x5C: 0x01ff0001 (FREG2: Management Engine) > 0x00001000-0x001fffff is read-write > 0x60: 0x00000fff (FREG3: Gigabit Ethernet) > Gigabit Ethernet region is unused. > 0x64: 0x00000fff (FREG4: Platform Data) > Platform Data region is unused. the following registers indicate no protected address regions either. > 0x74: 0x00000000 (PR0) > 0x78: 0x00000000 (PR1) > 0x7C: 0x00000000 (PR2) > 0x80: 0x00000000 (PR3) > 0x84: 0x00000000 (PR4) > 0x90: 0x84 (SSFS) > SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0 > 0x91: 0xf80000 (SSFC) > SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=0 > 0x94: 0x0006 (PREOP) > 0x96: 0x043b (OPTYPE) > 0x98: 0x05200302 (OPMENU) > 0x9C: 0x0000019f (OPMENU+4) > 0xA0: 0x00000000 (BBAR) > 0xD0: 0x00000000 (FPB) > Reading OPCODES... done > preop0=0x06, preop1=0x00 > op[0]=0x02, 3, 0 > op[1]=0x03, 2, 0 > op[2]=0x20, 3, 0 > op[3]=0x05, 0, 0 > op[4]=0x9f, 0, 0 > op[5]=0x01, 1, 0 > op[6]=0x00, 0, 0 > op[7]=0x00, 0, 0 > > SPI Read Configuration: prefetching enabled, caching enabled, OK. > This chipset supports the following protocols: FWH, SPI. > […] > Probing for Winbond W25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017 > Chip status register is 00 > […] > Reading flash... SSFS: SCIP=0, FDONE=1, FCERR=1, AEL=0 > SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=63, SME=0, SCF=0 > Running OPCODE 0x03 failed at address 0x400000 (payload length was 64). > FAILED. now the interesting part. let's repeat the output of the FREGs ordered by address range: > 0x54: 0x00000000 (FREG0: Flash Descriptor) > 0x00000000-0x00000fff is read-write > 0x5C: 0x01ff0001 (FREG2: Management Engine) > 0x00001000-0x001fffff is read-write > 0x58: 0x03ff0200 (FREG1: BIOS) > 0x00200000-0x003fffff is read-write transaction err.@400000 so the first transaction after the bios region fails. not that this is also the first address that is not described by any FREG. i can't remember right now if this was ever a problem. my suspicion is that the chipset prohibits any access to addresses that are not mentioned/described by the FREGs. i have "only" two (retail) boards with intel chipsets for testing. both have the whole address range covered by the FREGs (but have other problems.. namely the known write protection by FRAP/PR*). i will need to look into this further (searching for other reports). how big is the image you want to write? (it is obviously 8MB because else flashrom would not continue, but did you modify it and was it 4MB before?) are you able to write the flash with intel's tool (iirc it is called FIT) under windows/dos? do you have access to the firmware modules that are combined to the full image and can you modify the descriptor part? if so it would be interesting to see what happens when you increase the FREG1.limit bits from 0x003fffff to 0x007fffff so that the bios region covers the second half of the flash too (this can be done by modifying the descriptor afaik). if i am right this would allow flashrom to access the whole flash. another thing you could test are my hardware sequencing patches posted to this list and also accessible via http://patchwork.coreboot.org/bundle/stefanct/hwseq/). but i doubt that hwseq will behave different from swseq in this case. OTOH it would be nice to confirm this. if it is not too inconvenient i would like to see the verbose output of a flashrom version modified by the attached patch to output BFPR. this should be equal to FREG1 and therefor we do not print it normally. it will certainly not change the general behavior in your case, i just want to be sure we know every possible detail. a workaround for your problem would be to change flashrom in a way that it does not try to access addresses > 0x003fffff. currently this is only possible while writing (see layout option in the manpage). so you would probably want to hardcode the limit in flashrom to solve the problem quickly but ugly. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 3

MSI H55-GD65 (MS-7637) (H55, locked ME region, FLOCKDN=0(!))
by Stefan Tauner 19 Aug '11

19 Aug '11

hi there i have read the log on IRC. thanks for your report! ICH/PCH boards are problematic due to their locks which can't be unlocked by flashrom (yet). please see my mails and blog posts of the last months for details. that said, your board is a bit special because although it has a locked (and a r/o) region, these locks are not locked (as indicated by FLOCKDN=0. if that sounds a bit complicated then you got it ;). this means that we could (try to) just set the correct access rights (something which is usually impossible due to the lock down). OTOH we had also reports in the past where the access rights SEEMED to be correct, but accessing the flash failed nonetheless. this is still a bit of too much guesswork... blame intel, sorry :) i will put a "set PR* to read/write if FLOCKDN==0" on my todo list and will inform you about its progress. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 1

Intel 82557/8/9/0/1 Ethernet Pro 100 - TESTED
by Антон Кочков 18 Aug '11

18 Aug '11

Intel 82557/8/9/0/1 Ethernet Pro 100 flashrom v0.9.4-r1395 on MS-DOS 8 (i786), built with libpci 3.1.5, GCC 4.3.2, little endian PROBE TESTED http://paste.flashrom.org/view.php?id=761 Best regards, Anton Kochkov.

1 0

flashrom accepts its command line parameters as a file name to read to
by Idwer Vollering 18 Aug '11

18 Aug '11

2011/8/18 Christophe Poncy <cp(a)canaxis.org>: > Hi, > ... > # ./flashrom -r -L This shouldn't be allowed. What about disallowing the creation of files that have a name listed in cli_classic.c's optstring[] and/or long_options[] ? What's funny (or not..) is that running "flashrom -r -r" is allowed as well.

1 0

Re: [flashrom] [PATCH 1/3] layout: change return type and name of find_next_included_romentry
by Tadas Slotkus 18 Aug '11

18 Aug '11

On Pr, 2011-08-15 at 06:43 +0200, Stefan Tauner wrote: > - rename from find_next_included_romentry to get_next_included_romentry > - return a pointer to a rom_entry instead of just its index > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> Acked-by: Tadas Slotkus <devtadas(a)gmail.com>

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom