Well documented ARM devices for os dev?

[0xHenry]

I'm willing to enhance my ARM assembly skills by creating a simple OS for an ARM device. I've been trying to find a well documented and preferably cheap one but I've had no success. It doesn't need to be the most powerful one but some smarthpone-like features like (touch)screen, camera, bluetooth and similar are a plus so I can learn many things with single device.

So do you know any?

[TylerH]

You could build a device with any peripherals you want. http://www.sparkfun.com/products/520

[0xHenry]

That sounds like a good idea. I could try it but I have pretty much no clue what things should I buy and how to build it.

[JamesM]

Beagleboard.

[JamesM]

You could build a device with any peripherals you want. http://www.sparkfun.com/products/520

I couldn't find what ARM chip that SoC is based on, but as it's a microcontroller it's either going to be a Cortex-M series or one of its predecessors (ARM7TDMI). This won't handle the kind of workload you're expecting - it's not an applications processor.

The IC doesn't also specify its pinout, so doesn't say if it has any standard peripherals on board (such as a UART).

I'd stick with the beagleboard.

[0xHenry]

Beagleboard looks excellent. I should have stuff to experiment for a long time with it.

Thank you guys!

[OSwhatever]

For OS development I recommend using qemu instead in initial stages. Compile-flash-run, compile-flash-run will slow you down rather than just recompile and run on the host computer. Also debugging often requires additional JTAG hardware since I assume you don't have remote debuggning right from the start.

Hardware development boards are great when you're going to adapt the OS for one specific hardware but initial work of an OS doesn't really require the HW.

Just beware of qemu bugs. I've encountered several of them and you often have to adjust the bug yourself since updates are not frequent, especially when it comes to ARM. The benefit of the hardware is that you don't get the emulator bugs. Also when moving from emulator to real HW you will probably encounter caches and TLB problems since that is not emulated accurately enough and very forgiving.

I have a HW as well but I use qemu much more since I don't need to tinker with the hardware all the time. Less things to bring, if you're travelling and so on.

[Firestryke31]

Try the Gameboy Advance. VisualBoyAdvance is a good emulator that gets pretty close to RHW, and there are easily available dev tools, and it's very well documented. There's no other software running so you don't have to worry about that getting in your way. Once you're confident that the version running in the emulator is doing good you can invest in a flash cart and run it on RHW too.

[JackScott]

While the Gameboy Advance is easy to develop for and lots of fun to play around with, it has a couple of problems too. Firstly, it's not built with hobbyists in mind. You may piss Nintendo off, depending on what you intend to do. More importantly though, the GBA isn't a general-purpose platform. It's only got a 160x120 screen (which isn't expandable), 8 or so input keys (also not expandable), no networking to speak of, and has no memory management facilities (or if it does, they're very crude). So there's probably better choices... like the Beagleboard, as previously mentioned.

[Firestryke31]

While the Gameboy Advance is easy to develop for and lots of fun to play around with, it has a couple of problems too. Firstly, it's not built with hobbyists in mind. You may piss Nintendo off, depending on what you intend to do. More importantly though, the GBA isn't a general-purpose platform. It's only got a 160x120 screen (which isn't expandable), 8 or so input keys (also not expandable), no networking to speak of, and has no memory management facilities (or if it does, they're very crude). So there's probably better choices... like the Beagleboard, as previously mentioned.

He did say it was more for learning ARM ASM, and due to working so closely with hardware it can be easier. It certainly meets the cheap and well documented aspects.

The nice thing about the GBA is that the hardware is very consistent, so you know if something doesn't work it's most likely your fault. The GBA is also nice in that it's pretty easy to get visible results right away. The highly constrained environment is also good for teaching those super-optimization tricks, like mixing 16 channels of audio basically in real time while still leaving CPU time over for game logic (MOD file playing).

As long as you don't try and sell it or use it for running Nintendo software you should be fine with Nintendo.

[xyzzy]

For OS development I recommend using qemu instead in initial stages. Compile-flash-run, compile-flash-run will slow you down rather than just recompile and run on the host computer. Also debugging often requires additional JTAG hardware since I assume you don't have remote debuggning right from the start.

I believe you can boot a kernel image over a serial connection on the BeagleBoard, rather than having to reflash every time you want to run a new build. It's probably still more convenient to use QEMU though. MeeGo has a version of QEMU that can emulate the BeagleBoard here, which I'm using at the moment to port my OS to.

[gravaera]

Yo:

For the GBA jailbreaking endeavour you can maximize on the available buttons by having input done by an on-screen keyboard, and other things like use the d-pad as a mouse, etc: given a kernel that doesn't assume a PMMU, you can do quite a lot with the GBA, and even more for the Nintendo DS, which is even more fun, since it has WiFi and a touchscreen.

And there's abundant documentation for both platforms: lots of fun

--Cool topic
gravaera

[FlashBurn]

MeeGo has a version of QEMU that can emulate the BeagleBoard here, which I'm using at the moment to port my OS to.

Maybe you could make a Wiki entry for compiling this QEMU version and how to start programming for it and so on

I wanted to use this version, but as of now I haven´t found the time to do so