flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Broadwell-DE SoC
by Wen Wang 02 Aug '16

02 Aug '16

Hello, Has anybody tried flashrom on Broadwell-DE SoC? Intel has upstreamed coreboot support. But we are having trouble with flashrom. The ME region does not seem to be accessible. We cannot read the entire flash (fails when reading ME) even though we enabled all reads in Master Access Section in FITC. We also tried to set FDO, it did not help either. We would like to at least be able to update the BIOS region. However, flashrom performs a full read prior to doing partial write. Below is the log using flashrom trunk. Thanks! Wen ++++++++++++ flashrom log ++++++++++++++++ [root@localhost flashrom_trunk]# ./flashrom -p internal -r backup.bin -V flashrom v0.9.9-r1954 on Linux 4.2.8-200.fc22.x86_64 (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.3.0, GCC 5.3.1 20151207 (Red Hat 5.3.1-2), little endian Command line (5 args): ./flashrom -p internal -r backup.bin -V Calibrating delay loop... OS timer resolution is 1 usecs, 2474M loops per second, 10 myus = 10 us, 100 myus = 102 us, 1000 myus = 1011 us, 10000 myus = 10133 us, 4 myus = 4 us, OK. Initializing internal programmer Found candidate at: 00000500-00000510 Found coreboot table at 0x00000500. Error accessing high tables, 0x100000 bytes at 0x000000007efcf000 /dev/mem mmap failed: Resource temporarily unavailable Failed getting access to coreboot high tables. Using Internal DMI decoder. DMI string chassis-type: "Desktop" DMI string system-manufacturer: "ADI Engineering" DMI string system-product-name: "BCC" DMI string system-version: "1.0" DMI string baseboard-manufacturer: "ADI Engineering" DMI string baseboard-product-name: "BCC" DMI string baseboard-version: "1.0" Found chipset "Intel C224" with PCI ID 8086:8c54. This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap: enabled (A16(+) inverted) 0xfff80000/0xffb80000 FWH IDSEL: 0x0 0xfff00000/0xffb00000 FWH IDSEL: 0x0 0xffe80000/0xffa80000 FWH IDSEL: 0x1 0xffe00000/0xffa00000 FWH IDSEL: 0x1 0xffd80000/0xff980000 FWH IDSEL: 0x2 0xffd00000/0xff900000 FWH IDSEL: 0x2 0xffc80000/0xff880000 FWH IDSEL: 0x3 0xffc00000/0xff800000 FWH IDSEL: 0x3 0xff700000/0xff300000 FWH IDSEL: 0x4 0xff600000/0xff200000 FWH IDSEL: 0x5 0xff500000/0xff100000 FWH IDSEL: 0x6 0xff400000/0xff000000 FWH IDSEL: 0x7 0xfff80000/0xffb80000 FWH decode enabled 0xfff00000/0xffb00000 FWH decode enabled 0xffe80000/0xffa80000 FWH decode enabled 0xffe00000/0xffa00000 FWH decode enabled 0xffd80000/0xff980000 FWH decode enabled 0xffd00000/0xff900000 FWH decode enabled 0xffc80000/0xff880000 FWH decode enabled 0xffc00000/0xff800000 FWH decode enabled 0xff700000/0xff300000 FWH decode enabled 0xff600000/0xff200000 FWH decode enabled 0xff500000/0xff100000 FWH decode enabled 0xff400000/0xff000000 FWH decode enabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching enabled, caching enabled, BIOS_CNTL = 0x09: BIOS Lock Enable: disabled, BIOS Write Enable: enabled SPIBAR = 0x00007f7924698000 + 0x3800 0x04: 0xd009 (HSFS) HSFS: FDONE=1, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=0, FDV=1, FLOCKDN=1 Warning: SPI Configuration Lockdown activated. The Flash Descriptor Override Strap-Pin is set. Restrictions implied by the Master Section of the flash descriptor are NOT in effect. Please note that Protected Range (PR) restrictions still apply. Reading OPCODES... done 0x06: 0x3f00 (HSFC) HSFC: FGO=0, FCYCLE=0, FDBC=63, SME=0 0x50: 0x0000ffff (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write. 0x58: 0x0fff0e00 FREG1: BIOS region (0x00e00000-0x00ffffff) is read-write. 0x5C: 0x0dff0001 FREG2: Management Engine region (0x00001000-0x00dfffff) is read-write. 0x90: 0x80 (SSFS) SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 0x91: 0xf80000 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=0 0x94: 0x0000 (PREOP) 0x96: 0x0000 (OPTYPE) 0x98: 0x00000000 (OPMENU) 0x9C: 0x00000000 (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x80800000 (LVSCC) LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1 0xC8: 0x00000000 (UVSCC) UVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0 0xD0: 0x50444653 (FPB) Enabling hardware sequencing because some important opcode is locked. OK. The following protocols are supported: FWH, Programmer-specific. Probing for Programmer Opaque flash chip, 0 kB: Hardware sequencing reports 1 attached SPI flash chip with a density of 16384 kB. The first partition ranges from 0x000000 to 0x652fff. In that range are 1619 erase blocks with 4096 B each. The second partition ranges from 0x653000 to 0xffffff. In that range are 2477 erase blocks with 4096 B each. Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH00B4, 512 kB: probe_82802ab: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH004, 512 kB: probe_82802ab: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0x75, id2 0xef, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0x75, id2 0xef, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0x13, id2 0x8c, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0x75, id2 0xef, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0x75, id2 0xef, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF016C, 2048 kB: probe_82802ab: id1 0x4c, id2 0x41, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0x75, id2 0xef, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0x75, id2 0xef, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0x4c, id2 0x41, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0x75, id2 0xef, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0x75, id2 0xef, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0x02, id2 0x58, id1 is normal flash content, id2 is normal flash content Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific). Reading flash... Reading 16777216 bytes starting at 0x000000. Timeout error between offset 0x00014400 and 0x0001443f (= 0x00014400 + 63)! HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=1, FDOPSS=0, FDV=1, FLOCKDN=1 HSFC: FGO=0, FCYCLE=0, FDBC=63, SME=0 Read operation failed! FAILED. Restoring MMIO space at 0x7f792469b8a0 Restoring PCI config space for 00:1f:0 reg 0xdc [root@localhost flashrom_trunk]#

