Writing OS for something with an ARM processor

[DavidCooper]

I'd like to port my OS to run on something with an ARM processor in it, either real or virtual, but it looks as if it would be very easy to pick the wrong one and end up wasting months just trying to work out how to boot the thing. Qemu may be the best option, not least for cost reasons, but there's a worrying lack of people here posting so much as their bootsector code for anything using ARM, leading me to wonder if there is sufficient comprehensible documentation available to make this anything other than a nightmare task. I haven't yet managed to find any kind of tutorial going through the essentials of what's needed in a boot sector or how to access the screen and keyboard, so if anyone knows of one, please point me towards it. Ideally I'd like to be able to boot the thing from a floppy disk/image if that's an option, but that isn't essential. All options would be of interest, particularly if you've found an easy way in.

(If you reply, accompanying insults will be very welcome.)

[MasterLee]

Some days ago i stumpled upon over an special omap3 qemu module. That way you could emulate beagle board.

You can find the homepage of Das U-Boot under: http://www.denx.de/wiki/U-Boot

[OSwhatever]

Just use qemu. Find the start address where the qemu starts (different depending whic board you choose) and go from there. With an ARM board you don't need to hassle with boot sectors, ACPI, BIOS and things like that. Qemu has a way of loading a binary or and .elf file directly to the memory which enables you to start quickly with your OS development.

[DavidCooper]

Thanks for the replies. I've followed all your links and read through as much as possible to get an overview of what's what. The link to the ARM Integrator-CP Bare Bones page of the OS-Dev Wiki shows how to boot that board and send a message out through the serial port (which isn't something I want to do), but there's a link to the manual at the bottom, and that manual spells out the keyboard, mouse and screen addresses and gives sufficient information about them that I think I may be able to do this. If anyone's written a really simple "OS" for this already which does nothing more than take keyboard input and write to the screen, I'd certainly like to see it, but I don't want to copy it and would prefer to have a go first to see if I can manage on my own.

It looks as if I'll need to write a device driver for reading and writing to SD cards, but again there appears to be sufficient information there to make that possible (it tells you which manual is required - http://infocenter.arm.com/help/topic/co ... DI0172.pdf), but to begin with I can just bundle everything into a single binary file and rearrange my modules in memory once there - I won't initially want to save anything as my main goal is going to be to test code which has been translated from x86 to ARM within my existing OS (a process which I want to automate as much as possible, and having studied the ARM instruction set it looks as if a lot of automation can be done). I'm hoping all I have to do to get going is find out what address Qemu will load the kernel at, design my code to start running at that address, save it to floppy disk as a .bin file, copy that file onto an SD card and then see if I can get Qemu to boot it. I'll let you know how I get on...

I also like the idea of working with BeagleBoard, but I can't see any information on how you get at the keyboard input - do you need to write your own USB driver or is the input converted into something accessible through memory-mapped ports? It appears that the typical user is expected to be using Linux or some other advanced OS on it rather than developing a new one from scratch. I didn't notice anything explaining where to find the screen memory either, but I'm sure that can't be too hard to work with. Even so, I'm going to focus on the Qemu-Integrator-CP route for now.

[xyzzy]

Some days ago i stumpled upon over an special omap3 qemu module. That way you could emulate beagle board.

You can find the homepage of Das U-Boot under: http://www.denx.de/wiki/U-Boot

As far as I'm aware that is a fairly out of date now. Linaro maintain their own branch of QEMU, which includes more up to date OMAP3/BeagleBoard emulation.

[guyfawkes]

I have written a very basic arm OS, using FasmArm and the friendly arm dev board.
I may dig it out if you want, also any ? just ask.
http://www.friendlyarm.net/products/mini2440

[OSwhatever]

I have written a very basic arm OS, using FasmArm and the friendly arm dev board.
I may dig it out if you want, also any ? just ask.
http://www.friendlyarm.net/products/mini2440

If you start today, I'd say you should go for ARMv7 or newer. ARM is phasing out old ARM9 (ARMv5 something). It acutally depends on what OS you're creating but an OS with full MMU support is cumbersome with ARM9 and the CPU has bad support for multiple address spaces. ARM realized this drawback and changed the virtual memory architecture in ARM11 (ARMv6) so that multiple address spaces could be supported in a convienient way.

If you read Symbian Internals, it tells you a little bit about Symbian before and after when ARM changed the memory architecture. The ARM9 Symbian version was not multiple address space at all. It just flipped the access rights of the memory region at a task switch, the app was still mapped at its position though. I guess it was using the hardware supported task switching. Multiple address space can be done with ARM9, but it's not nice.

[DavidCooper]

I have written a very basic arm OS, using FasmArm and the friendly arm dev board.
I may dig it out if you want, also any ? just ask.
http://www.friendlyarm.net/products/mini2440

Thanks. I'm going to have to restrict myself to Qemu's Integrator-CP for now, but I can see that all these boards have real potential for doing fun things in robotics, so I'm not going to rule anything out for the future.

[Laksen]

Beagleboard has no "screen memory" - you need to map powervr frame buffer somewhere and use that. It's a fairly complicated topic and I would stick to serial port output for a start.

This is incorrect. There's no publicly available documentation for the PowerVR available, but there is information readily available for the Display Subsystem which is essentially a basic framebuffer device.

It is still somewhat complicated to set up of course, but it is documented

[Owen]

Any reference to PowerVR. It is completely independent.

[Jezze]

I'm sorry if I'm stealing this thread a bit but I have tried getting my OS ported to ARM using the arm barebones tutorial found here.

http://wiki.osdev.org/ARM_Integrator-CP_Bare_Bones

There is something I haven't figured out. You see as soon as you start using division the compiling fails with missing calls to something called __udivsi3 which is supposed to be some compiler defined definitions for division. Could anyone add that to the arm bones article who know why this happens and what to do about it?