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

[Uwe B. <bo...@el...>]

>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:

    Joris> On Saturday 27 August 2011, Uwe Bonnes wrote: For example:
    Joris> "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)

    Joris> Ok, clear. I think XCF currently does something else, but that
    Joris> 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

Arg, I wrote a wrong syntax here. Should be:
<multiboot-header.bit>:w   <golden.bit>:w:0x10000

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

Yes, XCF can only be erased as one block. But with
bitfile.1.bit:W:offset0 and bitfile2.bit:W:offset1, the erase action is
skipped, so partial writing is possible.

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

XCFP can be erased in sections to hold design revisions, so at least XCFP
has a use for that option. And for XCF, probably a lot of infrastructure is
already there, but probably also with some hard to find errors.

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

Again, XCFP knows about revisions, so it's more than a niche feature for SPI
programmed devices alone.  programXCF handles both XCF and XCFP, so getting
it right for XCF will fix XFCP too.

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

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

Just eliminating and getting the basic right will probably make 98% of the
users happy. But give proper error message if a user uses the
xc3sprog ... bitfile.1.bit:W:offset0 bitfile2.bit:W:offset1 
syntax on XCF/XFP.

But a look at the present code may also be worth some effort. The handling
of "current_offset" in the (int i = 0; i < nchainpos; i++) loop seems
dubious...

Bye

-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------