xc3sprog-users

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

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

Hello Uwe,

Thanks for fixing the FTD2XX dependency.

Something else: Last week I tried to program a board with one BIT file 
split over two XCFS devices. I noticed that this no longer works because 
some stuff got mixed up between the bitfile-splitting logic and the 
offset/rlength logic.

I'm trying to fix it, but my problem now is that I don't understand what 
the intended behaviour of the offset/rlength logic is.

For example: "xc3sprog w:sample.bit:64:BIT:32"

Should this take the complete contents of sample.bit (i.e. bytes 0 .. 32 
of the file) and program it into bytes 64 .. 95 of the flash chip?
Or should this take bytes 64 .. 95 from sample.bit and program them into 
bytes 64 .. 95 of the flash chip?

Same question for: "xc3sprog r:sample.bit:64:BIT:32"

This one is especially confusing. It seems that ProgAlgXCF::read takes 
bytes 64 .. 95 and puts them into positions 64 .. 95 of the buffer.
But then BitFile::saveAs writes buffer positions 0 .. 32 to disk.

Also, what is the use case for the offset/rlength feature? Understanding 
that may help me to do the right thing with the multi-PROM logic.

Joris.

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

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

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

    Joris> Hello Uwe, Thanks for fixing the FTD2XX dependency.
Hello,

thanks for your work!

    Joris> Something else: Last week I tried to program a board with one BIT
    Joris> file split over two XCFS devices. I noticed that this no longer
    Joris> works because some stuff got mixed up between the
    Joris> bitfile-splitting logic and the offset/rlength logic.

    Joris> I'm trying to fix it, but my problem now is that I don't
    Joris> understand what the intended behaviour of the offset/rlength
    Joris> logic is.

    Joris> For example: "xc3sprog w:sample.bit:64:BIT:32"

    Joris> Should this take the complete contents of sample.bit (i.e. bytes
    Joris> 0 .. 32 of the file) and program it into bytes 64 .. 95 of the
    Joris> flash chip?  Or should this take bytes 64 .. 95 from sample.bit
    Joris> and program them into bytes 64 .. 95 of the flash chip?

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> Same question for: "xc3sprog r:sample.bit:64:BIT:32"

    Joris> This one is especially confusing. It seems that ProgAlgXCF::read
    Joris> takes bytes 64 .. 95 and puts them into positions 64 .. 95 of the
    Joris> buffer.  But then BitFile::saveAs writes buffer positions 0 .. 32
    Joris> to disk.

Intended effect when reading is to start reading the PROM at offset for
length bytes

Probably I broke XCF writing. I have done no work on a design with XCF
since long and I don't have any multi-prom design to test at all.

    Joris> Also, what is the use case for the offset/rlength feature?
    Joris> Understanding that may help me to do the right thing with the
    Joris> multi-PROM logic.

The use case is to write a multi-boot pattern to serial flash
xc3sprog -c xx -I w:<multiboot-header.bit>:0 w:<golden.bit>:0x10000 w:<normal-image.bit>:0x190000

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

with PROMs at JTAG chain positions 2,4  for the example above.

An example for a XC6SLX45 multiboot header is in the source. We have this
XC6SLX serial multiboot pattern in a somehow "productive" use here.

The optional length could allow partial overwrite. The main use is to read
back the different images written above to different files against reading
the whole flash image to one file.

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.

Bye

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

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

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.

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

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

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

On Sunday 28 August 2011, Uwe Bonnes wrote:
> 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.

Ah, right. I was not aware of the difference between 'W' and 'w'.

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

Not really. The subrange feature is pushed down from programXCF to the 
actual ProgAlg code. ProgAlgXCF tries to handle subranges, but 
ProgAlgXCFP simply ignores them.

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

Ok, let's try to fix it then.
The attached patch makes multi-PROM programming work again, and also 
tries to do the right thing about offset/rlength situations. Note that I 
have not really tested offset/rlength because I don't have a natural 
test case for it.

I took the liberty to change/simplify a few other small things in 
ProgAlgXCF code; mostly integer signedness I think.

Greetings, Joris.

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

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

>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:
...
    Joris> Ok, let's try to fix it then.  The attached patch makes
...

Applied. Thanks again for the patch. I tested against the simples case
(single XCF programming), and it works :-)
-- 
Uwe Bonnes                bo...@el...

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