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

[Philippe Mathieu-Daudé]

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".