Dear all,
I hope this isn't a FAQ. I looked around and didn't find the topic discussed.
I am a longtime and grateful user of the linaro bbxm implementation. (For Minix.) Thanks for the great work!
For RTEMS we want to use it to run the RTEMS tests for the (upcoming) beagle support code.
My question is: is Linaro planning to upstream the bbxm code to stock qemu?
Having a single qemu would simplify life for us.
Thanks for your attention!
Ben
On 1 November 2014 23:15, Ben Gras beng@shrike-systems.com wrote:
My question is: is Linaro planning to upstream the bbxm code to stock qemu?
Having a single qemu would simplify life for us.
Upstreaming that code is something we would in theory like to do, but it is quite a lot of work required to clean it up to the point where it is upstream quality, so at the moment (and for the last several years!) more urgent/important things have unfortunately taken precedence. (It's probably a couple of months or more worth of work, depending how much of the functionality you want to try to upstream. If anybody wants to tackle the job I'm happy to give suggestions about what needs doing.)
-- PMM
All,
Ok, thanks for letting me know. It's better news than it could have been, e.g. we don't want it mainlined or upstream doesn't want it.
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.
On Sun, Nov 2, 2014 at 2:06 PM, Peter Maydell peter.maydell@linaro.org wrote:
On 1 November 2014 23:15, Ben Gras beng@shrike-systems.com wrote:
My question is: is Linaro planning to upstream the bbxm code to stock
qemu?
Having a single qemu would simplify life for us.
Upstreaming that code is something we would in theory like to do, but it is quite a lot of work required to clean it up to the point where it is upstream quality, so at the moment (and for the last several years!) more urgent/important things have unfortunately taken precedence. (It's probably a couple of months or more worth of work, depending how much of the functionality you want to try to upstream. If anybody wants to tackle the job I'm happy to give suggestions about what needs doing.)
-- PMM
On 2 November 2014 13:34, Ben Gras beng@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
-
Ben Gras -
Peter Maydell