flashrom August 2016

flashrom@flashrom.org

26 participants
43 discussions

Start a nNew thread

Skylarks chipsets

by Jason La Mont

Hi, Is there, or are there plans to, support the Intel skylake CM236 PCH? Thanks, Lee Sent from my iPhone

3 years, 12 months

Aspire One

by scrooyahoo＠riseup.net

Hi, In the Laptop table the Aspire one is listed as BAD But as there are so many different aspire one models i wonder if ALL Aspire one models are BAD In my case i have the ZG5 model also known as AOA110 (512MB) and AOA150 (1GB) These models have Winbond W25x80 EEPROMS (these are listed as supported, all OK I wonder what's the safest way to try? Also the link regarding the Aspire One in the Laptop table points to the coreboot mailing list, but in the entire post there is NO mention of the aspire one. Eventually i could de-solder the chip and try to flash it in an external programmer. I have 3 of these Acers that could use a fresh BIOS. (hopefully the latest one allows to boot from SD) Most Aspire One netbooks have BIOS issues and having a tool that doesn't require Microsoft would be very welcome. In software there is a mention of SST2400 and there is no mention of Winbond, but on the mainboard there is a Winbond 25x80 chip. Best, Wilfried

3 years, 12 months

Re: [flashrom] Broadwell-DE SoC

by Wen Wang

I am able to update the BIOS region too using Nico's patches. Updating the entire flash is still an issue - timing out in ME region. Hopefully Intel could help address it. Many thanks to Nico and Ed! Wen -----Original Message----- From: Ed Swierk [mailto:eswierk@skyportsystems.com] Sent: Tuesday, August 2, 2016 7:22 PM To: Nico Huber <nico.h(a)gmx.de> Cc: Wen Wang <wen.wang(a)adiengineering.com>; flashrom(a)flashrom.org Subject: Re: [flashrom] Broadwell-DE SoC I flashed coreboot using an external programmer (RPi), and booted it. Now flashrom with Nico's patches works fine for reading, erasing and writing the BIOS region. Just need to specify the layout (-l) and image (-i), and verify only the region being updated (-A). When I switch back to the stock BIOS I'll grab more debug output to figure out the write protection issue. --Ed On Tue, Aug 2, 2016 at 2:10 PM, Nico Huber <nico.h(a)gmx.de> wrote: > Hi Ed, > > On 02.08.2016 21:34, Ed Swierk wrote: >> With Nico's patches, I am able to read the BIOS portion of the flash >> (0x08000000-0x10000000) on a Camelback Mountain board with the stock >> BIOS. > thanks for the report. > >> I haven't been able to write the BIOS portion of the flash, though, >> as it fails to erase the very first block. Despite the warning, the >> flash is left untouched. > Your log too seems incomplete (please send a full log with -o option), > I can't say if it's not just due to write protection. > >> [...] >> Warning: SPI Configuration Lockdown activated. > We are only allowed to use SPI commands specified below. > >> [...] >> 0x94: 0x5006 (PREOP) > Each byte in PREOP specfies an allowed pre command (0x06 prepares for > write). >> 0x96: 0x4ed0 (OPTYPE) >> 0x98: 0x0201009f (OPMENU) >> 0x9C: 0xc705d803 (OPMENU+4) > Each byte in OPMENU specifies an allowed SPI command. > >> [...] >> Erasing and writing flash chip... Trying erase function 0... >> 0x800000-0x800fff:EInvalid OPCODE 0x06, will not execute. >> spi_block_erase_20 failed during command execution at address >> 0x800000 > This is supposed to fail, as SPI command 0x20 is not allowed. > (It complains about 0x06 because that's always executed before 0x20). > >> Reading current flash chip contents... done. Looking for another erase function. >> Trying erase function 1... 0x800000-0x807fff:EInvalid OPCODE 0x06, >> will not execute. >> spi_block_erase_52 failed during command execution at address >> 0x800000 > 52 is not allowed too. > >> Reading current flash chip contents... done. Looking for another erase function. >> Trying erase function 2... 0x800000-0x80ffff:ETransaction error! >> SSFS: SCIP=0, FDONE=1, FCERR=1, AEL=0 >> SSFC: SCGO=0, ACS=1, SPOP=0, COP=5, DBC=0, SME=0, SCF=4 Running >> OPCODE 0xd8 failed at address 0x800000 (payload length was 0). >> spi_block_erase_d8 failed during command execution at address >> 0x800000 > d8 is allowed but fails, might be due to a write protection. > >> Reading current flash chip contents... done. Looking for another erase function. >> Trying erase function 3... 0x000000-0xffffff:RTransaction error! >> SSFS: SCIP=0, FDONE=1, FCERR=1, AEL=0 >> SSFC: SCGO=0, ACS=0, SPOP=0, COP=4, DBC=63, SME=0, SCF=4 Running >> OPCODE 0x03 failed at address 0x023000 (payload length was 64). > Here it tried to fall back to erasing the whole chip, which again > tries to read the ME region and fails. > >> Can't read! Aborting. >> FAILED! >> Uh oh. Erase/write failed. >> Your flash chip is in an unknown state. > The warning is correct IMHO, as flashrom really doesn't know the state. > > In any case you can also try the hardware sequencing mode of flashrom > (see flashrom's manpage). It let's the hardware choose the opcodes > based on the flash descriptor. > > Nico

4 years

i found the supported laptop table

by scrooyahoo＠riseup.net

There is an aspire one listed as not suported, but it does not sat what exact type aspire one it is. I have the AOA110, also knowns as AOA150 with more RAM and ZG5. hwinfo told me that it uses an SST2400 chip. But that's as far as my skills get. I'll try FreeDOS route Best, Wilfried

4 years

How do i know if it is safe to try this tool to flash a Aspire One AOA 110?

by scrooyahoo＠riseup.net

Dear flashrom crew, I downloaded the latest BIOS for aspire one AOA 110 In case it helps here are the links https://acer--uk.custhelp.com/app/answers/detail/a_id/6054/~/updating-the-b… http://www.acer.com/ac/en/US/content/drivers http://global-download.acer.com/GDFiles/BIOS/BIOS/BIOS_Acer_3310_A_AOA110%2… Looks like the .fd file is the binary. But how do i know if this will work? Just trying to save some hardware from the scrapheap. So the risk is low, but it would be a shame if i brick this thing. Kind regards, Wilfried

4 years

Re: [flashrom] Broadwell-DE SoC

by Nico Huber

Hi Ed, On 02.08.2016 21:34, Ed Swierk wrote: > With Nico's patches, I am able to read the BIOS portion of the flash > (0x08000000-0x10000000) on a Camelback Mountain board with the stock > BIOS. thanks for the report. > I haven't been able to write the BIOS portion of the flash, though, as > it fails to erase the very first block. Despite the warning, the flash > is left untouched. Your log too seems incomplete (please send a full log with -o option), I can't say if it's not just due to write protection. > [...] > Warning: SPI Configuration Lockdown activated. We are only allowed to use SPI commands specified below. > [...] > 0x94: 0x5006 (PREOP) Each byte in PREOP specfies an allowed pre command (0x06 prepares for write). > 0x96: 0x4ed0 (OPTYPE) > 0x98: 0x0201009f (OPMENU) > 0x9C: 0xc705d803 (OPMENU+4) Each byte in OPMENU specifies an allowed SPI command. > [...] > Erasing and writing flash chip... Trying erase function 0... > 0x800000-0x800fff:EInvalid OPCODE 0x06, will not execute. > spi_block_erase_20 failed during command execution at address 0x800000 This is supposed to fail, as SPI command 0x20 is not allowed. (It complains about 0x06 because that's always executed before 0x20). > Reading current flash chip contents... done. Looking for another erase function. > Trying erase function 1... 0x800000-0x807fff:EInvalid OPCODE 0x06, > will not execute. > spi_block_erase_52 failed during command execution at address 0x800000 52 is not allowed too. > Reading current flash chip contents... done. Looking for another erase function. > Trying erase function 2... 0x800000-0x80ffff:ETransaction error! > SSFS: SCIP=0, FDONE=1, FCERR=1, AEL=0 > SSFC: SCGO=0, ACS=1, SPOP=0, COP=5, DBC=0, SME=0, SCF=4 > Running OPCODE 0xd8 failed at address 0x800000 (payload length was 0). > spi_block_erase_d8 failed during command execution at address 0x800000 d8 is allowed but fails, might be due to a write protection. > Reading current flash chip contents... done. Looking for another erase function. > Trying erase function 3... 0x000000-0xffffff:RTransaction error! > SSFS: SCIP=0, FDONE=1, FCERR=1, AEL=0 > SSFC: SCGO=0, ACS=0, SPOP=0, COP=4, DBC=63, SME=0, SCF=4 > Running OPCODE 0x03 failed at address 0x023000 (payload length was 64). Here it tried to fall back to erasing the whole chip, which again tries to read the ME region and fails. > Can't read! Aborting. > FAILED! > Uh oh. Erase/write failed. > Your flash chip is in an unknown state. The warning is correct IMHO, as flashrom really doesn't know the state. In any case you can also try the hardware sequencing mode of flashrom (see flashrom's manpage). It let's the hardware choose the opcodes based on the flash descriptor. Nico

4 years

Broadwell-DE SoC

by Wen Wang

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]#

4 years

Re: [flashrom] Writing to a specific Flash region with Layout approach

by Pradeep Ch

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. >

4 years

Re: [flashrom] Writing to a specific Flash region with Layout approach

by David Hendricks

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.

4 years

Re: [flashrom] Writing to a specific Flash region with Layout approach

by Pradeep Ch

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. >

4 years

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom August 2016