From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Wed, 25 Nov 2020 07:49:53 -0700 Subject: early stage debugging on a real product In-Reply-To: References: Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Andy, On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko wrote: > > On Wed, Nov 25, 2020 at 1:41 AM Simon Glass wrote: > > On Tue, 24 Nov 2020 at 12:46, Andy Shevchenko wrote: > > > On Tue, Nov 24, 2020 at 6:54 PM Simon Glass wrote: > > > > On Tue, 24 Nov 2020 at 06:57, Andy Shevchenko wrote: > > ... > > > > > Did you get the console working? > > > > > > Nope. The PCI (framebuffer) driver is not getting probed. > > Can you elaborate how Gfx PCI driver is supposed to be enumerated in > the DM model? I think you should be more worried about the UART! If graphics has been started up earlier, then I don't know if you can do it again, nor how you can find out the video parameters to use. I'm guessing you are not using the FSP in U-Boot, so fsp_graphics.c is not being used. Perhaps you have enabled vesa.c but it expects to be able to run the video ROM. There is also drivers/video/coreboot.c which reads a coreboot table to find out where the frame buffer is used. For Broadwell there is a special driver at drivers/video/broadwell_igd.c Note that graphics uses lazy init, like everything else in U-Boot, so unless you have 'vidconsole' in your stdout it won't actually init it. You can use something like this to force probing video: struct udevice *dev; int ret = uclass_first_device_err(UCLASS_VIDEO, &dev); Regards, Simon