On Wed, Apr 6, 2011 at 2:42 PM, Laurent Gauch <laurent.ga...@amontec.com> wrote:
> Drasko DRASKOVIC wrote:
>>
>> Hi all,
>> based on EJTAG spec, can somebody explain the difference between
>> FASTDATA competition and not competition modes :
>>
>> During a Fastdata access, the Fastdata register value shifted in
>> specifies whether the Fastdata
>> access should be completed or not. The value shifted out is a flag
>> that indicates whether the Fastdata access was
>> successful or not (if completion was requested).
>>
>> Shifting in a zero value requests completion of the
>> Fastdata access. The PrAcc bit in the EJTAG Control
>> register is overwritten with zero when the access
>> succeeds. (The access succeeds if PrAcc is one and
>> the operation address is in the legal dmseg segment
>> Fastdata area.) When successful, a one is shifted out.
>> Shifting out a zero indicates a Fastdata access failure.
>> Shifting in a one does not complete the Fastdata
>> access and the PrAcc bit is unchanged. Shifting out a
>> one indicates that the access would have been
>> successful if allowed to complete and a zero indicates
>> the access would not have successfully completed.
>>
>>
>> So my questions are :
>> 1) If we demand completion, when do we do shift-out of the SPrAcc bit
>> to check status :
>>
>
> First, you have to be sure to be in FASTDATA MODE (set the MODE in the TAP
> instruction REGISTER)
> see Table 6-1 TAP Instruction Overview
>
> Second, do not confuse PrAcc CONTROL register bit and sPrAcc FLAG added in
> the shift registers
Normally, they are not confused. If you look at the last patch I sent
(yesterday evening) I clearly observe SPrAcc in mips_ejtag.c (and
PrAcc in mips32_pracc.c, but that is of less importance).
I re-attached the patch.
> In FASTDATA mode:
> -----------------------
> For a processor MIPS 32-bits DATA register becomes 33bits in FASTDATA mode.
> from EJTAG spec., see Figure 6-6 TDI to TDO Path when in Shift-DR State and
> FASTDATA Instruction is Selected
> The LSB (bit 32) is your sPRAcc.
>
> Are you sure you are shiffting in and shifting out 33bits and not 32bits
> before coming back to the IDLE TAP STATE ?
Well... Kind of. I am doing jtag_add_dr_scan() for 1 bit in (value "1"
- completition), 1 bit out (SPracc to check).
Then I do jtag_add_dr_scan() for extra 32 data bit shif in, no shift
out (ignored, not needed, we do write not read. Is it needed to shift
the bits out nevertheless ?).
Then do jtag_execute_queue() to do the shifts, in order for shift-out
to be executed and I check shifted out bi (SPrAcc) to see if write
went well.
Basically that would make 33 bit to be shifted in and 1 bit to be
shifted out (ather 32 bits to be shifted out are ignored). Is this OK
?
Maybe there is something wrong there - you can take a quick look at
the function mips_ejtag_fastdata_scan() with my attached patch.
>>
>> a) We shift in SPrAcc, we shift it out, we check it if it is "1" -
>> that would say "You can send in data it will pass OK", and then
>> we shift in data or
>
> see Table 6-11 Fastdata Register Field Description
> Every thing is here
> 1.make sure to shift-in 1 in SPrAcc
Yes, this is done.
> 2. check the shit-out of SPrAcc -> must be one
Whe to check - before of after shifting in data ?
> 3. check the PrAcc CONTROL regsiter -> must be one
Yes, this is done in mips32_pracc.c, before calling
mips_ejtag_fastdata_scan() (refer to attached patch)
> if SPrAcc shifted-out value is one and PrAcc is one
> then the FASTDATA acccess succeeds
> else failure
Yes, this is implemented.
>
> For me that's all !
>
>> b) We shift in SPrAcc, we shift in data, we shift out SPrAcc and check
>> if if it is "1" - in this case check comes after data shift-in and it
>> would say something like "Data shifted in were well written" ?
>> Based on this :
>>
>> During Fastdata uploads and downloads, the processor will stall on
>> accesses to the Fastdata area. The PrAcc (processor
>> access pending bit) will be 1 indicating the probe is required to
>> complete the access. Both upload and download accesses
>> are attempted by shifting in a zero SPrAcc value (to request access
>> completion) and shifting out SPrAcc to see if the
>> attempt will be successful (i.e., there was an access pending and a
>> legal Fastdata area address was used). Downloads will
>> also shift in the data to be used to satisfy the load from the dmseg
>> segment Fastdata area, while uploads will shift out the
>> data being stored to the dmseg segment Fastdata area.
>>
>> I would say that it is case b) - pre-check SPrAcc and then shift-in
>> data... But I am not sure. I do not know at which point to check.
>>
>
> No sense, since your SPrAcc is in the shift regsiter itself !
I ment shift in one bit (i.e. "1"), shift out one bit (i.e. resulting
SPrAcc to check). Then check bit that we shifted out. If it is "1"
shift in additional 32 data bits. If it is "0" than goodbye with
failure, not data bits shifted in (loose of time)
> For me, you are misunderstanding the SPrAcc flag and PrAcc bit.
Maybe I have not been clear enough. The best would be to look at the
code I attached.
Thanks a lot for your comments and help.
Kind regards,
Drasko
From 3f4882c153ca15dc7689639eca52928cc4583e4b Mon Sep 17 00:00:00 2001
From: Drasko DRASKOVIC <drasko.drasko...@gmail.com>
Date: Tue, 5 Apr 2011 18:05:19 +0200
Subject: [PATCH] mips: FASTDATA needs PrAcc to be "1"
Added waiting for PrAcc to be "1" before initiating FASTDATA access.
Added error checking by verifying that shifted out SPrAcc is "1".
---
src/target/mips32_pracc.c | 17 +++++++++++------
src/target/mips_ejtag.c | 21 ++++++++++++++++++---
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/src/target/mips32_pracc.c b/src/target/mips32_pracc.c
index 178f68e..85ef48e 100644
--- a/src/target/mips32_pracc.c
+++ b/src/target/mips32_pracc.c
@@ -1056,20 +1056,25 @@ int mips32_pracc_fastdata_xfer(struct mips_ejtag *ejtag_info, struct working_are
mips_ejtag_set_instr(ejtag_info, EJTAG_INST_FASTDATA);
mips_ejtag_fastdata_scan(ejtag_info, 1, &val);
+ /* wait PrAcc pending bit for FASTDATA write */
+ if ((retval = wait_for_pracc_rw(ejtag_info, &ejtag_ctrl)) != ERROR_OK)
+ return retval;
+
/* Send the load end address */
val = addr + (count - 1) * 4;
+ mips_ejtag_set_instr(ejtag_info, EJTAG_INST_FASTDATA);
mips_ejtag_fastdata_scan(ejtag_info, 1, &val);
for (i = 0; i < count; i++)
{
- if ((retval = mips_ejtag_fastdata_scan(ejtag_info, write_t, buf++)) != ERROR_OK)
+ /* wait PrAcc pending bit for FASTDATA write */
+ if ((retval = wait_for_pracc_rw(ejtag_info, &ejtag_ctrl)) != ERROR_OK)
return retval;
- }
- if ((retval = jtag_execute_queue()) != ERROR_OK)
- {
- LOG_ERROR("fastdata load failed");
- return retval;
+ /* Send the data out using fastdata (clears the access pending bit) */
+ mips_ejtag_set_instr(ejtag_info, EJTAG_INST_FASTDATA);
+ if ((retval = mips_ejtag_fastdata_scan(ejtag_info, write_t, buf++)) != ERROR_OK)
+ return retval;
}
if ((retval = wait_for_pracc_rw(ejtag_info, &ejtag_ctrl)) != ERROR_OK)
diff --git a/src/target/mips_ejtag.c b/src/target/mips_ejtag.c
index 6229055..869b874 100644
--- a/src/target/mips_ejtag.c
+++ b/src/target/mips_ejtag.c
@@ -335,13 +335,14 @@ int mips_ejtag_fastdata_scan(struct mips_ejtag *ejtag_info, int write_t, uint32_
assert(tap != NULL);
struct scan_field fields[2];
- uint8_t spracc = 0;
+ uint8_t spracc_in = 0;
+ uint8_t spracc_out = 0;
uint8_t t[4] = {0, 0, 0, 0};
/* fastdata 1-bit register */
fields[0].num_bits = 1;
- fields[0].out_value = &spracc;
- fields[0].in_value = NULL;
+ fields[0].out_value = &spracc_out;
+ fields[0].in_value = &spracc_in;
/* processor access data register 32 bit */
fields[1].num_bits = 32;
@@ -358,6 +359,20 @@ int mips_ejtag_fastdata_scan(struct mips_ejtag *ejtag_info, int write_t, uint32_
}
jtag_add_dr_scan(tap, 2, fields, TAP_IDLE);
+
+ int retval;
+ if ((retval = jtag_execute_queue()) != ERROR_OK)
+ {
+ LOG_ERROR("fastdata load failed");
+ return retval;
+ }
+
+ if (spracc_in != 1)
+ {
+ LOG_ERROR("fastdata load failed");
+ return ERROR_FAIL;
+ }
+
keep_alive();
return ERROR_OK;
--
1.5.6.5
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
