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