M-Labs/nix-scripts
9
0
Fork 9
Code Issues 6 Pull Requests Releases Wiki Activity

openocd: 0.11.0 jtagspi driver doesn't work properly with n25q256 #62

New Issue
Closed
opened 2021-07-27 17:48:21 +08:00 by harry · 0 comments
harry commented 2021-07-27 17:48:21 +08:00
Contributor
Copy Link

When we use the current stable 0.11.0 of openocd on our Sinara controllers (Kasli, Metlino, Sayma, etc.), the wrong SPI commands will be sent because the on-board flash device, Micron 256Mb NOR flash (equivalent to n25q256 in openocd source code due to matching device ID), is defined with 4-byte addressing SPI commands (since commit ntfreak@42f1cc57) while the jtagspi driver is only compatible with the standard 3-byte addressing mode. IMO the ARTIQ package should take care of this.

To my knowledge, there are 4 types of workaround:

  1. Fix in openocd upstream: this is being discussed over http://openocd.zylin.com/#/c/4876/.

  2. Adopt jordens' fix: modify m-labs/openocd@1739532081 to resolve conflicts with openocd upstream.

  3. Adopt a simple patch by LambdaConcept: this patch file is provided on their online manual; but this simply neglects the possibility of accessing memory beyond 125Mb.

  4. Revert recent changes to nix-scripts (e.g. c9efc20aeb): It is at least safe to use our own fork on the older openocd 0.10.0 with proxy bitstream support.

When we use the current stable 0.11.0 of openocd on our Sinara controllers (Kasli, Metlino, Sayma, etc.), the wrong SPI commands will be sent because the on-board flash device, Micron 256Mb NOR flash (equivalent to `n25q256` in openocd source code due to matching device ID), is defined with 4-byte addressing SPI commands (since commit ntfreak@[`42f1cc57`](https://github.com/ntfreak/openocd/commit/42f1cc576ab9b503fadd0b8916a139cd0bc6563e)) while the jtagspi driver is only compatible with the standard 3-byte addressing mode. IMO the ARTIQ package should take care of this. To my knowledge, there are 4 types of workaround: 1. Fix in openocd upstream: this is being discussed over http://openocd.zylin.com/#/c/4876/. 2. Adopt jordens' fix: modify m-labs/openocd@https://github.com/m-labs/openocd/commit/17395320816c0bcc4f3401633197a851aeda20ce to resolve conflicts with openocd upstream. 3. Adopt a simple patch by LambdaConcept: [this patch file](https://docs.lambdaconcept.com/screamer/_downloads/f0357c5f44c3c8c49f575cee5b6634a8/flashid.patch) is provided on their [online manual](https://docs.lambdaconcept.com/screamer/troubleshooting.html#error-contents-differ); but this simply neglects the possibility of accessing memory beyond 125Mb. 4. Revert recent changes to nix-scripts (e.g. c9efc20aeb5ad5b81fe9d987fa5dc35e37b7dd9b): It is at least safe to use our own fork on the older openocd 0.10.0 with proxy bitstream support.
sb10q closed this issue 2021-07-27 18:25:38 +08:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/nix-scripts#62
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?