Hi Stefan.
IIUC, I will need to first create a "parent" 8MB image in which the "main" region is placed in its correct relative location in "parent". I then invoke flashrom using the romlayout file and the image option as in "-i main", and write option as in "-w parent". flashrom then extracts the region
"main" from "parent" and flashes the ROM just with "main" region.
It would seem that your patches are the way to go if you have the time to merge them.
Many thanks Stefan (and to others) who are donating valuable time to enhance/maintain what is a great piece of software.
John
On Thursday, February 7, 2013, Stefan Tauner wrote:
On Thu, 7 Feb 2013 16:09:45 -0800
John Gainsborough <jgindc1@gmail.com> wrote:
> Hi Stefan.
>
> I am now attempting to write to a flashrom using the layout/region
> approach. I need to write a region from a 4MB ROM to the beginning of an
> 8MB ROM.
> The region image from the 4MB ROM is 4,128,768 bytes == 0x3f0000 long and
> this file is called image1.
> I have defined the 8MB ROM layout in file called romlayout_8MB to be:
>
> 000000:3effff main
> 3f0000:7fffff remainder
>
> i.e I want to place the contents of file image1 in to the 8MB ROM region
> defined as main.
>
> I invoked flashrom as follows:
>
> flashrom -p buspirate_spi:dev=/dev/ttyUSB0,spispeed=250k -l romlayout_8MB
> -i main -w image1
>
> The flash ROM is detected correctly, delay calculated, but then flashrom
> immediately returns the error:
> "image size doesn't match".
>
> As always, guidance/suggestions gratefully received.
That's one of the other things my patches fix :)
The image you supply with -v/-r/-w is always used to present a mapping
of the whole chip. The layout information is only used to select the
address range inside that mapping. So for vanilla flashrom you have to
create an 8MB file and fill the first 4MB with the content you want and
continue as you have done.
With my patches one can add an image name to any -i parameter (e.g. -i
main:main.img) which is then mapped to the corresponding offset. IIRC
one has still to supply a whole image with the correct size, but if the
needed ranges are also present as "-i images" then it would not be used
at all. Similar for the read operations: it would create a whole image
with a lot of 0xFFs outside the selected regions and smaller/exact
files for the "-i images".
Maybe I have some time at the weekend to integrate the patches. I think
there is consensus that we want them in and they have been tested by a
number of people, so i think it should not break too much :)
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner