I'm working on a project using an ARM7 cpu (no, it's not another gameboy emu, lol), and the 1st instruction doesn't make sense to me..
MOV R6,R0

Why set the value of 1 cpu register to another? So I read the datasheet and it says this peculiar statement:

"Except for the program counter the ARM7TDMI registers do not have defined reset states."

So what value is in the registers then? Garbage? OR is it the LAST value from the last time the cpu was powered on? I didn't think cpu registers could do this?

It's quite strange, that the 1st 3 lines of code executed are:
MOV R6,R0
MOV R7,R1
MOV R8,R2

I mean, if those values are undefined at reset, how can you want to store them to other registers?

The only thing to me that makes any sense would be that the cpu register values are somehow retained from last powerup, and this codeblock is just storing that information.. Even still, why bother?

Anyone can help explain this or have thoughts on this strangeness?

Thanks-

PS - I'm sure more ARM7 questions to follow.. :)

That startup doesn't make any sense. If the entry point is correct, it seems like you are disassembling wrong data.

Are you starting in ARM or in Thumb mode? the processor always start in ARM mode.
Also you must be careful with the endianness of the read values.

> I'm working on a project using an ARM7 cpu (no, it's not another gameboy emu,
> lol), and the 1st instruction doesn't make sense to me..
> MOV R6,R0
>
> Why set the value of 1 cpu register to another? So I read the datasheet and it
> says this peculiar statement:
>
> "Except for the program counter the ARM7TDMI registers do not have defined reset
> states."
>
> So what value is in the registers then? Garbage? OR is it the LAST value from
> the last time the cpu was powered on? I didn't think cpu registers could do
> this?
>
> It's quite strange, that the 1st 3 lines of code executed are:
> MOV R6,R0
> MOV R7,R1
> MOV R8,R2
>
> I mean, if those values are undefined at reset, how can you want to store them
> to other registers?
>
> The only thing to me that makes any sense would be that the cpu register values
> are somehow retained from last powerup, and this codeblock is just storing that
> information.. Even still, why bother?
>
> Anyone can help explain this or have thoughts on this strangeness?
>
> Thanks-
>
> PS - I'm sure more ARM7 questions to follow.. :)
>

I couldn't agree with you more.. The start up makes no sense..

Yes, I'm starting in Arm mode, as I haven't
emulated Thumb mode yet and am hoping this project doesn't use it.

FYI - the mov instructions aren't the reset code.. The very first code block found at address 0 is an LDR R15 command which as would be expected jumps the PC into code addressed past the exception vector table. It is at this first code block that the MOV commands are found. Normally I would have suspected that the emulated cpu might be miscalculating the jump, but using IDAPRO along with MAME's (limited but functional for this purpose ARM2/3 emulation) confirms that the jump is correct.

Just for kicks, I indeed had tried to reverse the endianess and the reset vector code @ address 0 made no sense at all.

The rest of the executing code in most places seems to make some sense as I can see the cpu copying expection vectors from the boot up rom into the cpu's ram before the code tells the AT91 cpu to shift ram into page 0.

Just thought the whole thing was kind of weird, but I assume that the code is otherwise operating properly, at least as far as I have traced it.

> That startup doesn't make any sense. If the entry point is correct, it seems
> like you are disassembling wrong data.
>
> Are you starting in ARM or in Thumb mode? the processor always start in ARM
> mode.
> Also you must be careful with the endianness of the read values.

Ok - I'm pretty sure I solved this mystery now..

The cpu is an Atmel AT91 series which has internal ram mapped in memory ~0x300000 at boot.. The code can then write to an internal register to re-map the ram to Page 0. I watched the code, and it does just this, eventually executing code back from address 0 (which is now executing from ram)...

On the 2nd time round now, the MOV commands make sense, as R0-R3 were populated prior to the RAM remapping, so the code in this 2nd time through is now saving those registers.

At least, that's my theory.. :)

Dumb suggestion - I know nothing about ARM, but I know that the x86 bootstrap code that exists in some disk boot sectors, has "do nothing" code in it, but it serves as a binary byte signature, when read as data.

