I can finally answer that question
Code: Select all
qemu -M raspi3
It would be great to have the BCM2835 System Timer implemented, especially if it would be in the official QEMU.bzt wrote: ↑Tue Feb 26, 2019 3:02 amIf the qemu developers accept the patch, I'll continue with the BCM2835 System Timer. That's a bit more difficult to implement, as there's no class for it yet and it requires a dynamic memory value, but with that many bare metal projects would run under qemu (like @rst's Circle for one). Usually the reason of failure is the infinite delay() loop, caused by the register at 0x3F003004 (SYSTEMTIMER_CLO) not changing at all.
Tell me about it Last time the "-M raspi3" patch only went through because Pekka helped. I hope the ARM Local Timer will pass as that's a very simple patch, but with the System Timer I'll definitely need Pekka's help again. I'm hoping he is willing to push through another patch of mine. But first I have to write it
In the repo of 0xabu, which I forked, the System Timer has already been implemented. I'm sure, that it works, because I'm using it from time to time with Circle. I think, this man did already a lot for RPi support in QEMU. I don't know, why this System Timer support is not part of the current QEMU 3.1.0, because 0xabu had it implemented and did add code to QEMU.
Thanks for this hint. Perhaps I will try this, when the System Timer works. At the moment the patch would not help me, because Circle is not working with the original QEMU and the patch cannot be tested. But I think, this has already been tried (search for "usb_net_handle_dataout") by flypie at GitHub and the patch was not accepted, because it is not contained in QEMU 3.1.0.About your dev-network.c patch, if I were you, I would write to the qemu-devel at nongnu.org mailing list. I'm sure your patch qualifies as a trivial patch.
Hey this is awesome, he wrote the driver exactly in a way I wanted to! And he has also added the power management interface! I see no point in reimplementing the wheel (or reinventing the timer, ehhh whatever ). His solution looks pretty good, clean code, proper classes, using host friendly virtual clock etc. Do you know by any chance why on earth was his patch refused?rst wrote: ↑Tue Feb 26, 2019 2:52 pmI have to apologize, because I mentioned the wrong author of the bcm2835_st driver for QEMU. The driver is here and the author is noticed in the file header. In the commit notice there is the suffix "et al".
Shouldn't talk about things, I do not know much about like QEMU. @bzt you knows for sure much better, how to handle this with QEMU, because, as far as I know, you have done a lot for it too. So I'm looking forward to your solution for the System Timer, based on this one above or a new one, what ever is better from your point of view.
It's good, if this driver helps you. No, I have no clue, but it seems to be not easy to get a patch accepted.bzt wrote: ↑Wed Feb 27, 2019 1:14 amHey this is awesome, he wrote the driver exactly in a way I wanted to! And he has also added the power management interface! I see no point in reimplementing the wheel (or reinventing the timer, ehhh whatever ). His solution looks pretty good, clean code, proper classes, using host friendly virtual clock etc. Do you know by any chance why on earth was his patch refused?
ps.: The all winner comment is: "/* Ugly temporary hack to get Plan9 to boot... */", that alone made my day!!!
This is really good news! Thanks.bzt wrote: ↑Thu Feb 28, 2019 2:22 pmThe ARM Local Timer is accepted for a review, and I got answer from Andrew. He said the only reason why those drivers weren't merged because he didn't had the time to bring them up with the modern qemu API. Yeah, lots of things changed, granted, but still I can do that easily. I also got Pekka on board, so this is really happening
We took the opposite approach, instead of waiting for QEMU to emulate a Raspberry Pi we added QEMU support to Ultibo. The advantage of this approach is that we get network, storage, keyboard, mouse, framebuffer etc without having to worry about incomplete or inaccurate emulations of the Pi specific devices.
It isn't really a workaround, more of an option for those that need it.
Let us do some quick tests and see, we'll let you know the results.