qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v2 0/6] hw/southbridge: QOM'ify vt82c686 as VT82C686B_SOUTHBRIDGE
Date: Thu, 13 May 2021 11:46:55 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

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.

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

> As for the firmware, once Alexey's VOF (Virtual Open Firmware, minimial
> OF emulation in QEMU) is merged I plan to try to use that to make it
> possible to boot some guests with that so no firmware image would be
> needed and pegasos2 could be enabled by default. But for now a firmware
> image is needed as guests expect an OF environment to boot.
> 
> Regards,
> BALATON Zoltan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]