3 3

Re: [flashrom] Writing to a specific Flash region with Layout approach
by Pradeep Ch 02 Aug '16

02 Aug '16

Hello David, Thanks for commands usage . For the command: dd if=test2.bin of=test.bin bs=1 seek=$((0x1a1e0)) conv=notrunc It is subtle when you are mentioning bs=1, If we donot specify bs, it will take a default value of 512 I suppose, then seek will be (0x1a1e0)*512 which will skip lot of bytes from the beginning of the file. So, we cannot use a layout file to write to a specific region. Rgds, On Tue, Aug 2, 2016 at 1:31 AM, David Hendricks <dhendrix(a)chromium.org> wrote: > > > On Mon, Aug 1, 2016 at 9:59 AM, Pradeep Ch <shanmugp(a)sysargus.com> wrote: > >> How do I pad the bootloader. img to 8MBytes ? But, still it occupies the >> first 106976 Bytes right ? Remaining space is empty I suppose. >> > To create a 8MB file full of 0xff bytes: > dd if=/dev/zero bs=1k count=8192 2>/dev/null | tr "\000" "\377" > test.bin > > From there, you can use dd with skip=, seek=, and conv=notrunc to place > your content wherever you need to in the image. For example, > dd if=test1.bin of=test.bin bs=1 conv=notrunc > dd if=test2.bin of=test.bin bs=1 seek=$((0x1a1e0)) conv=notrunc > > Thanks. >> On Aug 1, 2016 9:08 PM, "Urja Rannikko" <urjaman(a)gmail.com> wrote: >> >>> Hi, >>> >>> On Mon, Aug 1, 2016 at 10:33 AM, Pradeep Ch <shanmugp(a)sysargus.com> >>> wrote: >>> > >>> > I am attempting to write to a flashrom using layout/region approach. >>> > The NOR flash size is 8MBytes. The file size I am writing is 106976 >>> Bytes. >>> > >>> > The rom.layout file contents are: >>> > 00000000:0001a1df test1 >>> > 0001a1e0:007fffff test2 >>> > >>> > The command I am using is: >>> > ./flashrom -p ft2232_spi:type=arm-usb-ocd --layout rom.layout --image >>> test1 >>> > -w bootloader.img >>> > >>> > The error I am getting is : >>> > Using region: "test1". >>> > Calibrating delay loop... OK. >>> > Found Eon flash chip "EN25Q64" (8192 kB, SPI) on ft2232_spi. >>> > Error: Image size (106976 B) doesn't match the flash chip's size >>> (8388608 >>> > B)! >>> > >>> > Please let me know about the error. >>> >>> The current layout system will only limit the actually written area, >>> not change the requirements of the flash file being the size of the >>> chip, so in this case you'd need to pad the bootloader.img to 8MB. >>> >> >> _______________________________________________ >> flashrom mailing list >> flashrom(a)flashrom.org >> https://www.flashrom.org/mailman/listinfo/flashrom >> > > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. >

