Hi all,
I would like to ask again for the problems noted below.
If it seems reasonable from the maintainers point of view, I'll
prepare the patch.
Otherwise I'll keep the implementation just for me, as the existing
solution seems to be working for the resto of people (but for me is
wrong).
BTW. Andy, what core are you using ? M4K or something else ? I am
using M14Kc, but I believe that EJTAG implementation should be exactly
the same...
Best regards,
Drasko
On Tue, Mar 29, 2011 at 2:35 PM, Drasko DRASKOVIC
<drasko.drasko...@gmail.com> wrote:
> On Fri, Mar 25, 2011 at 4:29 PM, Spencer Oliver <s...@spen-soft.co.uk> wrote:
>> On 25/03/2011 10:37, Drasko DRASKOVIC wrote:
>>>
>>> Obviausly, there is an inconsistency of mips_ejtag_fastdata_scan() in
>>> the loop comparing to previous references - it is not preceded by
>>> mips_ejtag_set_instr().
>>
>> This should not matter. The second call can be removed as the fastdata
>> instruction is already selected in the tap.
>
> I agree with you. But for some reason it meters for me. If I do not
> put mips_ejtag_set_instr(ejtag_info, EJTAG_INST_FASTDATA) inside the
> loop function fails with error :
> mini program did not return to start.
>
> And not only that. I also had to assure that PrAcc is "1" by putting
> these lines inside the loop :
> /* wait PrAcc pending bit for FASTDATA write */
> if ((retval = wait_for_pracc_rw(ejtag_info, &ejtag_ctrl)) != ERROR_OK)
> return retval
>
> But this sounds more or less logical, because EJATG spec says explicitly :
>
> As noted above, two conditions must be true for the Fastdata access to
> succeed. These are:
> • PrAcc must be 1, i.e., there must be a pending processor access.
> • The Fastdata operation must use a valid Fastdata area address in the
> dmseg segment (0xF..F20.0000 to
> 0xF..F20.000F).
>
> But for this to work, wait_for_pracc_rw() had to be modified before,
> as it contains useless and wrong while(1) loop, as we discussed
> before.
>
> So, when you take all of this into account, I am really surprised that
> current implementation works for some people.
>
> I think that FASTDATA loop in mips32_pracc_fastdata_xfer() :
> for (i = 0; i < count; i++)
> {
> /* Send the data out using fastdata (clears the access pending bit) */
> if ((retval = mips_ejtag_fastdata_scan(ejtag_info, write_t,
> buf++)) != ERROR_OK)
> return retval;
> }
>
> should actually look like this :
>
> for (i = 0; i < count; i++)
> {
> /* wait PrAcc pending bit for FASTDATA write */
> if ((retval = wait_for_pracc_rw(ejtag_info, &ejtag_ctrl)) !=
> ERROR_OK)
> 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;
> }
>
> and that sending of both start and end addresses before should be
> preceded with corrected wait_for_pracc_rw(), as requested by the EJTAG
> spec.
>
> I am very concerned to submit the patch, having in mind that Andrew
> and you confirm that the mips32_pracc_fastdata_xfer() works as it is
> now in the git repo.
>
> BR,
> Drasko
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
