From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Wed, 25 Nov 2020 08:23:11 -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 08:07, Andy Shevchenko wrote: > > On Wed, Nov 25, 2020 at 4:50 PM Simon Glass wrote: > > 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! > > How? There is no UART (there are ports, but all of them are occupied > by real devices wired up). The only connector is microB and getting > USB to work in a gadget mode seems to me a harder task to achieve. The board designers should be severely punished. Do you have post codes? Some boards have an FTDI chip to do the USB/serial conversion but I guess your one does not. > > > 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. > > That is my question, how to start a PCI subsystem in U-Boot. > In DM model it seems some should actually call one of PCI function > against device. AFAIU the vidconsole driver should find somehow the > adapter in DT or so and load > > > I'm guessing you are not using the FSP in U-Boot, so fsp_graphics.c is > > not being used. > > No, it's not. > > > Perhaps you have enabled vesa.c but it expects to be > > able to run the video ROM. > > There is no video ROM as far as I can tell. > > > 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. > > I have no environment for now (ENV_IS_NO_WHERE) and I have provided > > #define CONFIG_STD_DEVICES_SETTINGS "stdin=serial\0" \ > "stdout=vidconsole\0" \ > "stderr=vidconsole\0" > > in the configuration header. Not sure if it's correct and/or enough. Should be fine. > > > You can use something like this to force probing video: > > > > struct udevice *dev; > > int ret = uclass_first_device_err(UCLASS_VIDEO, &dev); > > I will try this, thanks! But you'll need to select the driver, or write one that finds the frame buffer. Is video already set up by the earlier loader? Regards, Simon