i tried some different versions, including mid2008 ones, and i work now mainly with the latest svn version.
i forgot : an example of the CP15 registers : data CP15(0) 41029402 CP15(1) C000107D >> CP15(2) 00000015 >> D region 0,2,4 cachable CP15(3) 00000017 CP15(5) 0000FEFF CP15(6) 00000027 08000035 08000031 20000033 2400002B 38000035 2201401B 22020021 CP15(7) 00000000 CP15(9) 00000000 CP15(F) 00000000 instruction CP15(0) 0F0F10F1 CP15(2) 00000015 >> D region 0,2,4 cachable CP15(5) 0000FEFF CP15(6) 00000027 08000035 08000031 20000033 2400002B 38000035 2201401B 22020021 CP15(7) 00000000 CP15(9) 00000000 Cory Walker a écrit : > You did compile openocd from source right? the repo has an outdated > version (commit 1147 when the current is 2294) > > On Sat, 2009-06-20 at 17:28 +0900, tof wrote: >> Hello >> >> >> some news : >> >> We have now a working ARM core in debug. The problem is., as soon as TCK >> gets closcked, all the memories and peripherials are disconnected from >> the micro. (the nano freezes) >> >> I cannot acess any memory, so it's not possible to dump the mask rom. >> Also, between the clocking of the jtag, and the efffective stopping of >> the execution, many instruction can get executed, leading to random >> effects. These instructions are usually a fixed opcode. >> >> Useful infos we can get : >> - all core registers, at any time (small chance of corruption) >> - CP15 registers : R/W acess : config of the memory system... >> - some sparse data left in the data cache. Unfortunately the instruction >> cache cannot be acessed, and the caches are not active during the first >> phase of the boot (only activated when the screen light turns on) >> - the memory map is guessed to be nearly the same than the 8700 >> - the NOR flash is physically acessed, even if the value does not arrive >> to the processor. >> - i did not found a scanchain 3 (1 bit only ?) >> >> >> I suspect 2 things >> a) some protection scheme introduced by samsung externally to the core >> b) some problem from openocd for clocking the load instructions at >> system speed. >> >> >> For acessing the memory, the debugger needs to follow a special >> procedure, so that the core resynchronizes to sys. clock, instead of the >> JTAG clock. This could be an issue. Normally openocd handles this, but >> there are far more users of the ARM920 than the ARM940 (with different >> memory systems) >> >> To check that, we could make a trial with a commercial JTAG debugger+SW >> does someone here own this kind of hardware ? >> >> >> some data examples : >> >> http://f4eru.free.fr/nano2/log/ >> >> >> the dump with 4 words is the Dcache data >> >> the random patterns with most time 16bits content are the corrupt values >> >> >> >> Cory Walker a écrit : >>> Also, could you explain the difference between red and pink on your >>> annotations? >>> >> the pink is just for interesting signals... >> >> >> >> >> sto >> >> >> _______________________________________________ >> Linux4nano-dev mailing list >> [email protected] >> https://mail.gna.org/listinfo/linux4nano-dev >> http://www.linux4nano.org > > > _______________________________________________ > Linux4nano-dev mailing list > [email protected] > https://mail.gna.org/listinfo/linux4nano-dev > http://www.linux4nano.org _______________________________________________ Linux4nano-dev mailing list [email protected] https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
