On 2 November 2014 13:34, Ben Gras <b...@shrike-systems.com> wrote: > A few months of work sounds like a bit much to take on as a side project at > this point, and I have a few already, so no promises. But I am interested in > hearing where the first thread is to start pulling at, so to speak.
The major problem is simply that the patches are a nasty mess of new functionality, formatting changes, genuine bugfixes and the odd random unnecessary change, and all of this has to be straightened out into a coherent set of patches for them to go upstream. I managed to do this in some places (and so a few parts of omap3 actually went upstream already) but there is a lot more work still to do. Also necessary will be updating this fairly old code to modern QEMU standards (most notably making all the devices and SoC containers into proper QOM classes). This is usually fairly straightforward but there is a lot of code here to update. The omap3's "fake not actually functional trustzone" code that it uses to make the omap3 kernel SMC interface work is going to collide with the actual functional implementation of TZ that's starting to appear upstream, so it will need to be looked at to see how much changing it needs. (If you try to rebase the patches this is probably going to be the nastiest bit to sort out to get them back to functional again.) My plan last time I was thinking about how to do this was based on trying to identify a minimum subset of devices that would still boot a kernel that was configured with a very minimal set of devices (so no graphics, no MMC, no USB, etc etc). Unfortunately since u-boot for OMAP3 seems to like to probe anything and everything this means that we probably need to start by implementing support for QEMU's -kernel parameter to directly load a kernel rather than letting the guest boot loader do it. Then identify the minimal set of devices and clean up just those to get them into submittable shape. Once those are upstream then the size of the patchset is reduced, which in turn means the pain of maintaining it out of tree is lowered, and it's a bit easier to try to sort out the rest one device at a time. -- PMM _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
