Breakpoint

How Breakpoints Work
==================
A hardware breakpoint stops your target code from running using external emulator-mounted electronics that is completely independent of your hardware. Logic circuits (often implemented as RAM arrays) watch every bus cycle, stopping execution when the address at which you've set the breakpoint occurs.

A hardware breakpoint never alters your code, stack, or any other target resource; it is completely non-intrusive.

A software breakpoint, by contrast, always modifies your code. Typically the source level debugger inserts an INT3 instruction in your code at each breakpoint address. (INT3 does a call through location 0000C).

When properly implemented the debugger remembers the instruction that was at the breakpoint address, replacing it after the code hits any breakpoint.The emulator detects the software breakpoint by watching the system execute the INT3 - specifically, by catching the INT3's read from location 0000C. It then switches to its own internal operation, stopping your code and running its own.

software breakpoints must modify your code, you cannot debug ROMed code with software breakpoints.

Don't Read from 0000C!Another problem arises from the way most software breakpoints work. The emulator typically watches for reads from location 0000C (the INT3 vector address). Any read from this address causes the unit to immediately breakpoint _ even if no breakpoints were set

http://www.avocetsystems.com/company/articles/hints/aphwbk.htm

NAND & NOR

NOR and NAND flash differ in two important ways:
* the connections of the individual memory cells are different
* the interface provided for reading and writing the memory is different (NOR allows random-access for reading, NAND allows only page access)

NAND: the I/O interface of NAND flash does not provide a random-access external address bus, Rather, data must be read on a block-wise basis, NAND devices also require bad block management by the device driver software



http://en.wikipedia.org/wiki/Flash_memory

debuging kdump

Convert kdump
=============
open DumpConverter
Select file
Set Logical Address (same for Debug and regular build variants)
using offsets 0x80000000 for EBI.bin and 0x88000000 for SMI.bin (7200, 7500, 7200A, etc)
Select another text field (to update UI)
Save As...
Important: Does not work well opening/saving to network location (must do locally)Important: This only captures 90% of information so capturing kdmp via PB is preferred!

PB debug kdump
=============
In PB, open kdmp.
click edit->symbol search path, and paste in the flat release directory
click target->connectivity options->debugger->CE Dump File Reader
Click target->attach device

20090707-hopper seed

"Strictly speaking, you can reproduce any particular Hopper run by using its random seed as a parameter (-sxxx) when you invoke the test. Hopper derives its randomness by calling rand() which is completely predictable if you to know its seed. All Hopper actions are bound by this rand() functionality so keystrokes (and screen taps) sent to the device from one seed run will reproduce 100% to a similarly seeded device."

http://blogs.msdn.com/hopperx/archive/2005/08/24/455572.aspx

create a shortcut file like this will run hopper in \ with seed number 305780

256#\hopper.exe -s305780

QPST couldn't recognize the phone

sometims QPST couldn't recognize the phone, it may has conflict with ClearCase network operation.