DocScrutinizer05 changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
zrafa has joined #qi-hardware
<zrafa> hey hey
<zrafa> where are the arm cortex-m hackers here? :)
<zrafa> 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
<zrafa> some code in ram, could we change register 15 (program counter) then leave from reset to try to jump to our code in ram?
<zrafa> the mk20 is an arm cortex-m4
<whitequark> zrafa: I did that with m3
<whitequark> well
<whitequark> define "reset mode" more precisely
<wpwrak> i guess SWD mode entered after reset, with the core being debugged
<wpwrak> and yes, i think that should work
<whitequark> yes, then I did exactly that
<wpwrak> though, why would you do it like this ? just run your fw from reset, that is unless you plan to use a debugger
<whitequark> zrafa: setting the PC would work as you expect
<whitequark> PC isn't that special in ARMs.
<zrafa> wpwrak: we have a little gdb server in SIE board, with ubb to have SWD with mk20
<zrafa> 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
<zrafa> whitequark: cool ! :) (setting the program counter)
<zrafa> whitequark: I will try then :)
<zrafa> 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
<zrafa> )
<zrafa> wpwrak: ^
<wpwrak> 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
<whitequark> zrafa: VTOR?
<whitequark> the vector table, right?
<wpwrak> 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 :)
<whitequark> or you can flash it via the debugger just as well.
<whitequark> see how texane/stlink does it
<whitequark> then upload it to an arbitrary position in RAM together with the bytes to flash, and jump to it
<whitequark> gdb can instruct the gdbserver to do that, too.
<zrafa> whitequark: yeaht, the vector table
<zrafa> yes, we can write on flash as well, but we want to play with our experiments just to learn
<whitequark> not sure why VTOR won't change, that sounds weird
<zrafa> wpwrak: no just to flash something and then forgot what all this swd is about :)
<wpwrak> i suppose you tried the mechanism you use to change the VTOR already on, say, a port register to toggle a LED and such ?
<zrafa> whitequark: we were thinking that we could not chang vtor because in reset mode
<zrafa> wpwrak: led okey yes
<zrafa> :)
<wpwrak> and at what address is VTOR ?
<whitequark> 0xE000ED08
<zrafa> 0xE000ED08 VTOR RW Privileged 0x00000000 Vector Table Offset Register
<zrafa> :)
<whitequark> vtor shouldn't behave like that
<whitequark> but I'm too lazy to pull out my stm boards
<zrafa> 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
<wpwrak> hmm, if you two agree, then i won't bother with checking ;-)
<zrafa> 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
<zrafa> vtor then after read it again it showed us 0x00000000 :(
<whitequark> zrafa: what have you changed it to?
<whitequark> what's the CPSR value (are you in privileged mode?)
<whitequark> (you should be)
<zrafa> whitequark: we tried to put in vtor some valid RAM address
<whitequark> it needs to be properly aligned
<whitequark> 0x20000000 should work fine
<zrafa> 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 ?
<zrafa> whitequark: yes, we did
<zrafa> (aligned)
<wpwrak> zrafa: what value did you try ?
<zrafa> wpwrak: let me check the logs
<zrafa> 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)
<zrafa> wpwrak: ^
<zrafa> 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 ?
<wpwrak> (ram address) as in 0x2000xxxx ? (i.e., SRAM_U, not SRAM_L)
<wpwrak> dunno. i wouldn't expect it to, but of course, there can always be surprises :)
<wpwrak> when you read it back immediately after writing, without any other changes to the CPU state, what do you obtain ?
<wpwrak> is the value changed then or still 0x0...xx ?
<zrafa> wpwrak: I can not test right now :(
<zrafa> wpwrak: I was thinking this idea (program counter) after I left uni office we the frustration of vtor
<zrafa> tests
<zrafa> and now I can not test
<zrafa> we the= with the
<wpwrak> so you never checked whether the write succeeded ?
<whitequark> there's also this question
<whitequark> if you *remove the halt signal* to the core, it will just continue as usual
<zrafa> no no.. we did not try the program counter idea. We tried to change vtor but we checked that the write was unsucefull
<zrafa> :(
<whitequark> 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
<whitequark> looking as it's a core register
<whitequark> there's a rather complicated system of resets in the m-series
<zrafa> whitequark: yes, and we are suffering with this complicated system in our little tests with the idea to learn :)
<whitequark> it's entirely described in the manual
<whitequark> 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
<whitequark> I just do set $pc = ...; set $sp = ...; cont; in gdb
<wpwrak> 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
<zrafa> 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
<zrafa> 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
<zrafa> with this little incomplete gdb server
<zrafa> then we are in reset mode, because if we leaving the reset mode we lose the control etc
<zrafa> in reset mode we are learning about the posibilities
<whitequark> well... then your only option is to finish the swd-gdb server to make it work properly
<whitequark> it is not hard
<zrafa> we do not have easy software to flash or build programs (like eclipse, or proper bootloaders, etc)
<whitequark> you can use my stlink gdbserver as a template
<zrafa> so we have not flashed useful software yet
<zrafa> we do not have recovering tools either, etc. All our tests are very fragile and minimal :)
<zrafa> whitequark: okey, we are trying yes :)
<wpwrak> my libswd does have code for flashing .... :)
<wpwrak> uses a fairly direct approach, without running code on the device
Guest7061 has quit [Ping timeout: 264 seconds]
Codora has joined #qi-hardware
rz2k has joined #qi-hardware
atommann has joined #qi-hardware
rz2k has quit [*.net *.split]
mth has quit [*.net *.split]
freespace has quit [*.net *.split]
freespace has joined #qi-hardware
rz2k has joined #qi-hardware
mth has joined #qi-hardware
zrafa_ has joined #qi-hardware
zrafa has quit [Write error: Broken pipe]
BerryHalsak has joined #qi-hardware
atommann has quit [Ping timeout: 276 seconds]
rz2k has quit [Read error: Connection reset by peer]
BerryHalsak has quit [Ping timeout: 252 seconds]
xiangfu has joined #qi-hardware
xiangfu has quit [Remote host closed the connection]
kyak_ is now known as kyak
BerryHalsak has joined #qi-hardware
rz2k has joined #qi-hardware
rz2k has quit [Ping timeout: 240 seconds]
rz2k has joined #qi-hardware
wolfspraul has joined #qi-hardware
michael_lee has joined #qi-hardware
kristian1aul has joined #qi-hardware
FDCX_ has joined #qi-hardware
FDCX has quit [Ping timeout: 265 seconds]
kristianpaul has quit [Ping timeout: 265 seconds]
<wpwrak> 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/
<wpwrak> 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 ...
<whitequark> that could actually prove to be a problem
<whitequark> google doesn't like people scraping its results very much.
<whitequark> of course, you could just pair it with http://antigate.net ;)
<whitequark> er http://antigate.com/
pcercueiS2 has joined #qi-hardware
<wpwrak> hmm, there's googlefight, duckduckgo, etc. seems that they don't mind overmuch
<whitequark> googlefight is rand() in disguise
<whitequark> duckduckgo doesn't scrape google, they use bing and their own heuristics (not indexing)
<eintopf> duckduckgo rocks
<whitequark> it sucks at finding relevant stuff
<whitequark> it rocks at providing answers by template, but it is not a good search engine.
<whitequark> because well, duh, bing
<wpwrak> (antigate) now that sounds useful. someone should make a plugin for chromium "solve this annoying captcha for me" ;-)
<whitequark> that wouldn't fly most likely
<whitequark> oh
<whitequark> I'm fairly certain google *will* block this if it gets more popular
<whitequark> seeing as it's against Google's (other) ToS and they don't really give a fuck anyway
<eintopf> ehm, this plugin isn't popular. You are sure that this plugin working well?
<whitequark> try it?
sb0 has joined #qi-hardware
pcercuei has joined #qi-hardware
rz2k has quit []
pcercuei_ has joined #qi-hardware
pcercuei has quit [Disconnected by services]
pcercuei_ is now known as pcercuei
pcercueiS2 has quit [Ping timeout: 264 seconds]
mth has quit []
rz2k has joined #qi-hardware
<DocScrutinizer05> wpwrak: (google-diff) awesome! not that I had missed to ponder similar stuff when I heard that google.com still provides the links
<nicksydney> wpwrak: interesting http://wiki.openmoko.org/wiki/Qi .. were you part of it ?
<nicksydney> 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
<whitequark> too many things named "qi"...
<nicksydney> sometimes i mistaken qi to qué :)
<eintopf> whitequark: never install a russian chrome plugin :-)
<DocScrutinizer05> nicksydney: iirc wpwrak been father of Qi
<DocScrutinizer05> qi*
<DocScrutinizer05> I might as well be wrong on that one
<nicksydney> father or grandfather ?
<DocScrutinizer05> oops, http://people.openmoko.org/andy/
<DocScrutinizer05> dunno then
atommann has joined #qi-hardware
<DocScrutinizer05> hmmpf, clicking on git://git.openmoko.org/git/qi.git opens giggle, but it looks rather useless and void to me
rz2k has quit []
<wpwrak> nicksydney: no, that was the work of Andy Green. just made a few tiny changes to it.
<DocScrutinizer05> and I guess even Andy didn't invent it
<DocScrutinizer05> giggle is pretty useless
<wpwrak> 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 :)
<DocScrutinizer05> 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
<DocScrutinizer05> ~xyawn
<DocScrutinizer05> ooh
<DocScrutinizer05> anyway hot coffee
pcercuei has quit [Quit: bbl]
michael_lee has quit [Ping timeout: 240 seconds]
michael_lee has joined #qi-hardware
<DocScrutinizer05> seems qi bootloader been named by http://en.wikipedia.org/wiki/Alan_Cox
<DocScrutinizer05> wpwrak: was Alan involved into OM sw development?
<wpwrak> no, but he had been listening in. could be that he suggested the name.
mth has joined #qi-hardware
pcercueiS2 has joined #qi-hardware
<DocScrutinizer05> familar names on http://git.openmoko.org/?p=qi.git;a=commit;h=HEAD :-)
<DocScrutinizer05> but yeah, initial commits been by Andy obviously
BerryHalsak has quit [Ping timeout: 245 seconds]
BerryHalsak has joined #qi-hardware
BerryHalsak has quit [Remote host closed the connection]
atommann has quit [Quit: Leaving]
michael_lee has quit [Quit: Ex-Chat]
wolfspraul has quit [Quit: leaving]
sb0 has quit [Quit: Leaving]
Luke-Jr has quit [Remote host closed the connection]
Luke-Jr has joined #qi-hardware