ARM Assembly

[kneehighspy]

anyone have any good locations for device bios / rom memory maps for the ARM / Pandora? (used bing and yahoo to no avail, don't use google anymore since turkey turmoil tie-in to google coo). i'm an old assembly programmer for the 6502, 65C02, 6510 and motorolla 68k series of processors (apple ][x, C64 and Amiga 1000, 3000) and wanting to get into some assembly on the Pandora. don't have any good ide or assembler yet, just getting started. have ordered several ARM assembly manuals, need some good device i/o / memory maps.

 

[sswam]

I'm interested but don't have the goods. Bump!

 

[Exophase]

You can read the memory map in the OMAP3 documentation, but you shouldn't need to go anywhere near it just to do assembly. In fact, the OS and MMU will do a lot to get in your way first. Just glue your ASM with some C or whatever, to access some library calls.. or if you must keep it all ASM you can access those libraries or OS syscalls straight from it.

 

[kneehighspy]

You can read the memory map in the OMAP3 documentation, but you shouldn't need to go anywhere near it just to do assembly. In fact, the OS and MMU will do a lot to get in your way first. Just glue your ASM with some C or whatever, to access some library calls.. or if you must keep it all ASM you can access those libraries or OS syscalls straight from it.

thanks Exophase for the info. honestly i'd rather keep everything in assembly. i ordered a couple of hundred dollars worth of ARM assembly programming manuals, same way i started with the other processors...much older now though

 

[Exophase]

thanks Exophase for the info. honestly i'd rather keep everything in assembly. i ordered a couple of hundred dollars worth of ARM assembly programming manuals, same way i started with the other processors...much older now though

Like I said, you can keep all of it in assembly and stick with accessing pre-compiled libraries and OS syscalls. If you do interface libraries that were written in C or meant to be C compatible you won't have a hard time calling functions, but you could have some difficulty accessing struct fields. You may need to write some C code just to find where the compiler put things.


Since you mentioned information on BIOS I imagine you're at least open to interfacing an OS. The syscall interface is pretty clean/abstracted and you can use it to access files. On Pandora the interface is ARM Linux EABI. Here's an example of how to use syscalls in it:


http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3105/4


I couldn't find a syscall list for ARM Linux, but the one for i386 should be similar:


http://asm.sourceforge.net/syscall.html#p31


Using the file interface on device nodes you can gain access to simple interfaces for framebuffer video, direct audio, and input. Framebuffer can be accessed with standard Linux devfb, audio can be accessed through an emulated OSS node, and input has some devices specific to Pandora. You can read about these things here:


http://pandorawiki.org/Kernel_interface


You should mainly be able to do all of the accesses through the open, read, write, ioctl, and mmap syscalls, all easily accessible in ASM.


But just so this is clear, I strongly recommend not trying to program the hardware directly on Pandora. I think you'll find that it's very different from machines from 30 years ago. The technical reference manual is 3458 pages long, and it doesn't even contain information on some peripherals. Even if you managed to punt the OS and write enough to the metal to get a useful application done you'd still miss the luxury of having a program loader and a nice way to get files directly onto the unit. That is, unless you coded up all of that too.. have fun trying to redo wifi drivers and a TCP/IP stack for instance. You'd also end up with a much less portable program (even ARM ASM targeting Linux can work on several devices, with the input abstracted anyway)


If you do want to access hardware entirely yourself on an ARM platform I recommend something like GBA/DS or a board containing a Cortex-M3 or similar. These devices have much simpler peripheral interfaces and are more the embedded type that do okay with simple or no OS.

 

[chris_r]

If you want to learn ARM assembly I think you may be better off buying a dev board with a Cortex m3 or similar microcontroller where there's no OS to get in the way of access to the peripherals.

 

[Exophase]

If you want to learn ARM assembly I think you may be better off buying a dev board with a Cortex m3 or similar microcontroller where there's no OS to get in the way of access to the peripherals.

People use ARM assembly with Linux/other big OSes all the time. IMO it's having to access peripherals directly which gets in the way of learning an assembly language, not the other way around. That is, if the high level interfaces you use instead are reasonably simple.

 

[kneehighspy]

thanks Exophase for the info. honestly i'd rather keep everything in assembly. i ordered a couple of hundred dollars worth of ARM assembly programming manuals, same way i started with the other processors...much older now though

Like I said, you can keep all of it in assembly and stick with accessing pre-compiled libraries and OS syscalls. If you do interface libraries that were written in C or meant to be C compatible you won't have a hard time calling functions, but you could have some difficulty accessing struct fields. You may need to write some C code just to find where the compiler put things.


Since you mentioned information on BIOS I imagine you're at least open to interfacing an OS. The syscall interface is pretty clean/abstracted and you can use it to access files. On Pandora the interface is ARM Linux EABI. Here's an example of how to use syscalls in it:


http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3105/4


I couldn't find a syscall list for ARM Linux, but the one for i386 should be similar:


http://asm.sourceforge.net/syscall.html#p31


Using the file interface on device nodes you can gain access to simple interfaces for framebuffer video, direct audio, and input. Framebuffer can be accessed with standard Linux devfb, audio can be accessed through an emulated OSS node, and input has some devices specific to Pandora. You can read about these things here:


http://pandorawiki.org/Kernel_interface


You should mainly be able to do all of the accesses through the open, read, write, ioctl, and mmap syscalls, all easily accessible in ASM.


But just so this is clear, I strongly recommend not trying to program the hardware directly on Pandora. I think you'll find that it's very different from machines from 30 years ago. The technical reference manual is 3458 pages long, and it doesn't even contain information on some peripherals. Even if you managed to punt the OS and write enough to the metal to get a useful application done you'd still miss the luxury of having a program loader and a nice way to get files directly onto the unit. That is, unless you coded up all of that too.. have fun trying to redo wifi drivers and a TCP/IP stack for instance. You'd also end up with a much less portable program (even ARM ASM targeting Linux can work on several devices, with the input abstracted anyway)


If you do want to access hardware entirely yourself on an ARM platform I recommend something like GBA/DS or a board containing a Cortex-M3 or similar. These devices have much simpler peripheral interfaces and are more the embedded type that do okay with simple or no OS.

awesome info Exophase, very helpful indeed. i agree with the hardware being different from hardware from 30 years ago, trying out a devkit from keil and also arm ds-5. really appreciate your info though, got me in the right directions, your knowledge is well shown . one thing is sure though, old age only comes with getting older.