RAG: Red: Amber: Green:

Current Milestones: || || Planned || Estimate || Actual || ||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 || ||upstream-omap3-cleanup || 2011-11-10 || 2011-11-10 || ||

Historical Milestones: ||qemu-linaro-2011-07 || 2011-07-21 || 2011-07-21 || 2011-07-21 || ||qemu-linaro 2011-08 || 2011-08-18 || 2011-08-18 || 2011-08-18 || ||qemu-linaro 2011-09 || 2011-09-15 || 2011-09-15 || 2011-09-15 || ||add-omap3-networking || 2011-10-13 || 2011-10-13 || 2011-10-13 || ||a15-systemmode-planning || 2011-10-13 || 2011-10-13 || 2011-09-22 ||

== a15-usermode-support == * A15 instruction support patches committed upstream in time for upstream's 1.0 release == upstream-omap3-cleanup == * some work on restructuring the omap3 patchset -- it's now basically in the right order and the last 'touches several different bits of code' jumbo patch has been split == other == * sent some patches upstream which address the main things I want to get into qemu 1.0 (PL041 audio support and fixing a regression in handling multithreaded programs in linux-user mode) * A15 KVM planning work and other preparation for Linaro Connect * finally tracked down the qemu-on-ARM memory corruption: we mmap the code generation buffer at 0x1000000 with MAP_FIXED; unfortunately this is now in the middle of glibc's heap... (filed as LP:883133) * qemu now has a coroutine implementation which defaults to using makecontext() if it is present. Unfortunately ARM eglibc provides an implementation which always returns ENOSYS, which is a bit tricky to detect with a compile time configure check (without breaking cross-compilation support). * these two things (and some other known bugs) mean that QEMU on ARM hosts is basically broken, and will probably continue to be since we don't have the spare resource to test and fix bugs (beyond those which we need to fix for KVM-on-ARM)