imi415
/
openocd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc/target/mips: fix grammar 

Change-Id: Ib9012a1cfccbe4f69682d106688536c4d92392dd
Signed-off-by: Christopher Head <chead@zaber.com>
Reviewed-on: http://openocd.zylin.com/5777
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
This commit is contained in:
Christopher Head 2020-07-17 11:04:50 -07:00 committed by Antonio Borneo
parent b2821b6074
commit bc987c8e31
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/manual/target/mips.txt
View File

@ -393,15 +393,15 @@ for (i = 0; i < count; i++)
}
@endcode
Each time when OpenOCD fills data to CPU (via dongle, via dmseg), CPU takes it and proceeds in executing the handler. However, since handler is in a assembly loop,
Each time when OpenOCD fills data to CPU (via dongle, via dmseg), CPU takes it and proceeds to execute the handler. However, since the handler is in an assembly loop,
CPU comes to next instruction which also fetches data from FASTDATA area. So it stalls.
Then OpenOCD fills the data again, from it's (OpenOCD's) loop. And this game continues until all the data has been filled.
Then OpenOCD fills the data again, from its (OpenOCD's) loop. And this game continues until all the data has been filled.
After the last data has been given to CPU it sees that it reached the end address, so it proceeds with next instruction. However, this instruction do not point into dmseg, so
CPU executes bunch of handler instructions (all prologue) and in the end jumps to MIPS32_PRACC_TEXT address.
On it's side, OpenOCD checks in CPU has jumped back to MIPS32_PRACC_TEXT, which is the confirmation that it correctly executed all the rest of the handler in RAM,
and that is not stuck somewhere in the RAM, or stalling on some access in dmseg - that would be an error :
On its side, OpenOCD checks in CPU has jumped back to MIPS32_PRACC_TEXT, which is the confirmation that it correctly executed all the rest of the handler in RAM,
and that is not stuck somewhere in the RAM, or stalling on some access in dmesg - that would be an error:
@code
address = 0;