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

[Matt Waddel]

Hi Mark,

It's nice to hear from you.  I wondered if our paths would cross
again after m68knommu at Freescale.

On 06/04/2010 02:30 PM, Loïc Minier wrote:
> 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.

Loïc summed things up pretty nicely.  I have been chipping away
at the bugs for a while now.  It seems like qemu supports a
single boot path and as soon as something changes a whole new
set of bugs pop-up.  I have been trying to get a stock beagleboard
configuration to boot using the Linaro 1005 Release parts.  I
am using the qemu version at:

git://gitorious.org/qemu-maemo/qemu.git

I was building a kernel from scratch, but have switched over to
using the parts from the 1005 release at:

https://image-share.canonical.com/linaro/10.05/

I just basically create a large image file and divide it into a
small vfat partition and a larger ext3 partition.  Right now all
of the parts in the small vfat partition work (ie. - x-loader,
u-boot.bin, kernel, and initrd).  It's failing when init tries
to switch to the real rootfs.

My goal here is to come up with a "build" system which will
create an image that can be booted on real hardware or qemu
without any modifications.  (I think I am minutes and 1 bug
away from success, but I've thought that before.)

> 
>  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.

I was going to start investigating virtio support for qemu
as soon as I had a good beagleboard system going.  However,
if you have any thoughts on this it would be good to hear
them.

> 
>  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.

Supporting various TI platforms seems reasonable at
this point.  I'm not sure how difficult Freescale
platforms would be.  In my opinion it was easier to
fix missing u-boot features than it was to fix kernel
problems.  The rootfs shouldn't make a difference
between the various platforms once it is working.

I guess the thing to do is build the default configs
in u-boot and the kernel and try them.  We might be
surprised.

Let me know if you need more information.  (I see
CodeSourcery copyright notices in a lot of qemu code
so you all probably know a lot more about this stuff
than I do, but I'm more than willing to help where I
can.)

Best regards,
Matt

> 
>  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
> 
>  ...
>