[Linaro-dev] Availability of hardware for Linaro development?

[Loïc Minier]

On Fri, Jun 04, 2010, Mark Mitchell wrote:
> Various CodeSourcery folks have a lot of experience with ARM QEMU.  If
> there are things that we can do to improve QEMU in the context of
> Linaro, we're happy to do so!

 There are tons of things which could be done on the QEMU front indeed!

 We should coordinate things with Matt Waddel since he has been working
 a lot on this in the last weeks, to avoid work duplication.  I Cc:ed
 him explicitly so that he monitors the thread.  In fact, I expect him
 to have a better list of TODOs than mine.

 a) qemu-maemo/-meego, beagleboard fixes

 Matt has been working on top of the qemu-maemo/qemu-meego branches
 which provide beagleboard support; this branch has recently started
 being upstreamed by cmchao at gmail.com on the qemu-devel@ list.  It would
 be nice to get the support patches in QEMU proper as to get the full
 beagleboard/n900 support in distros.

 Matt produced some nice fixes for beagles when faced with the Ubuntu
 linux-ti-omap kernel, which has a bunch of things turned on exposing
 some QEMU bugs.  Ideally, we'd be able to boot stock OMAP images from
 Angstrom, Ubuntu etc. in QEMU, but that currently fails in various
 places ATM.

 b) buildd setup

 Fast ARM hardware is not very widely available yet, which makes it hard
 to build things like native builds farms.  It's also expensive and hard
 to maintain such a farm.  Finally, some companies might not be happy to
 use the hardware from a competitor to run their build farm.

 Using QEMU in a buildd setup on top of Intel hardware makes sense to
 address these issues.  However, it's hard to find platforms which are
 both well supported in QEMU and well supported in the upstream kernel.
 Currently, Ubuntu provides versatile kernels to use with QEMU, patched
 ot run v7.  This is a bit limitative and it's very slow too.  Versatile
 is an old board, and has limitations around memory support (no sparse
 memory, the platform didn't support much RAM etc.).

 It would be great to have a fully featured and more recent board,
 perhaps a realview one, or an omap3 one.

 One thing which would probably boost performance significantly would be
 to add virtio support to ARM.  It would allow for much faster disk and
 network I/O for sure.

 c) support for more platforms

 It might make sense to support more platforms and hardware to e.g.
 automate testing of binary images, kernels, or just to develop new
 features while the hardware stabilizes (allowing software development
 to start before hardware is available).  This is more blue sky stuff,
 but having support for e.g. imx53 or OMAP4 would be awesome, but it
 seems out of reach unfortunately.

 d) random features / bugs

 * Would be great if we could easily run x86 binaries when running
   qemu-system-arm under x86 (this is possible in syscall emulation mode
   already)

 * mono hangs when installed under QEMU ATM

 * more syscalls / better emulation in syscall emulation mode

 ...

-- 
Loïc Minier