Emulating An Arm Linux System On Windows

[benjymous]

I'm currently trying to hack together a Arm Linux type environment so I can start development without access to a real pandora. I've got to the stage of booting linux, but there are a few snags -
it insists on fsck'ing the fs on every boot, and qemu has a bug that causes it to hang. You can skip the fsck (ctrl+c) but this seems to result in the filesystem getting mounted as read-only (which is somewhat useless!)

Has anyone else done anything similar?

Emulating a Linux Arm system on Windows

 

[sindbad]

If you're using ext2, switch to ext3 or jffs2.

 

[juanvvc]

Unless you really need an ARM (that is, if you are going to do some assembler coding), you can use a normal Linux system to develop applications. If you use C+SDL, you can use your Windows box since you won't need so many system calls (read/write files at most, and they are the same in Windows and Linux)

 

[benjymous]

Unless you really need an ARM (that is, if you are going to do some assembler coding), you can use a normal Linux system to develop applications. If you use C+SDL, you can use your Windows box since you won't need so many system calls (read/write files at most, and they are the same in Windows and Linux)

Yeah, I know - my plan was to get a debian arm system up and running with roughly the same setup as a Pandora, then start trying to optimise debian packages to run well in that environment

 

[pder]

I'm currently trying to hack together a Arm Linux type environment so I can start development without access to a real pandora. I've got to the stage of booting linux, but there are a few snags -
it insists on fsck'ing the fs on every boot, and qemu has a bug that causes it to hang. You can skip the fsck (ctrl+c) but this seems to result in the filesystem getting mounted as read-only (which is somewhat useless!)

Has anyone else done anything similar?

Emulating a Linux Arm system on Windows



I have done a successful Debian arm install with these instructions:

http://www.aurel32.net/info/debian_arm_qemu.php

 

[Svartalf]

Yeah, I know - my plan was to get a debian arm system up and running with roughly the same setup as a Pandora, then start trying to optimise debian packages to run well in that environment

They should already run "well" in that environment. ARM's not rocket science- the Linux community has been doing it for a while now with OpenEmbedded (Which is the distribution builder that we're using for making the firmware images...). By all means, go on ahead, but I think you're going to find that the emu environment's going to be slow on QEMU for any machine not a mid to high end box. Moreover, I think a goodly bulk of the work's been done already...

 

[benjymous]

They should already run "well" in that environment. ARM's not rocket science- the Linux community has been doing it for a while now with OpenEmbedded (Which is the distribution builder that we're using for making the firmware images...). By all means, go on ahead, but I think you're going to find that the emu environment's going to be slow on QEMU for any machine not a mid to high end box. Moreover, I think a goodly bulk of the work's been done already...

They'll be optimised for ARM, yes, but not necessarily for a small touch screen system with the Pandora's style of input, so most of the porting work will be in refactoring UIs to work better, etc

I have done a successful Debian arm install with these instructions:

http://www.aurel32.net/info/debian_arm_qemu.php



Yeah, I tried that, but it seemed to get stuck downloading packages (unless it was taking a rediculously long time depacking stuff...)

Maybe I'll leave it going overnight, and see where it gets to

 

[ledow]

I'm currently trying to hack together a Arm Linux type environment so I can start development without access to a real pandora.

I tried this once, I was trying to make a primitive "gp2x emulator" using qemu-arm. I was intending to tweak qemu so that, for example, it could load the GP2X firmware image and run that, and would use the same locations as the GP2X for things like sounds buffers, joystick inputs, screen framebuffer etc. In the end I didn't need it, but it would be a good thing for somebody to do. The GP2X may soon go the way of the dodo and it'd be a shame to lose those GP2X programs for which we don't have sourcecode.

it insists on fsck'ing the fs on every boot, and qemu has a bug that causes it to hang. You can skip the fsck (ctrl+c) but this seems to result in the filesystem getting mounted as read-only (which is somewhat useless!)

You could run tune2fs and/or edit /etc/fstab from inside the arm environment to turn off the disk check entirely. In fstab, I believe it's the last number that determine whether a disk is checked on bootup (and in what order if you have a number of partitions). tune2fs has a load of options to tweak all bits of a filesystem including when/if it's marked dirty because of the number of mounts / days since last check.

 

[mcobit]

Ever tried to remount the drive read/write after booting in read-only mode?

 

[cosam]

it insists on fsck'ing the fs on every boot, and qemu has a bug that causes it to hang. You can skip the fsck (ctrl+c) but this seems to result in the filesystem getting mounted as read-only (which is somewhat useless!)

Add "init=/bin/bash" to the -append string when starting qemu. This will drop you into a shell from which you can edit /etc/fstab (if root is still read-only do "mount -o remount,rw /" first).

 

[ledow]

Ever tried to remount the drive read/write after booting in read-only mode?