Could the code sequence that you are describing, possibility serve in the same manner? Just a thought.


Edit: I just learned something the other day - many of those so-called "USB flash drive" devices, use something called "DiskOnKey", which was apparently developed by a company called "M-Systems". Anyways, the newest DOK2.0 devices, the so-called "T4" ones, use an ARM7-based 32-bit CPU on them! In those tiny little packages. Hard to believe that those USB flash drives have nearly the equivalent power as a GBC in them. (Too bad there's no video-output. :P)

Anyways, does your project have anything to do with ARM7-based DOK devices at all? Just curious, after learning about this. I own one of these (a PNY 512MB USB2.0 model), and was wondering what you could do with one of these things, if you could run your own assembly code on them.

That's interesting, I can't imagine how they can make it so small.. The arm7 cpu on my project is for a pinball machine sound board, so there's no DOK on it.

> Dumb suggestion - I know nothing about ARM, but I know that the x86 bootstrap
> code that exists in some disk boot sectors, has "do nothing" code in it, but it
> serves as a binary byte signature, when read as data.
>
> Could the code sequence that you are describing, possibility serve in the same
> manner? Just a thought.
>
>
> Edit: I just learned something the other day - many of those so-called "USB
> flash drive" devices, use something called "DiskOnKey", which was apparently
> developed by a company called "M-Systems". Anyways, the newest DOK2.0 devices,
> the so-called "T4" ones, use an ARM7-based 32-bit CPU on them! In those tiny
> little packages. Hard to believe that those USB flash drives have nearly the
> equivalent power as a GBC in them. (Too bad there's no video-output. :P)
>
> Anyways, does your project have anything to do with ARM7-based DOK devices at
> all? Just curious, after learning about this. I own one of these (a PNY 512MB
> USB2.0 model), and was wondering what you could do with one of these things, if
> you could run your own assembly code on them.
>

> Edit: I just learned something the other day - many of those so-called "USB
> flash drive" devices, use something called "DiskOnKey", which was apparently
> developed by a company called "M-Systems". Anyways, the newest DOK2.0 devices,

Yup. They make an IDE version also, which is popular for embedded Linux applications.

I forgot to mention, there are flavors of arm7 that have embedded rom in the cpu, and I would have to guess to save on size these usb devices to the same, so i'd say the odds of programming into that cpu are pretty low..

> Dumb suggestion - I know nothing about ARM, but I know that the x86 bootstrap
> code that exists in some disk boot sectors, has "do nothing" code in it, but it
> serves as a binary byte signature, when read as data.
>
> Could the code sequence that you are describing, possibility serve in the same
> manner? Just a thought.
>
>
> Edit: I just learned something the other day - many of those so-called "USB
> flash drive" devices, use something called "DiskOnKey", which was apparently
> developed by a company called "M-Systems". Anyways, the newest DOK2.0 devices,
> the so-called "T4" ones, use an ARM7-based 32-bit CPU on them! In those tiny
> little packages. Hard to believe that those USB flash drives have nearly the
> equivalent power as a GBC in them. (Too bad there's no video-output. :P)
>
> Anyways, does your project have anything to do with ARM7-based DOK devices at
> all? Just curious, after learning about this. I own one of these (a PNY 512MB
> USB2.0 model), and was wondering what you could do with one of these things, if
> you could run your own assembly code on them.
>

> I forgot to mention, there are flavors of arm7 that have embedded rom in the
> cpu, and I would have to guess to save on size these usb devices to the same, so
> i'd say the odds of programming into that cpu are pretty low..

Actually, M-Systems has some apps that you can apparently download and somehow install onto those devices. The reason that they have such (relatively) powerful CPUs, is to do realtime encryption on the data stored, among other things. I've seem MP3 add-ons for some of those USB flash drives, and now I have to wonder - I wonder if it's just a powered amplifier and headphone jack, and the CPU on the USB flash drive is actually doing the sample mixing/decoding, etc. Maybe not though, I'm sure that some company sells an integrated MP3 decoder and DAC all in one chip package by now.