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. Regards, Phil.
