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

[BALATON Zoltan]

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.

Regards,
BALATON Zoltan