|
From: | BALATON Zoltan |
Subject: | Re: [PATCH v2 0/6] hw/southbridge: QOM'ify vt82c686 as VT82C686B_SOUTHBRIDGE |
Date: | Sat, 15 May 2021 22:01:17 +0200 (CEST) |
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-20210504I'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.makI 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.htmlWell, 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.htmlabout 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
[Prev in Thread] | Current Thread | [Next in Thread] |