qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 1/2] hw/misc/bcm2835_property: Fix framebuffer with recent RP


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 1/2] hw/misc/bcm2835_property: Fix framebuffer with recent RPi kernels
Date: Mon, 18 Oct 2021 11:47:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0

On 10/18/21 02:41, Benjamin Herrenschmidt wrote:
> On Sun, 2021-10-17 at 17:08 +0200, Philippe Mathieu-Daudé wrote:
>> Hi Benjamin,
>>
>> On 10/17/21 09:48, Benjamin Herrenschmidt wrote:
>>> The framebuffer driver fails to initialize with recent Raspberry Pi
>>> kernels, such as the ones shipped in the current RaspiOS images
>>> (with the out of tree bcm2708_fb.c driver)
>>
>> Which particular version?
> 
> The one I dug out of 2021-05-07-raspios-buster-arm64-lite.img (note
> that this then fails to boot some time after the fb is setup, even
> after the fix, in the vchip driver init (before serial is up even).
> 
> That said, the same fb problem happens with 5.10.60-v8+ from raspbian.
> 
> I'm not sure your fix will work on these, see below:
> 
>> +        case 0x00040013: /* Get number of displays */
>> +            stl_le_phys(&s->dma_as, value + 12, 0 /* old fw: unique display 
>> */);
>> +            resplen = 4;
>> +            break;
>>
> This should have been equivalen to not having the property. However,
> the failure path in the driver looks like this (note the mismatch
> between the comment and the code.. this is rpi 5.10.73 from the rpi
> repo :
> 
>       ret = rpi_firmware_property(fw,
>                                   RPI_FIRMWARE_FRAMEBUFFER_GET_NUM_DISPLAYS,
>                                   &num_displays, sizeof(u32));
> 
>       /* If we fail to get the number of displays, or it returns 0, then
>        * assume old firmware that doesn't have the mailbox call, so just
>        * set one display
>        */
>       if (ret || num_displays == 0) {
>               dev_err(&dev->dev,
>                       "Unable to determine number of FBs. Disabling 
> driver.\n");
>               return -ENOENT;
>       } else {
>               fbdev->firmware_supports_multifb = 1;
>       }
> 
> So it appears that the intention at some stage was to set only one display but
> the code as written will fail to initialize the drive if the properly is 
> absent
> *or* if it returns 0.
> 
> I've just checked the rpi-5.15.y branch and it's the same.

Indeed. I stopped testing recent kernels because they use too many
features QEMU don't implement.

Our model should generate the DTB blob of devices implemented, instead
of giving false expectations to the guest by passing an unmodified dtb.

This is on my TODO, I might give it a try next WE.



reply via email to

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