[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [PATCH 17/19] uninorth: create new uninorth
Re: [Qemu-ppc] [Qemu-devel] [PATCH 17/19] uninorth: create new uninorth device
Wed, 25 Apr 2018 11:35:45 -0300
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
On 04/25/2018 03:58 AM, Mark Cave-Ayland wrote:
> On 25/04/18 07:34, David Gibson wrote:
>> On Wed, Apr 25, 2018 at 07:06:03AM +0100, Mark Cave-Ayland wrote:
>>> On 06/04/18 06:33, Mark Cave-Ayland wrote:
>>>> On 25/03/18 22:11, Mark Cave-Ayland wrote:
>>>>> Just to follow up on this, I spent a bit looking at what this
>>>>> register is trying to do and from the Darwin source I can see that
>>>>> in fact it is simply a hard-wired hardware register which should
>>>>> return the revision of the UniNorth hardware.
>>>>> So in fact the code in its current form is completely bogus which is
>>>>> visible when trying to boot FreeBSD, which as the register is never
>>>>> written to, returns a completely different random number each time.
This is scary...
>>>>> David - are you okay to change DEVICE_NATIVE_ENDIAN to
>>>>> DEVICE_BIG_ENDIAN and then apply this and the final patch to your
>>>>> for-2.13 queue? I can then follow up with another patch later that
>>>>> will implement this register (and also the matching PCI revision ID)
>>>> Ping? I can see that more patches are being added to the for-2.13
>>>> so I was just wondering if there is now anything else needed from me in
>>>> order to get the last 3 patches from this patchset queued?
>>> Ping again? The reason for asking is because my next set of Mac
>>> branches are
>>> all rebased on this patchset since they rely on this, plus the final two
>>> patches in this series which remove the need for qdev_connect_gpio_out()
>>> when wiring up macio devices.
>> Uh... sorry. I completely missed this series. And, apparently, your
>> earlier ping. Can you resend, please. Make sure you explicitly CC
>> me, I occasionally go through the lists but it's easy for me to miss
>> stuff there.
> No it's okay - you've already got the majority of the patchset applied
> to ppc-for-2.13 (see
> https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg04312.html) but
> it's the last 3 patches which are still missing, presumably because
> Philippe had some questions about them at
> https://lists.gnu.org/archive/html/qemu-devel/2018-03/msg06026.html and
> you queried the DEVICE_NATIVE_ENDIAN at
> If you're happy to consider patch 17 as just code movement and touch it
> up locally to use DEVICE_BIG_ENDIAN rather than have me resend, then
> does that allow the remaining patches 17-19 to be applied to ppc-for-2.13?
> Once they are there I can send a follow-up patch which will completely
> remove the original implementation in patch 17 and replace it with a
> proper versioned register, updating the PCI config space to match
> In short: without the follow-up patch the code for the uninorth register
> both before and after patch 17 is wrong regardless of which endian is
> used, so that itself doesn't affect whether or not it can be applied.
With this explanation you have my blessing :)
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>