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

Closed
opened 3 months ago by harry · 0 comments
harry commented 3 months ago
Collaborator

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 3 months ago
sb10q referenced this issue from a commit 3 months ago
sb10q referenced this issue from a commit 3 months ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.