| 02:30.09 | *** join/#qi-hardware fengling (~fengling@101.254.186.97) |
| 03:07.40 | *** join/#qi-hardware sb0_ (~sb0@123202036015.ctinets.com) |
| 07:23.43 | *** join/#qi-hardware jekhor (~jek@46.216.12.20) |
| 07:31.57 | *** join/#qi-hardware kyak (~kyak@89-178-174-19.broadband.corbina.ru) |
| 07:31.57 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 08:39.27 | *** join/#qi-hardware xiangfu (~xiangfu@124.202.191.226) |
| 10:56.08 | *** join/#qi-hardware Haswell (~Haswell@unaffiliated/haswell) |
| 11:47.42 | DocScrutinizer05 | ((<wpwrak> maybe a fresh pair of eyes will find it in minutes ...)) Link, and instructions what's the problem to look for, please! |
| 11:49.19 | DocScrutinizer05 | whitequark: are you meanwhile ready to emigrate before the frontiers close and arms are pointing direction west? |
| 12:12.49 | *** join/#qi-hardware jwhitmore (~jwhitmore@host86-154-188-50.range86-154.btcentralplus.com) |
| 12:41.32 | wpwrak | DocScrutinizer05: it's a hard piece of work. the question is: why is my implementation of SWD unreliable ? my implementation is here: https://gitorious.org/anelok/anelok/source/swdlib |
| 12:41.55 | wpwrak | there are some links to resources in https://gitorious.org/anelok/anelok/source/swdlib/swdlib.c |
| 12:42.50 | wpwrak | note that there is more out there, and some of the material is contradictory. so the first step is to develop consistent conceptd |
| 12:59.20 | DocScrutinizer05 | sdwlib is conecting to the anelok "debug port" to program the chip? From ben? |
| 13:12.03 | *** join/#qi-hardware pcercuei (~pcercuei@2a02:810d:1b40:1118::4) |
| 13:12.33 | *** join/#qi-hardware mth (iosdkemj@88.159.34.112) |
| 14:53.02 | wpwrak | yes. ben -> ubb -> anelok -> "debug port" of the kinetis |
| 14:53.45 | wpwrak | i think most arms nowadays have some form of swd |
| 15:05.32 | wpwrak | swd then talks to the debug port or the AP. on the AP you have one entity that does a few flash things and another one that gives access to the AHB (system bus). so you basically have: 1) a wire protocol to move data to the debug interface. 2) a protocol to talk to the debug port. 3) a protocol to talk to the AHB port. 4) a protocol (which is also used by software) to command flash operation. |
| 15:07.20 | wpwrak | plus a few bits and pieces, e.g. the protocol on the MDM-AP, which is the critter that does the additional flash operations, such as checking security status, commanding a mass erase, etc. |
| 16:30.34 | *** join/#qi-hardware nicksydney (~quassel@61.155.dsl.syd.iprimus.net.au) |
| 18:07.04 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a08c:1::6e) |
| 18:34.18 | *** join/#qi-hardware FDCX_ (~fdcx@188.25.144.148) |
| 19:22.09 | *** join/#qi-hardware porchao (~quassel@61.245.23.230.eo.eaccess.ne.jp) |
| 20:22.18 | *** join/#qi-hardware valhalla_ (~valhalla@88-149-227-3.v4.ngi.it) |
| 20:23.05 | *** join/#qi-hardware jwhitmore (~jwhitmore@host86-154-190-143.range86-154.btcentralplus.com) |
| 21:16.06 | *** join/#qi-hardware jekhor (~jek@134.17.131.16) |
| 21:20.20 | *** join/#qi-hardware jekhor (~jek@134.17.131.16) |
| 22:04.14 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 22:08.19 | *** join/#qi-hardware lrockhq (~AOv2@unaffiliated/sirlongrock) |
| 22:59.17 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 23:35.42 | *** join/#qi-hardware lrockhq (~AOv2@c-50-173-74-12.hsd1.ca.comcast.net) |
| 23:35.42 | *** join/#qi-hardware lrockhq (~AOv2@unaffiliated/sirlongrock) |
| 23:43.42 | *** join/#qi-hardware rejon (~rejon@245.sub-70-195-71.myvzw.com) |