1 0

Re: [flashrom] Writing to a specific Flash region with Layout approach
by David Hendricks 01 Aug '16

01 Aug '16

On Mon, Aug 1, 2016 at 9:59 AM, Pradeep Ch <shanmugp(a)sysargus.com> wrote: > How do I pad the bootloader. img to 8MBytes ? But, still it occupies the > first 106976 Bytes right ? Remaining space is empty I suppose. > To create a 8MB file full of 0xff bytes: dd if=/dev/zero bs=1k count=8192 2>/dev/null | tr "\000" "\377" > test.bin >From there, you can use dd with skip=, seek=, and conv=notrunc to place your content wherever you need to in the image. For example, dd if=test1.bin of=test.bin bs=1 conv=notrunc dd if=test2.bin of=test.bin bs=1 seek=$((0x1a1e0)) conv=notrunc Thanks. > On Aug 1, 2016 9:08 PM, "Urja Rannikko" <urjaman(a)gmail.com> wrote: > >> Hi, >> >> On Mon, Aug 1, 2016 at 10:33 AM, Pradeep Ch <shanmugp(a)sysargus.com> >> wrote: >> > >> > I am attempting to write to a flashrom using layout/region approach. >> > The NOR flash size is 8MBytes. The file size I am writing is 106976 >> Bytes. >> > >> > The rom.layout file contents are: >> > 00000000:0001a1df test1 >> > 0001a1e0:007fffff test2 >> > >> > The command I am using is: >> > ./flashrom -p ft2232_spi:type=arm-usb-ocd --layout rom.layout --image >> test1 >> > -w bootloader.img >> > >> > The error I am getting is : >> > Using region: "test1". >> > Calibrating delay loop... OK. >> > Found Eon flash chip "EN25Q64" (8192 kB, SPI) on ft2232_spi. >> > Error: Image size (106976 B) doesn't match the flash chip's size >> (8388608 >> > B)! >> > >> > Please let me know about the error. >> >> The current layout system will only limit the actually written area, >> not change the requirements of the flash file being the size of the >> chip, so in this case you'd need to pad the bootloader.img to 8MB. >> > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > https://www.flashrom.org/mailman/listinfo/flashrom > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Re: [flashrom] Writing to a specific Flash region with Layout approach
by Pradeep Ch 01 Aug '16

01 Aug '16

How do I pad the bootloader. img to 8MBytes ? But, still it occupies the first 106976 Bytes right ? Remaining space is empty I suppose. Thanks. On Aug 1, 2016 9:08 PM, "Urja Rannikko" <urjaman(a)gmail.com> wrote: > Hi, > > On Mon, Aug 1, 2016 at 10:33 AM, Pradeep Ch <shanmugp(a)sysargus.com> wrote: > > > > I am attempting to write to a flashrom using layout/region approach. > > The NOR flash size is 8MBytes. The file size I am writing is 106976 > Bytes. > > > > The rom.layout file contents are: > > 00000000:0001a1df test1 > > 0001a1e0:007fffff test2 > > > > The command I am using is: > > ./flashrom -p ft2232_spi:type=arm-usb-ocd --layout rom.layout --image > test1 > > -w bootloader.img > > > > The error I am getting is : > > Using region: "test1". > > Calibrating delay loop... OK. > > Found Eon flash chip "EN25Q64" (8192 kB, SPI) on ft2232_spi. > > Error: Image size (106976 B) doesn't match the flash chip's size (8388608 > > B)! > > > > Please let me know about the error. > > The current layout system will only limit the actually written area, > not change the requirements of the flash file being the size of the > chip, so in this case you'd need to pad the bootloader.img to 8MB. >

