Closed kamathba closed 8 years ago
Hello Ben, We do know that us diverging from mainline QEMU is a problem and we are working on fixing this. We are also trying hard to send our code upstream to mainline QEMU. It is just a slow process.
Hi Alistair, I was wondering the same. Especially since I was looking for Cortex-R5f support and it's difficult to tell if your patch aeab360746ecf56f9a08e8989570042942d06920 is broken, not accepted for another reason or (what I believe to be most probable) just not send/reviewed upstream, yet.
So am I safe with that patch, do I need to nag qemu-dev on IRC,...? I would probably just apply it to 2.5.1.1.
But I appreciate your work :) and I am happy I don't have to do the R5f stuff ;)
Hey Sebastian, Hopefully that patch isn't broken, we just haven't sent it upstream. I have a beta branch of a much newer QEMU version. I'll push that to a side branch after a little bit of tidying up. No guarantees anything works though. I'm glad we can help :) Alistair
Hello all, I just pushed this branch which updates us to QEMU 2.6.5. It still has a few bugs, but it seems pretty stable so far Feel free to use it and let me know how it goes. https://github.com/Xilinx/qemu/tree/mainline-merge
We just finished merging the QEMU release 2.6.0. We will continue to move forward and hopefully we will be able to catchup with mainline QEMU soon. I am going to close this issue now.
This fork seems like it is diverging, though some patch sets make it upstream to the main qemu repository.