Okay, my bad. I see that in handle_flash_protect_command() you pass either
sectors or prot_blocks as first, last. I'd argue that the SAMD
implementation should not be using 's' as the variable nor 'first' and
'last' but prot_block, first_block, last_block instead to make the point
clear to future callers of samd_protect(). The variable names led me to the
wrong conclusion.
Yeah the docs were not laser clear on HACKING OpenOCD. I replied to one
thing but I have no idea what I'm doing. I'm just an embedded developer.
On Fri, Dec 23, 2016 at 11:07 AM, Tomas Vanek <tom_...@users.sourceforge.net
> wrote:
> On 23.12.2016 13:48, Mark Odell wrote:
>
> Ignore my assert problem. I always use SWD, the assert is gone. Heat of
> debug I guess.
>
> Anyhow, I don't think it's just a doc problem. In
>
> static int samd_protect(struct flash_bank *bank, int set, int first, int
> last)
>
> first and last are sector numbers.
>
>
> Where did you find it that you are so sure ? :-)
>
> Trying to explain once more:
> first/last used to be described as sector numbers.
> In reality first/last is used as an index to bank->sectors array.
> It always depends on flash driver what it takes as a sector: real erase
> sector in flash or some other entity.
> E.g. SAMD driver in git master defines "sector" equal to erase block (as
> you already know).
> So using fresh git master OpenOCD and SAMD flash driver, first/last are
> "sectors", but "sectors" which SAMD driver defines
> as protection blocks. NOT real flash erase SECTORS.
>
> See commit
> http://openocd.zylin.com/gitweb?p=openocd.git;a=commit;h=
> 77a1c01ccbb1150ffe749a7373cf6c4dc15ecad0
>
> The commit changed flash/nor infrastructure so first/last parameters are
> indices to bank->prot_blocks array
> if driver defines it. If not, fallback to bank->sectors array is used.
>
> SAMD flash driver with http://openocd.zylin.com/3546 fills
> bank->prot_blocks array (and bank->num_prot_blocks)
> so first/last are protection block numbers, NOT SECTORS at all.
>
> I admit there were some residual code comments and messages dealing with
> 'sectors'
> and one forgotten-to-update range check in flash_driver_protect().
> http://openocd.zylin.com/3917 should fix them all.
>
> If you still do not believe me, use e.g. 'flash protect 0 1 1 on' command
> and find
> what flash part is protected (handy command to do so is 'flash fillw')
>
> As for review, I've never done one and am not sure how to do so.
>
> See HACKING file in OpenOCD root.
>
> Happy Xmas
> Tom
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
