Re: [PATCH v2 0/6] hw/southbridge: QOM'ify vt82c686 as VT82C686B_SOUTHBRIDGE

[Philippe Mathieu-Daudé]

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.