Hi Pali,
On Sun, 6 Mar 2022 at 07:17, Pali Rohár pali@kernel.org wrote:
On Sunday 06 March 2022 05:51:34 Simon Glass wrote:
Hi Pali,
On Sun, 6 Mar 2022 at 04:51, Pali Rohár pali@kernel.org wrote:
PING?
On Thursday 17 February 2022 13:20:43 Pali Rohár wrote:
On Thursday 17 February 2022 09:53:39 Anatolij Gustschin wrote:
Hi Pali,
On Wed, 16 Feb 2022 21:42:19 +0100 Pali Rohár pali@kernel.org wrote:
I had to comment "return -ENOSPC;" in video-uclass.c because without it DM_VIDEO does not work and I do not know why. This looks like either false-positive test or a bug in DM_VIDEO code. I have already set PRE_RELOC flag but it has no effect on that code.
Probably the frame buffer memory allocation did not work. Could you please try with a bind callback, i.e.:
static int rx51_video_bind(struct udevice *dev) { struct video_uc_plat *plat = dev_get_uclass_plat(dev);
plat->size = 800 * 480 * 2; return 0;} ... U_BOOT_DRIVER(rx51_video) = { .name = "rx51_video", .id = UCLASS_VIDEO, .bind = rx51_video_bind, .probe = rx51_video_probe, .flags = DM_FLAG_PRE_RELOC, };
Hello! It does not work too. Here is the output:
U-Boot 2022.04-rc2-00002-ga2c1a9878375-dirty (Jan 01 1970 - 00:00:00 +0000)
OMAP35XX-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz DRAM: Video frame buffers from 8fe30000 to 8fe30000 256 MiB Video device 'rx51_video' cannot allocate frame buffer memory -ensure the device is set up before relocation
If "return -ENOSPC;" is not commented then this is the last printed line. If it is commented then output continues with:
video_post_bind: Claiming 130000 bytes at 8fd00000 for video device 'rx51_video'
And framebuffer is working fine like without above rx51_video_bind() change.
It looks like you are hard-coding the address of the video buffers. Is that intentional? If so, you may need to disable U-Boot's automatic allocation.
This is how it works, signed bootloader which loads U-Boot initialize and prepare framebuffer.
One way to do that is to set the frame buffer address and size in your bind() routine (post relocation) and update video_post_bind() to check if the address is non-zero (plat->base I mean) and skip its allocation if so.
Ok, I have tried it and following change makes framebuffer in qemu working:
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c index 7d499bcec51d..f4d8d395e714 100644 --- a/drivers/video/video-uclass.c +++ b/drivers/video/video-uclass.c @@ -78,6 +80,9 @@ static ulong alloc_fb(struct udevice *dev, ulong *addrp) if (!plat->size) return 0;
if (plat->base)return 0;
Yes let's go with that.
align = plat->align ? plat->align : 1 << 20; base = *addrp - plat->size; base &= ~(align - 1);Is this what you mean?
Second thing is that CONFIG_VIDEO_LOGO is broken and does not work even it is enabled in config file. I do not know why too.
Any idea?
Not yet. There were some logo related changes recently, but if I remember correctly, I tested them on wandboard and nitrogen6q targets and with sandbox, and logo drawing worked there.
Can you be more specific than 'broken'? What is broken about it?
Does not work, logo is not drown on the screen.
See video_bmp_display() - I wonder if the particular depth you are using is not supported? Anyway you should be able to debug it there or using the bmp command. The file is drivers/video/u_boot_logo.bmp
Regards, Simon