[PATCH v5 01/12] efi: Correct handling of frame buffer

[Jiaxun Yang]

在2024年5月17日五月 下午1:46，Heinrich Schuchardt写道：
> On 11/19/23 20:11, Simon Glass wrote:
>> The efi_gop driver uses private fields from the video uclass to obtain a
>> pointer to the frame buffer. Use the platform data instead.
>>
>> Check the VIDEO_COPY setting to determine which frame buffer to use. Once
>> the next stage is running (and making use of U-Boot's EFI boot services)
>> U-Boot does not handle copying from priv->fb to the hardware framebuffer,
>> so we must allow EFI to write directly to the hardware framebuffer.
>>
>> We could provide a function to read this, but it seems better to just
>> document how it works. The original change ignored an explicit comment
>> in the video.h file ("Things that are private to the uclass: don't use
>> these in the driver") which is why this was missed when the VIDEO_COPY
>> feature was added.
>>
>> Signed-off-by: Simon Glass <sjg at chromium.org>
>> Fixes: 8f661a5b662 ("efi_loader: gop: Expose fb when 32bpp")
>> Reviewed-by: Bin Meng <bmeng.cn at gmail.com>#
>
> Since this patch
> a75cf70d23ac ("efi: Correct handling of frame buffer") the EFI block
> image transfer is broken on the sandbox.

Our situation on sandbox is a little bit confusing to me.

Sandbox requires explicit sync itself to allow framebufer to be copied
to the texture, so I don't really understand how does this work in first
place.

Thanks
- Jiaxun

>
> Build sandbox_defconfig with CONFIG_EFI_SELFTEST=y.
>
> setenv efi_selftest block image transfer
> bootefi selftest
>
> A moving submarine should be shown.
>
> Best regards
>
> Heinrich
>
>> ---