Re: [Xc3sprog-users] Use of offset/rlength parameters in xc3sprog

[Joris v. R. <jo...@sr...>]

On Saturday 27 August 2011, Uwe Bonnes wrote:
> Joris> For example: "xc3sprog w:sample.bit:64:BIT:32"
> 
> It's intended effect would be to take bytes 0..31 of the bitfile and
> write it starting at PROM position 64
> (offset for offset in PROM, rlength for bitfile read length)

Ok, clear. I think XCF currently does something else, but that can be 
fixed.

> For xcf, intended command line is like
> xc3sprog -c xx -p 2,4,... -I w:<multiboot-header.bit>:0
> w:<golden.bit>:0x10000 w:<normal-image.bit>:0x190000

In the case of XCF, I'm not yet convinced that this would be useful.
As XC3SPROG processes the bitfiles, it performs an erase of the PROM 
device immediately before programming each bit file. Merging two 
bitfiles into one PROM device is thus not possible, because the PROM 
would be erased after programming the first file and before programming 
the second file.

This could probably be solved as well. But alternatively, you could 
decide that PROM-subranging is not useful for XCF, and then we could 
simply kick it out of the XCF code.
What about XCFxxP?

I am not (yet) familiar with Spartan-6, so I don't understand what is at 
stake in this decision. Do all Spartan-6 boards use SPI flash in 
practice? In that case I think we should avoid burdening the XCF code 
with a niche feature which can not even be tested.

> As I intend to have orthogonal arguments, I tried to make XCF behave
> like serial flash programming, but probably got it wrong. Any help
> welcome. Multi PROM arrangements will make things more difficult.

I will look into XCF programming, and I hope to get multi-PROM working 
again. Please advise me on the way forward with XCF-subranging, i.e. try 
to fix or just eliminate.

Greetings, Joris.