On 6 July 2012 19:00, Christian Robottom Reis <k...@linaro.org> wrote: > On Fri, Jul 06, 2012 at 05:19:10PM +0100, Peter Maydell wrote: >> Current Milestones: >> || || Planned || Estimate || Actual || >> ||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 || > > Wow. That's a lot of months off-plan! I like it that you have the > planned dates so I don't want to complain about it, but in your mind why > did this take so long?
A combination of: * I'm not very good at estimation, and going through all the cp15 registers and converting them took much longer than I expected * we ran into the combination of QEMU-upstream-freeze, Connect and my holiday, which accounts for 7-8 weeks all on its own where the status was basically "complete but not landed upstream" * we rearranged the schedule in early Feb when it became clear that this cp15-rework wasn't an absolute dependency for us to hit the initial milestone for Connect in SF, so we did various other tasks instead and cp15-rework went on the back burner for a month or two * some underestimation of how much time I would spend doing this dev work rather than other things (like qemu-linaro releases, upstream maintainer work, etc). >> ||a15-lpae-support || 2012-07-13 || 2012-07-13 || || >> ||clean-up-kvm-patches || || || || >> ||track-kvm-abi-changes || || || || >> ||fake-trustzone || || || || > > Also, are you planning on having planned/estimate entries here, given > your "by-August" entry? It's a bit tricky because the set of work we ended up with in the 'by August' card doesn't neatly line up with the blueprint boundaries, and also because there's a bunch of stuff on the card which is "wait for kernel side implementation then do a small amount of QEMU side work", and which I therefore can't provide estimate dates for because I have no idea when the kernel will be done. There's also a chunk of work I wasn't expecting to see on the card (though I don't disagree that it's there) and which thus doesn't yet have an underlying blueprint. I'll try to clean this up a bit for next week so that bit at least has some plan/estimate dates. >> * discovered that Linux will happily throw away the top 32 bits >> of a device tree memory node's size field. Wrote a patch for this, >> which works but needs redoing to fix in a cleaner way. > > That's weird. Why would it do that? Because historically the assumption in arch/arm has been that you can't possibly have a memory size that won't fit in 32 bits because physical addresses are 32 bits; this is just a dangling assumption that never got fixed. See thread on linaro-dev for technical detail. -- PMM _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