You are using a qemu image file as an emulated hard drive, I assume. In which case, you can operate directly on the file itself in most cases. Depending on your partition layout in that emulated hard drive, it could be simple (loop mount the .img file) or complicated. I tend to always have an ISO image of the distribution around on my hard drive so in such cases, I get qemu to boot from that "CD" and fix the "hard drive" manually. I don't think you'd need an ARM-based ISO (i.e. you could load up normal qemu on a normal x86 ISO and that hard drive image) but you might. I think the hard drive partitions/format can be read properly from any linux kernel.

But, yes, the simple way is to get the kernel that's booting to override the r/o through an explicit remount as SteveM detailed. It does make me wonder, though, why the kernel insists on fsck'ing the drive every time - this could be a time/date issue (because it thinks it's 180 days since it last did it, because the distribution didn't tune2fs that filesystem to stop the checks and it's still got a creation date WAY in the past), the distribution that you've used (i.e. if they've not tune2fs'd the filesystem to stop such checking in the first place) or something more sinister (the ext2 filesystem itself or the image file that holds the hard drive is corrupt).

 

[cosam]

It does make me wonder, though, why the kernel insists on fsck'ing the drive every time - this could be a time/date issue

Your suspicion is right - if there's no RTC emulated, or it can't be read, the kernel reverts to epoch and everything goes pair-shaped. You have the added bonus that all your passwords have expired, too ;-)

 

[Exophase]

The one problem with using something like qemu to write optimized ARM code before the platform is out is that you won't be able to get profiling numbers that mean much at all.

 

[Svartalf]

They'll be optimised for ARM, yes, but not necessarily for a small touch screen system with the Pandora's style of input, so most of the porting work will be in refactoring UIs to work better, etc

Actually, many of the apps should already be that way- Maemo already does a LOT of this sort of thing for the Nxxx series devices. They're OMAP2 based and have the same screen real-estate, etc. Maemo could concieveably be an advanced UI for the Pandora if someone wanted it to be pretty easily. And, emulating the stuff's not the same thing as tweaking on a similar platform or the actual target. The emulation never quite works the way one would think it would. This is not telling you that I think you're wasting your time- that's hardly the case. Just setting appropriate expectations...

 

[benjymous]

Add "init=/bin/bash" to the -append string when starting qemu. This will drop you into a shell from which you can edit /etc/fstab (if root is still read-only do "mount -o remount,rw /" first).

Thanks - that seems to have done the trick.

 

[javaJake]

Well, I did some serious poking around to solve the /dev/rtc0 issue (which I think affects the time), and I thought that perhaps I should start from scratch (since the precompiled qcow image available crashes as well).

Then I came up with this (thread starts here). The gist of the it is, what QEMU can emulate is old, and what QEMU can't emulate is hardware new enough to cause ARM to lock it down under NDA.

So, at this point I don't think it's worth it, since QEMU can't really give us an accurate system, in relation to the OMAP3 anyway. You're better off e-mailing a developer who already has a board.

 

[benjymous]

So, at this point I don't think it's worth it, since QEMU can't really give us an accurate system, in relation to the OMAP3 anyway. You're better off e-mailing a developer who already has a board.

Ok, I know it's not really accurate, but it still gives us a feel for what needs doing to get existing UI based apps running on the Pandora, and if they'll fit in memory.

FWIW, I've now got it running X at 800x480 using the Matchbox WM, and have set the screen DPI to 150, which seems to give a readable UI in most apps when the window is scaled down to the actual LCD size.

Firefox 2 and Thunderbird 1.5 (or rather IceWeasel and IceDove) seem to run ok, and appear to fit happily within a 128mb memory footprint. You need to turn off toolbars and run FF in fullscreen mode to get the most usability, but they happily scale and display stuff sensibly at 150dpi. They both run dog slow (due to the emulation), but do seem to work, and FF seemed perfectly happy (other than the slowness) with three tabs open.

Abiword runs much better, and a just about usable speed within qemu (so I'd expect this to really fly on the Pandora!)

This is very reassuring, since it basically tells us that a good chunk of X based applications should work out of the box if we can install arm debian packages directly, and if not, it should be straightforward to recompile them against the Pandora libs

 

[javaJake]

Yea, except, remember, these applications all ran on an entirely different ARM processor. If you're just looking to see if it looks good, someone already wrote a little application for that. If you're looking to figure out how fast it'll be... well, that's a different matter altogether.

I guess to each his own. Personally, I'd much rather wait and spend productive time with the Pandora instead.

By the way, did you work around the rtc and time issues, or did you actually manage to fix them?

 

[benjymous]

Yeah, I was mostly thinking about how much work will be invoved reworking UIs and such, and didn't really feel like installing a full linux distro on my PC - qemu answers those questions fine.

By the way, did you work around the rtc and time issues, or did you actually manage to fix them?

It's odd... The rtc fails miserably when qemu runs on my office machine. The same version of qemu emulates an rtc fine when running on my home pc. :blink:

 

[javaJake]

Maybe it has to do with kqemu. Could you try loading it once with and once without that module?

*did tests 'self*

Nope, still fails with or without kqemu.