2014-05-31 00:06 zrafa has joined #qi-hardware 2014-05-31 00:06 hey hey 2014-05-31 00:06 where are the arm cortex-m hackers here? :) 2014-05-31 00:09 I would like to learn if it is possible to load some code in RAM in reset mode and then to jump to this code. We are using swd with the mk20 and in reset mode we are able to load some code in ram. But, we can not change the vtor in reset mode, so we would like to know if after to leave from reset we can jump to our code in ram. I do not have hardware to test right now :( we have this problem at uni, but I can test from time to time. IN reset mode, if we loa 2014-05-31 00:09 some code in ram, could we change register 15 (program counter) then leave from reset to try to jump to our code in ram? 2014-05-31 00:10 the mk20 is an arm cortex-m4 2014-05-31 00:18 zrafa: I did that with m3 2014-05-31 00:18 well 2014-05-31 00:18 define "reset mode" more precisely 2014-05-31 00:19 i guess SWD mode entered after reset, with the core being debugged 2014-05-31 00:20 and yes, i think that should work 2014-05-31 00:20 yes, then I did exactly that 2014-05-31 00:21 though, why would you do it like this ? just run your fw from reset, that is unless you plan to use a debugger 2014-05-31 00:31 zrafa: setting the PC would work as you expect 2014-05-31 00:31 PC isn't that special in ARMs. 2014-05-31 00:33 wpwrak: we have a little gdb server in SIE board, with ubb to have SWD with mk20 2014-05-31 00:33 wpwrak: then we can not flash the mk20 yet, or at least, we want to try to load some code (we can right now) on RAM, and then we would like to jump there after leaving from reset 2014-05-31 00:34 whitequark: cool ! :) (setting the program counter) 2014-05-31 00:34 whitequark: I will try then :) 2014-05-31 00:35 whitequark: I can not test right now, but we triet to set VTOR to something in RAM, but in reset mode it seems that we can not change that value (if we change and then we read vtor still is 0x00000000 2014-05-31 00:35 ) 2014-05-31 00:35 wpwrak: ^ 2014-05-31 00:35 ah, and regarding the new happy marriage of Apple and Beats, i wonder if someone will make an update of: www.businessinsider.com/these-are-the-14-best-economist-covers-2011-7#the-trouble-with-mergers-september-10-1994-1 2014-05-31 00:36 zrafa: VTOR? 2014-05-31 00:36 the vector table, right? 2014-05-31 00:36 zrafa: ah, i'd try to solve the flashing then :) all you need is a DFU loader. after than, you can use DFU. doesn't get any more comfortable :) 2014-05-31 00:38 or you can flash it via the debugger just as well. 2014-05-31 00:38 see how texane/stlink does it 2014-05-31 00:39 basically you build this https://github.com/texane/stlink/blob/master/flashloaders/stm32f4.s 2014-05-31 00:39 then upload it to an arbitrary position in RAM together with the bytes to flash, and jump to it 2014-05-31 00:39 gdb can instruct the gdbserver to do that, too. 2014-05-31 00:43 whitequark: yeaht, the vector table 2014-05-31 00:44 yes, we can write on flash as well, but we want to play with our experiments just to learn 2014-05-31 00:44 not sure why VTOR won't change, that sounds weird 2014-05-31 00:44 wpwrak: no just to flash something and then forgot what all this swd is about :) 2014-05-31 00:44 i suppose you tried the mechanism you use to change the VTOR already on, say, a port register to toggle a LED and such ? 2014-05-31 00:45 whitequark: we were thinking that we could not chang vtor because in reset mode 2014-05-31 00:45 wpwrak: led okey yes 2014-05-31 00:45 :) 2014-05-31 00:46 and at what address is VTOR ? 2014-05-31 00:47 0xE000ED08 2014-05-31 00:47 0xE000ED08 VTOR RW Privileged 0x00000000 Vector Table Offset Register 2014-05-31 00:47 :) 2014-05-31 00:47 vtor shouldn't behave like that 2014-05-31 00:47 but I'm too lazy to pull out my stm boards 2014-05-31 00:48 whitequark: if we write on RAM and READ after that, then new value is on RAM and all is okey. The same with some registers, for example, to turn on a led 2014-05-31 00:48 hmm, if you two agree, then i won't bother with checking ;-) 2014-05-31 00:48 but today we were thinking to load some code in RAM (we did, because we are using a incomplete gdb server), but when we tried to change 2014-05-31 00:49 vtor then after read it again it showed us 0x00000000 :( 2014-05-31 00:49 zrafa: what have you changed it to? 2014-05-31 00:49 what's the CPSR value (are you in privileged mode?) 2014-05-31 00:50 (you should be) 2014-05-31 00:50 whitequark: we tried to put in vtor some valid RAM address 2014-05-31 00:51 it needs to be properly aligned 2014-05-31 00:51 0x20000000 should work fine 2014-05-31 00:52 whitequark: wpwrak : my new doub is ... if in reset mode we change the register 15 (program counter) to some address in RAM, after leaving the reset mode, will not it change the register again with 0x00000004 ? 2014-05-31 00:52 whitequark: yes, we did 2014-05-31 00:52 (aligned) 2014-05-31 00:52 zrafa: what value did you try ? 2014-05-31 00:55 wpwrak: let me check the logs 2014-05-31 00:58 bah, dont have access to my pc at uni, but I am sure that it was a correct ram address and aligned (and using just the bits[29:7] vtor use for that offset) 2014-05-31 00:58 wpwrak: ^ 2014-05-31 01:00 whitequark: wpwrak : my new doub is ... if in reset mode we change the register 15 (program counter) to some address in RAM, after leaving the reset mode, will not it change the register again with 0x00000004 ? 2014-05-31 01:01 (ram address) as in 0x2000xxxx ? (i.e., SRAM_U, not SRAM_L) 2014-05-31 01:01 dunno. i wouldn't expect it to, but of course, there can always be surprises :) 2014-05-31 01:02 when you read it back immediately after writing, without any other changes to the CPU state, what do you obtain ? 2014-05-31 01:02 is the value changed then or still 0x0...xx ? 2014-05-31 01:04 wpwrak: I can not test right now :( 2014-05-31 01:04 wpwrak: I was thinking this idea (program counter) after I left uni office we the frustration of vtor 2014-05-31 01:04 tests 2014-05-31 01:04 and now I can not test 2014-05-31 01:05 we the= with the 2014-05-31 01:05 so you never checked whether the write succeeded ? 2014-05-31 01:06 there's also this question 2014-05-31 01:06 if you *remove the halt signal* to the core, it will just continue as usual 2014-05-31 01:06 no no.. we did not try the program counter idea. We tried to change vtor but we checked that the write was unsucefull 2014-05-31 01:06 :( 2014-05-31 01:07 if, however, you *reset the core* (and since you appear to want the core to jump to the reset vectory, you probably do), the vtor will be probably reset as well 2014-05-31 01:07 looking as it's a core register 2014-05-31 01:07 there's a rather complicated system of resets in the m-series 2014-05-31 01:07 whitequark: yes, and we are suffering with this complicated system in our little tests with the idea to learn :) 2014-05-31 01:08 it's entirely described in the manual 2014-05-31 01:08 note that if vtor is indeed reset, pc will be reset too. so you need to find a way to run the core rather than resetting it 2014-05-31 01:08 I just do set $pc = ...; set $sp = ...; cont; in gdb 2014-05-31 01:08 as yes, if you change the vtor just to change the reset vector, than that's not likely to work, since resetting the core will also reset vtor :) see also B.1.5.5 (page 438) of http://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARMv7-M_ARM.pdf 2014-05-31 01:16 whitequark: we have a bare metal micro, no profesional boards or things like that, just the mk20 micro from freescale factory, naked. With just the pins of swd and powering and reset. We use UBB from werner to use swd software from the SIE board 2014-05-31 01:16 whitequark: we have some little gdb server in sie board, but it is not complete. All this little monster use the swd software from werner as well 2014-05-31 01:17 with this little incomplete gdb server 2014-05-31 01:17 then we are in reset mode, because if we leaving the reset mode we lose the control etc 2014-05-31 01:18 in reset mode we are learning about the posibilities 2014-05-31 01:18 well... then your only option is to finish the swd-gdb server to make it work properly 2014-05-31 01:18 it is not hard 2014-05-31 01:18 we do not have easy software to flash or build programs (like eclipse, or proper bootloaders, etc) 2014-05-31 01:18 you can use my stlink gdbserver as a template 2014-05-31 01:18 so we have not flashed useful software yet 2014-05-31 01:19 we do not have recovering tools either, etc. All our tests are very fragile and minimal :) 2014-05-31 01:19 whitequark: okey, we are trying yes :) 2014-05-31 01:23 my libswd does have code for flashing .... :) 2014-05-31 01:23 uses a fairly direct approach, without running code on the device 2014-05-31 02:12 Guest7061 has quit [Ping timeout: 264 seconds] 2014-05-31 02:14 Codora has joined #qi-hardware 2014-05-31 02:32 rz2k has joined #qi-hardware 2014-05-31 03:26 atommann has joined #qi-hardware 2014-05-31 03:46 rz2k has quit [*.net *.split] 2014-05-31 03:46 mth has quit [*.net *.split] 2014-05-31 03:46 freespace has quit [*.net *.split] 2014-05-31 03:46 freespace has joined #qi-hardware 2014-05-31 03:46 rz2k has joined #qi-hardware 2014-05-31 03:46 mth has joined #qi-hardware 2014-05-31 03:52 zrafa_ has joined #qi-hardware 2014-05-31 04:00 zrafa has quit [Write error: Broken pipe] 2014-05-31 04:45 BerryHalsak has joined #qi-hardware 2014-05-31 05:59 atommann has quit [Ping timeout: 276 seconds] 2014-05-31 06:11 rz2k has quit [Read error: Connection reset by peer] 2014-05-31 06:32 BerryHalsak has quit [Ping timeout: 252 seconds] 2014-05-31 07:06 xiangfu has joined #qi-hardware 2014-05-31 07:22 xiangfu has quit [Remote host closed the connection] 2014-05-31 07:22 kyak_ is now known as kyak 2014-05-31 07:25 BerryHalsak has joined #qi-hardware 2014-05-31 07:30 rz2k has joined #qi-hardware 2014-05-31 08:21 rz2k has quit [Ping timeout: 240 seconds] 2014-05-31 08:37 rz2k has joined #qi-hardware 2014-05-31 08:48 wolfspraul has joined #qi-hardware 2014-05-31 09:20 michael_lee has joined #qi-hardware 2014-05-31 09:41 kristian1aul has joined #qi-hardware 2014-05-31 09:44 FDCX_ has joined #qi-hardware 2014-05-31 09:44 FDCX has quit [Ping timeout: 265 seconds] 2014-05-31 09:44 kristianpaul has quit [Ping timeout: 265 seconds] 2014-05-31 09:58 for those reading german and likes google more than EUcracy: this looks like a fun idea: www.heise.de/newsticker/foren/S-Durch-Abgleich-mit-google-com-erfaehrt-man-dann-wem-was-peinlich-war/forum-280509/msg-25295826/read/ 2014-05-31 09:58 now, all you need is the domain googlediff.something (e.g., .com is still available), and a bit of code that talks to the search apis ... 2014-05-31 10:09 that could actually prove to be a problem 2014-05-31 10:10 google doesn't like people scraping its results very much. 2014-05-31 10:10 of course, you could just pair it with http://antigate.net ;) 2014-05-31 10:10 er http://antigate.com/ 2014-05-31 10:12 pcercueiS2 has joined #qi-hardware 2014-05-31 10:13 hmm, there's googlefight, duckduckgo, etc. seems that they don't mind overmuch 2014-05-31 10:13 googlefight is rand() in disguise 2014-05-31 10:14 duckduckgo doesn't scrape google, they use bing and their own heuristics (not indexing) 2014-05-31 10:14 duckduckgo rocks 2014-05-31 10:14 it sucks at finding relevant stuff 2014-05-31 10:14 it rocks at providing answers by template, but it is not a good search engine. 2014-05-31 10:14 because well, duh, bing 2014-05-31 10:14 (antigate) now that sounds useful. someone should make a plugin for chromium "solve this annoying captcha for me" ;-) 2014-05-31 10:15 that wouldn't fly most likely 2014-05-31 10:15 oh 2014-05-31 10:15 https://chrome.google.com/webstore/detail/anti-captcha/nconiknmmhhhffhmbknbplalknajiaef?utm_source=chrome-ntp-icon 2014-05-31 10:15 I'm fairly certain google *will* block this if it gets more popular 2014-05-31 10:16 seeing as it's against Google's (other) ToS and they don't really give a fuck anyway 2014-05-31 10:22 ehm, this plugin isn't popular. You are sure that this plugin working well? 2014-05-31 10:24 try it? 2014-05-31 11:04 sb0 has joined #qi-hardware 2014-05-31 11:31 pcercuei has joined #qi-hardware 2014-05-31 11:42 rz2k has quit [] 2014-05-31 11:59 pcercuei_ has joined #qi-hardware 2014-05-31 12:01 pcercuei has quit [Disconnected by services] 2014-05-31 12:02 pcercuei_ is now known as pcercuei 2014-05-31 12:02 pcercueiS2 has quit [Ping timeout: 264 seconds] 2014-05-31 13:18 mth has quit [] 2014-05-31 13:29 rz2k has joined #qi-hardware 2014-05-31 13:36 wpwrak: (google-diff) awesome! not that I had missed to ponder similar stuff when I heard that google.com still provides the links 2014-05-31 14:51 wpwrak: interesting http://wiki.openmoko.org/wiki/Qi .. were you part of it ? 2014-05-31 14:52 according to this http://www.slideshare.net/kanru/android-boot-time-optimization?qid=0d5ae513-a5d0-4012-a32b-c586e6f64e24&v=qf1&b=&from_search=247 (Page 38) Qi-boot takes < 1s while u-boot + Xloader takes > 5s 2014-05-31 14:52 too many things named "qi"... 2014-05-31 14:53 sometimes i mistaken qi to qué :) 2014-05-31 14:59 whitequark: never install a russian chrome plugin :-) 2014-05-31 15:09 nicksydney: iirc wpwrak been father of Qi 2014-05-31 15:09 qi* 2014-05-31 15:11 I might as well be wrong on that one 2014-05-31 15:11 father or grandfather ? 2014-05-31 15:14 oops, http://people.openmoko.org/andy/ 2014-05-31 15:14 dunno then 2014-05-31 15:23 atommann has joined #qi-hardware 2014-05-31 15:25 hmmpf, clicking on git://git.openmoko.org/git/qi.git opens giggle, but it looks rather useless and void to me 2014-05-31 15:29 rz2k has quit [] 2014-05-31 15:37 nicksydney: no, that was the work of Andy Green. just made a few tiny changes to it. 2014-05-31 15:39 and I guess even Andy didn't invent it 2014-05-31 15:39 giggle is pretty useless 2014-05-31 15:40 as far as i recall, he pretty much did. well, we may have talked about such a thing before. i never exactly liked u-boot :) 2014-05-31 15:41 has a "clone data" but that doesn't do anything useful. I really wonder what's the use of the mimetype invoking giggle when clicking on git://git.openmoko.org/git/qi.git 2014-05-31 15:41 ~xyawn 2014-05-31 15:42 ooh 2014-05-31 15:42 anyway hot coffee 2014-05-31 16:05 pcercuei has quit [Quit: bbl] 2014-05-31 16:06 michael_lee has quit [Ping timeout: 240 seconds] 2014-05-31 16:21 michael_lee has joined #qi-hardware 2014-05-31 16:23 seems qi bootloader been named by http://en.wikipedia.org/wiki/Alan_Cox 2014-05-31 16:23 wpwrak: was Alan involved into OM sw development? 2014-05-31 16:27 no, but he had been listening in. could be that he suggested the name. 2014-05-31 16:33 mth has joined #qi-hardware 2014-05-31 16:33 pcercueiS2 has joined #qi-hardware 2014-05-31 16:34 http://git.openmoko.org/?p=qi.git;a=blob;f=README;hb=HEAD 2014-05-31 16:35 familar names on http://git.openmoko.org/?p=qi.git;a=commit;h=HEAD :-) 2014-05-31 16:36 but yeah, initial commits been by Andy obviously 2014-05-31 16:44 BerryHalsak has quit [Ping timeout: 245 seconds] 2014-05-31 16:50 BerryHalsak has joined #qi-hardware 2014-05-31 16:50 BerryHalsak has quit [Remote host closed the connection] 2014-05-31 17:00 atommann has quit [Quit: Leaving] 2014-05-31 17:36 michael_lee has quit [Quit: Ex-Chat] 2014-05-31 22:54 wolfspraul has quit [Quit: leaving] 2014-05-31 23:36 sb0 has quit [Quit: Leaving] 2014-05-31 23:58 Luke-Jr has quit [Remote host closed the connection] 2014-05-31 23:58 Luke-Jr has joined #qi-hardware