Sharpflash Bugs: Difference between revisions
(→More) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 4: | Line 4: | ||
== Partition Overrun == | == Partition Overrun == | ||
Version: 0.1 | |||
Suspected Bug: If there are bad blocks, writing will overrun, and possibly corrupt next partition. | Suspected Bug: If there are bad blocks, writing will overrun, and possibly corrupt next partition. | ||
| Line 14: | Line 16: | ||
== Speed == | == Speed == | ||
Version: 0.1 | |||
The program is very slow - it can be speeded up several ways: | The program is very slow - it can be speeded up several ways: | ||
| Line 20: | Line 24: | ||
downloading a programmer program to the RAM, and also the code to be programmed. the programmer program can then write and check, thus reducing the involvement of jtag. OpenOCD has a lot of the code needed to do this. | downloading a programmer program to the RAM, and also the code to be programmed. the programmer program can then write and check, thus reducing the involvement of jtag. OpenOCD has a lot of the code needed to do this. | ||
== Corruption == | |||
Suspect that writes are dropping the odd byte here and there, so the resulting data is not what is wanted. | |||
== More ... == | == More ... == | ||
Latest revision as of 18:01, 3 November 2007
Bugs
Please leave details of bugs and bug-fixes on this page, or chat about them on the discussion tab ...
Partition Overrun
Version: 0.1
Suspected Bug: If there are bad blocks, writing will overrun, and possibly corrupt next partition.
Temporary fix: run sharpflash -b and reduce length in sharpflash -w command by 0x4000 * number of known bad blocks in partition.
Permanent Fix: Truncate (lose) any blocks which overrun the specified length in the -w command.
Issues: There may be issues with this - I don't understand how the device driver uses the flash - i.e. could it have an unused gap, then use the last block on the partition?
Speed
Version: 0.1
The program is very slow - it can be speeded up several ways:
using a different scan chain to write to the processor memory - this would mean that the processor flash controller would write the ECC and 16 bytes instead of us doing it. The number of jtag clock ticks would probably also be less.
downloading a programmer program to the RAM, and also the code to be programmed. the programmer program can then write and check, thus reducing the involvement of jtag. OpenOCD has a lot of the code needed to do this.
Corruption
Suspect that writes are dropping the odd byte here and there, so the resulting data is not what is wanted.