<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
<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>
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
<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]
<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