OSDev.org

Hi,

I am very interested in extending Bochs emulation engine to support emulation of ARM system.
But this is just a beginning.
I have all necessary docs but it will take very long time without any support.

- Is anybody would like to participate in the project ?
Explaining/understanding of ARM architecture and ISA extensions + coding in Bochs.

- Is anybody have lightweight ARM OS running on the real ARM / QEMU which could be used as testing platform on the first stages ?
Especially great if your OS doesn't require any special hardware which is currently not emulated in Bochs.

- Writing/porting from QEMU any required device models for ARM platform.

- More ? Any help is appreciated.

Stanislav

AFAIR, Bochs's main feature is accuracy of simulation while still keeping reasonable speed. So it's too tied to x86 and ARM simulator would be a completely new project, wouldn't it? What would it share with Bochs?

Then there's a second problem: ARM is just an ISA (with a lot of optional extensions from both ARM corporation and independent hardware vendors) and to define a platform one have to specify:
- core ISA version
- available extensions
- available on-chip peripherals and their addresses
- available external devices (no standard way to get system information similar to BIOS services! UEFI and DeviceTree are moving in this direction but they are both far from universal standard)
- boot ROM position and contents
- ...

Currently I can speak about the following ARM emulators: SkyEye, QEmu and, possibly, uARM. What's the need for another one?
Please, don't get me wrong, I appreciate x86 Bochs very much and I'm eager to support this project but I need to get some reasons to spend time on another ARM emulator instead of improving those that I already use. Of course I can offer some pieces of lightweight code (that I'm developing for real hardware and sometimes test in QEmu) that can be used for testing, although I'm not sure whether you are planning to support such or even just similar platforms:
- Integrator-CP
- EDB9302
- HP h2200
- RPi v1
- STM32F107/407 + external PHY and several display controllers connected via FSMC bus

As already said Bochs only emulates an IBM-PC compatible system.
There are already some projects for ARM based PCs.
For example RPCEmu:
http://www.marutan.net/rpcemu/
The other are emulators that emulate specific ARM systems, like visualboyadvance.
Also MAME emulates some ARM (and x86) Arcade Machines.

That's quite an ambitious projects - I like the idea. The main reason why I like it is that Bochs is a great tool for (x86) operating system developers, since it can easily be configured, is accurate and has lots of logging and debugging features, a lot more than QEMU, for example. So I would really appreciate having a similar tool for ARM.

I guess the main difficulty has already been mentioned: there are lots of very different platforms implementing the ARM architecture, in contrast to the "standard IBM PC" with x86 CPU. So at first one should probably try to implement a rather simple one, but make sure to keep things somehow modular, so that one can easily implement other platforms.

I would be happy to see this project going and jump in and provide some support if I see where it fits.

Hi,

As far as I know; ARM servers are mostly going to be the same "PC compatible" hardware (including PCI-E, UEFI and ACPI), just with a different CPU (ARM rather than 80x86).

Bochs developers could do the same - e.g. create a "mostly PC compatible hardware with ARM instead of 80x86 CPU" system and recycle all of the existing (video, disk, network, USB) device emulation code.


Cheers,

Brendan

Thanks, Brendan,

This is most that I expected. To create mainly "PC compatible hardware with ARM instead of 80x86 CPU", in addition it is of course possible to add some commonly used ARM-specific hardware. But certainly I would like to be able to re-use all the hard-disk, video, network, usb and etc stuff.

The reason I want to start the project is the same reason why you doing OS development.
It is great tool to learn an ARM platform and analyze it.
I also would like to introduce Bochs' instrumentation capabilities to ARM because I find it very useful in research work I do.

But I am newbie here. I have no idea how ARM platform works. And I don't want to start from heaviest Linux like system to emulate, if possible I would like to start from home-written OS done by one of you. And, of course, if someone wish to join the project - I welcome everybody.
I don't plan to fork from Bochs, it is expected to reuse the same infrastructure in GUI, devices and etc so I only planned to replace CPU to ARM in the first stage.

Stanislav

To be honest, having to write a longish configuration file including things like manually calculating mandatory geometry options for the hard disk is exactly what drove me to qemu back in the day. There, "qemu hd.img" was enough and it just worked. So if someone is looking for something to improve user friendliness in Bochs, an easier configuration would be a start. (Or has this already changed? Haven't used Bochs in a while; meanwhile, with a larger OS, it's simply too slow.)


Yes, that's definitely the strength of Bochs.


Maybe kvm-unit-tests would be worth a look for this purpose? It's essentially a collection of test kernels. It doesn't seem to have too much for ARM yet, but for the basics that might just be what you're looking for.

That sounds most reasonable to me as well. So I guess what one would need to implement would be something like an ARM core (and there are quite a lot of them) plus some kind of "chipset" which lets the core talk to the other hardware. The core(s) should be fairly straightforward to implement, just using the ARM architecture reference manuals. The "chipset" part could be more tricky, as it needs to interface with the already existing Bochs PC hardware, but using only the ARM memory mapped I/O address space instead of the x86 memory mapped + I/O bus spaces.


I haven't really used hard disk images with Bochs, I normally just boot my kernel from an ISO image. So indeed that QEMU seems to be simpler to use in this case. But on the other hand, if you want to use a specific hard drive geometry in order to test whether your OS correctly determines this geometry, than you can do so with Bochs. I think it's a problem of being easy to configure some default vs. being easy to configure specific / non-default test cases.