On Sat, 15 May 2021, Philippe Mathieu-Daudé wrote:
On 5/15/21 4:37 PM, BALATON Zoltan wrote:
On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote:
On 5/13/21 1:54 PM, BALATON Zoltan wrote:
On Thu, 13 May 2021, Philippe Mathieu-Daudé wrote:
On 5/11/21 3:09 PM, BALATON Zoltan wrote:
On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote:
Hi Zoltan,
On 5/11/21 1:28 PM, BALATON Zoltan wrote:
On Tue, 11 May 2021, Philippe Mathieu-Daudé wrote:
The motivation behind this series is to remove the
isa_get_irq(NULL) call to simplify the ISA generic model.
Since v1:
- rebased on top of remotes/dg-gitlab/tags/ppc-for-6.1-20210504
I'll try to have a look at these later but some notes: The pegasos2
changes are now in master so if this was before that maybe
rebasing on
master is now enough.
This is what this series does, simply rebase on top of your merged
patches.
However I wonder if any changes to pegasos2.c is
needed due to changed init of the chip model or is that only
affecting
82c686b?
There is no change in 'init' in this series, it is only QOM
boilerplate
code churn, no logical change intended.
Please also note that pegasos2 is not enabled by default due to
needing undistributable firmware ROM so to test it you need to
enable it
in default-configs/devices/ppc-softmmu.mak
I remember you said you were mostly interested in the VT8231, not
the VT82C686. This series only QOM'ify the latter.
OK as I said I haven't looked at it in detail.
What is your idea? Send the firmware off-list and explain how
the OS works and how (what) to test?
I've already sent you this info:
https://lists.nongnu.org/archive/html/qemu-devel/2021-01/msg01553.html
Well, if you have everything setup, it is easier to test and send
a Tested-by tag.
I indend to test it when I'll have some time but I could not get to
it yet.
but I can't write a test case so if you want to automate this and make
it part of QEMU tests then some help with that would be appreciated.
You are not the only want wanting that. I'm working on a solution to
run
such tests (depending on binary blobs) in your own namespace, but it
will take me time (doing it in my free time, without help).
I did not mean to say you should do this urgently, just sent this as a
reminder about how this could be tested in case you forgot because
you've asked about testing.
Unrelated to this series, with master (dab59ce0312) I sometime get:
Initializing KBD...00000012 FAILED.
and then the mouse isn't working.
Sometimes:
Initializing KBD... Done.
and the mouse is crazy (similar to my host mouse).
Anyway, there is smth wrong with patch #2 of this series:
"Simplify removing unuseful qemu_allocate_irqs() call".
As I said before, when I've tried to do it that way first it did not
work for me so I introduced the indirection which fixed it but I did not
understand why it was needed or I forgot by now so all I remember is
that I could not directly connect the irq and needed the local function
for some reason.
OK, I'll try to figure out what the problem is and come back to you.
I'm not sure, but could this be related to a note Peter made in this
series:
https://lists.nongnu.org/archive/html/qemu-ppc/2020-12/msg00171.html
about converting PPC interrupts to qdev qpios? Could it be that the irq
cannot be connected directly as it has some unexpected behaviour due to
this?
Regards,
BALATON Zoltan
