On Sunday 06 March 2022 05:51:34 Simon Glass wrote:
> Hi Pali,
>
> On Sun, 6 Mar 2022 at 04:51, Pali Rohár <p...@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 p...@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;
+
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.