1 0

Re: [flashrom] Writing to a specific Flash region with Layout approach
by Urja Rannikko 01 Aug '16

01 Aug '16

Hi, On Mon, Aug 1, 2016 at 10:33 AM, Pradeep Ch <shanmugp(a)sysargus.com> wrote: > > I am attempting to write to a flashrom using layout/region approach. > The NOR flash size is 8MBytes. The file size I am writing is 106976 Bytes. > > The rom.layout file contents are: > 00000000:0001a1df test1 > 0001a1e0:007fffff test2 > > The command I am using is: > ./flashrom -p ft2232_spi:type=arm-usb-ocd --layout rom.layout --image test1 > -w bootloader.img > > The error I am getting is : > Using region: "test1". > Calibrating delay loop... OK. > Found Eon flash chip "EN25Q64" (8192 kB, SPI) on ft2232_spi. > Error: Image size (106976 B) doesn't match the flash chip's size (8388608 > B)! > > Please let me know about the error. The current layout system will only limit the actually written area, not change the requirements of the flash file being the size of the chip, so in this case you'd need to pad the bootloader.img to 8MB.

1 0

Writing to a specific Flash region with Layout approach
by Pradeep Ch 01 Aug '16

01 Aug '16

I am attempting to write to a flashrom using layout/region approach. The NOR flash size is 8MBytes. The file size I am writing is 106976 Bytes. The rom.layout file contents are: 00000000:0001a1df test1 0001a1e0:007fffff test2 The command I am using is: ./flashrom -p ft2232_spi:type=arm-usb-ocd --layout rom.layout --image test1 -w bootloader.img The error I am getting is : Using region: "test1". Calibrating delay loop... OK. Found Eon flash chip "EN25Q64" (8192 kB, SPI) on ft2232_spi. Error: Image size (106976 B) doesn't match the flash chip's size (8388608 B)! Please let me know about the error. Thanks, Pradeep Ch.

1 0

Re: [flashrom] Failed to write/read NOR flash EN25Q64 using ARM-USB-OCD Jtag.
by Stefan Tauner 01 Aug '16

01 Aug '16

On Sun, 31 Jul 2016 15:34:18 +0530 Pradeep Ch <pradeepsysargus(a)gmail.com> wrote: > favorite > <http://stackoverflow.com/questions/38674226/flashrom-tool-command-has-faile…> > > I am able to detect my flash chip when I use the command: > > ./flashrom -p ft2232_spi:type=arm-usb-ocd -c EN25Q64 > > If use the below command to write binary file to the flash memory using > JTAG - ARM-USB-OCD debugger for my target board RT5350F-OLinuXino-EVB, > > ./flashrom -p ft2232_spi:type=arm-usb-ocd -w > FlashImage_RT5350F_OLinuXino_EVB.bin > > I am getting an error, the error is: > > Found Eon flash chip "EN25Q64" (8192 kB, SPI) on ft2232_spi. > ftdi_write_data: -110, usb bulk write failed > send_buf failed before read: 1 > Reading old flash chip contents... ftdi_read_data: -110, usb bulk read failed > get_buf failed: 1 > FAILED. Do you power the whole setup via the OCD? That might be the culprit. I presume that it can not supply enough current in all operating modes. Apparently it is enough to probe for the chip though... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Failed to write/read NOR flash EN25Q64 using ARM-USB-OCD Jtag.
by Pradeep Ch 31 Jul '16

31 Jul '16

favorite <http://stackoverflow.com/questions/38674226/flashrom-tool-command-has-faile…> I am able to detect my flash chip when I use the command: ./flashrom -p ft2232_spi:type=arm-usb-ocd -c EN25Q64 If use the below command to write binary file to the flash memory using JTAG - ARM-USB-OCD debugger for my target board RT5350F-OLinuXino-EVB, ./flashrom -p ft2232_spi:type=arm-usb-ocd -w FlashImage_RT5350F_OLinuXino_EVB.bin I am getting an error, the error is: Found Eon flash chip "EN25Q64" (8192 kB, SPI) on ft2232_spi. ftdi_write_data: -110, usb bulk write failed send_buf failed before read: 1 Reading old flash chip contents... ftdi_read_data: -110, usb bulk read failed get_buf failed: 1 FAILED. Please let me know, Thanks, Pradeep Ch.

1 0

[PATCH] Work around very broken timers.
by Stefan Tauner 30 Jul '16

30 Jul '16

Allow myusec_calibrate_delay() to indicate errors and abort in cli_classic if that happens. Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> --- cli_classic.c | 6 +++++- programmer.h | 2 +- udelay.c | 22 ++++++++++++++-------- 3 files changed, 20 insertions(+), 10 deletions(-) Roxfan on IRC had major problems getting flashrom to even start because of some hardware-related timing problems. Without this patch his hardware would (almost?) endlessly loop during timer calibration. This patch aborts instead after a while and should not trigger any regressions. One can test it by overriding the gettimeofday results in measure_delay() by adding following assignments: start.tv_sec = 0; end.tv_sec = 0; start.tv_usec = 0; end.tv_usec = 0; diff --git a/cli_classic.c b/cli_classic.c index a2c2014..4a68f0b 100644 --- a/cli_classic.c +++ b/cli_classic.c @@ -414,7 +414,11 @@ int main(int argc, char *argv[]) } /* FIXME: Delay calibration should happen in programmer code. */ - myusec_calibrate_delay(); + if (myusec_calibrate_delay() != 0) { + msg_perr("Error: Custom timer calibration failed.\n"); + ret = 1; + goto out_shutdown; + } if (programmer_init(prog, pparam)) { msg_perr("Error: Programmer initialization failed.\n"); diff --git a/programmer.h b/programmer.h index bd8e98d..b39fba4 100644 --- a/programmer.h +++ b/programmer.h @@ -268,8 +268,8 @@ extern const struct board_info laptops_known[]; #endif /* udelay.c */ +int myusec_calibrate_delay(void); void myusec_delay(unsigned int usecs); -void myusec_calibrate_delay(void); void internal_sleep(unsigned int usecs); void internal_delay(unsigned int usecs); diff --git a/udelay.c b/udelay.c index 7c6961d..3562268 100644 --- a/udelay.c +++ b/udelay.c @@ -85,7 +85,7 @@ static unsigned long measure_delay(unsigned int usecs) return timeusec; } -void myusec_calibrate_delay(void) +int myusec_calibrate_delay(void) { unsigned long count = 1000; unsigned long timeusec, resolution; @@ -106,16 +106,21 @@ recalibrate: if (timeusec > 1000000 / 4) break; if (count >= ULONG_MAX / 2) { - msg_pinfo("timer loop overflow, reduced precision. "); + msg_pwarn("timer loop overflow (count=%lu, micro=%lu, timeusec=%lu), reduced precision.\n", + count, micro, timeusec); break; } count *= 2; } tries ++; - /* Avoid division by zero, but in that case the loop is shot anyway. */ - if (!timeusec) - timeusec = 1; + /* Something is completely wrong. Avoid a possible endless loop and fall back to internal_delay(). */ + if (timeusec == 0) { + micro = 0; + msg_pwarn("Timing measurement seems to be broken.\n" + "Falling back to possibly insufficient timing sources!\n"); + return 1; + } /* Compute rounded up number of loops per microsecond. */ micro = (count * micro) / timeusec + 1; @@ -168,6 +173,7 @@ recalibrate: msg_pdbg("%ld myus = %ld us, ", resolution * 4, timeusec); msg_pinfo("OK.\n"); + return 0; } /* Not very precise sleep. */ @@ -187,7 +193,7 @@ void internal_sleep(unsigned int usecs) void internal_delay(unsigned int usecs) { /* If the delay is >1 s, use internal_sleep because timing does not need to be so precise. */ - if (usecs > 1000000) { + if (micro == 0 || usecs > 1000000) { internal_sleep(usecs); } else { myusec_delay(usecs); @@ -197,9 +203,9 @@ void internal_delay(unsigned int usecs) #else #include <libpayload.h> -void myusec_calibrate_delay(void) +int myusec_calibrate_delay(void) { - get_cpu_speed(); + return get_cpu_speed() == 0; // Return 1 on errors, i.e. if get_cpu_speed() returns 0 } void internal_delay(unsigned int usecs) -- Kind regards, Stefan Tauner

1 0

[PATCH 0/6] Initial status register and access protection infrastructure
by Hatim Kanchwala 29 Jul '16

29 Jul '16

Hi, Following patches add new infrastructure for status register(s) and locking/unlocking of access protection. Detailed points for explaining each patch are included within them. Some general thoughts - - The code has a lot TODOs and FIXMEs (most of which I have addressed to myself). They are short-term targets and represent the work-in-progress nature of the patches. Future revisions will resolve them. - There are a lot of comments. Eventually much of that will be relocated to documentation and wiki, so comments in future revisions will shrink. - Some CLI code is borrowed from the ChromiumOS fork (https://chromium.googlesource.com/chromiumos/third_party/flashrom/). IMO, the exact words to use for the options is subjective. - The names for struct status_register and struct wp defines (in statusreg_layouts.c and writeprotect_layouts.c respectively) are not very creative and tend to be long. I couldn't come up with a generic scheme that captures most of the information regarding it. You are welcome to offer creative suggestions ;) Further work - - Read and write "configuration" registers (a lot of Spansion chips have those) - Add tested/untested status for new infrastructure similar to what we have for chips (like TEST_PREW, etc.) - write protection modes - protection ranges - Access protection for non-SPI chips (pointed to by Stefan over IRC) - Reuse layouts for locking/unlocking (pointed to by Stafan and David over IRC) - Handling WPS bit (a couple of GigaDevice chips have this) - Exotic chips (mostly Atmel, now Adesto, chips fall under this category) This is what I particularly seek - - Feedback on code - Feedback on CLI - Any other ideas that you'd like to add tu further work - Please add support for a few chips that you might have, and if possible also test them - would like to know how cumbersome it is Thank you for your time. I am looking forward to your feedback and having a discussion. I hope this contribution (and many more in the future) adds value to flashrom and its community. Bye, Hatim Hatim Kanchwala (6): Status register infrastructure Locking/unlocking access protection infrastructure WIP: Add support for status register infrastructure to existing chips WIP: Add support for access protection infrastructure to existing chips Integrate new infrastructure with existing codebase Add command-line interface to expose new infrastructure Makefile | 6 +- chipdrivers.h | 24 +++ cli_classic.c | 200 +++++++++++++++++++++++- flash.h | 46 +++++- flashchips.c | 176 +++++++++++++++++---- flashrom.8.tmpl | 56 ++++++- flashrom.c | 17 +- spi.h | 8 +- spi25.c | 164 +++++++++++++++---- spi25_statusreg.c | 416 +++++++++++++++++++++++++++++++++++++++++++++++++ spi25_statusreg.h | 115 ++++++++++++++ statusreg_layouts.c | 320 +++++++++++++++++++++++++++++++++++++ writeprotect.c | 405 +++++++++++++++++++++++++++++++++++++++++++++++ writeprotect.h | 40 +++++ writeprotect_layouts.c | 166 ++++++++++++++++++++ 15 files changed, 2083 insertions(+), 76 deletions(-) create mode 100644 spi25_statusreg.h create mode 100644 statusreg_layouts.c create mode 100644 writeprotect.c create mode 100644 writeprotect.h create mode 100644 writeprotect_layouts.c -- 2.7.4

2 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom