Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-13 14:53:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/pci/pci_rom.c

402 lines
10 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
// SPDX-License-Identifier: GPL-2.0
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
/*
* Copyright (C) 2014 Google, Inc
*
* From coreboot, originally based on the Linux kernel (drivers/pci/pci.c).
*
* Modifications are:
* Copyright (C) 2003-2004 Linux Networx
* (Written by Eric Biederman <ebiederman@lnxi.com> for Linux Networx)
* Copyright (C) 2003-2006 Ronald G. Minnich <rminnich@gmail.com>
* Copyright (C) 2004-2005 Li-Ta Lo <ollie@lanl.gov>
* Copyright (C) 2005-2006 Tyan
* (Written by Yinghai Lu <yhlu@tyan.com> for Tyan)
* Copyright (C) 2005-2009 coresystems GmbH
* (Written by Stefan Reinauer <stepan@coresystems.de> for coresystems GmbH)
*
* PCI Bus Services, see include/linux/pci.h for further explanation.
*
* Copyright 1993 -- 1997 Drew Eckhardt, Frederic Potter,
* David Mosberger-Tang
*
* Copyright 1997 -- 1999 Martin Mares <mj@atrey.karlin.mff.cuni.cz>
*/
video: pci: Set up the copy framebuffer When using a copy framebuffer we need to tell the video subsystem its address. U-Boot's normally allocated framebuffer is used as the working buffer, but nothing is displayed until it is copied to the copy framebuffer. For this to work the video driver must request that a framebuffer be allocated separately from the hardware framebuffer, so add a check for that. Also add a log category so that logging appears correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-03 03:12:30 +00:00
#define LOG_CATEGORY UCLASS_PCI
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
#include <common.h>
#include <bios_emul.h>
common: Drop bootstage.h from common header Move this fairly uncommon header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 17:40:00 +00:00
#include <bootstage.h>
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
#include <dm.h>
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
#include <errno.h>
common: Move ll_boot_init() to init.h This is an init-related function so belongs in that file. Move it. Signed-off-by: Simon Glass <sjg@chromium.org>
2019-12-28 17:44:56 +00:00
#include <init.h>
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-10 17:40:05 +00:00
#include <log.h>
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
#include <malloc.h>
#include <pci.h>
#include <pci_rom.h>
video: Renname vbe.h to vesa.h We want to use VBE to mean Verfiied Boot for Embedded in U-Boot. Rename the existing VBE (Vesa BIOS extensions) to allow this. Verified Boot for Embedded is documented doc/develop/vbe.rst Signed-off-by: Simon Glass <sjg@chromium.org>
2022-07-30 21:52:04 +00:00
#include <vesa.h>
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
#include <video.h>
x86: Move acpi_s3.h to include/acpi/ This header relates to ACPI and we are about to add some more ACPI headers. Move this one into a new directory so they are together. The header inclusion in pci_rom.c is not specific to x86 anymore, so drop the #ifdef CONFIG_X86. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-04-08 22:57:35 +00:00
#include <acpi/acpi_s3.h>
common: Drop asm/global_data.h from common header Move this out of the common header and include it only where needed. In a number of cases this requires adding "struct udevice;" to avoid adding another large header or in other cases replacing / adding missing header files that had been pulled in, very indirectly. Finally, we have a few cases where we did not need to include <asm/global_data.h> at all, so remove that include. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2020-10-31 03:38:53 +00:00
#include <asm/global_data.h>
x86: Configure VESA parameters before loading Linux kernel Store VESA parameters to Linux setup header so that vesafb driver in the kernel could work. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Jian Luo <jian.luo4@boschrexroth.de>
2015-07-06 08:31:36 +00:00
#include <linux/screen_info.h>
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
x86: pci: Allow conditionally run VGA rom in S3 Introduce a new CONFIG_S3_VGA_ROM_RUN option so that U-Boot can bypass executing VGA roms in S3. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
2017-04-21 14:24:46 +00:00
DECLARE_GLOBAL_DATA_PTR;
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
__weak bool board_should_run_oprom(struct udevice *dev)
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
{
x86: pci: Allow conditionally run VGA rom in S3 Introduce a new CONFIG_S3_VGA_ROM_RUN option so that U-Boot can bypass executing VGA roms in S3. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de>
2017-04-21 14:24:46 +00:00
#if defined(CONFIG_X86) && defined(CONFIG_HAVE_ACPI_RESUME)
if (gd->arch.prev_sleep_state == ACPI_S3) {
if (IS_ENABLED(CONFIG_S3_VGA_ROM_RUN))
return true;
else
return false;
}
#endif
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
return true;
}
pci: Add board_ prefix to should_load_oprom() and make it weak For consistency with board_should_run_oprom(), do the same to should_load_oprom(). Board support codes can provide this one to override the default weak one. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-06-14 09:02:40 +00:00
__weak bool board_should_load_oprom(struct udevice *dev)
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
{
pci: Make load_oprom and run_oprom independent At present should_load_oprom() calls board_should_run_oprom() to determine whether oprom should be loaded. But sometimes we just want to load oprom without running. Make them independent. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-06-14 09:02:39 +00:00
return true;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
}
__weak uint32_t board_map_oprom_vendev(uint32_t vendev)
{
return vendev;
}
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
static int pci_rom_probe(struct udevice *dev, struct pci_rom_header **hdrp)
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
{
dm: treewide: Rename ..._platdata variables to just ..._plat Try to maintain some consistency between these variables by using _plat as a suffix for them. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-03 23:55:23 +00:00
struct pci_child_plat *pplat = dev_get_parent_plat(dev);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
struct pci_rom_header *rom_header;
struct pci_rom_data *rom_data;
x86: Correct endianness isues in pci_rom This code is too x86-dependent at present. Correct it so that it can run on big-endian machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:23 +00:00
u16 rom_vendor, rom_device;
pci: Option rom class is a 24-bit number We should pass a u32 class number to pci_rom_probe() instead of a u16. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-24 07:48:03 +00:00
u32 rom_class;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
u32 vendev;
u32 mapped_vendev;
u32 rom_address;
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
vendev = pplat->vendor << 16 | pplat->device;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
mapped_vendev = board_map_oprom_vendev(vendev);
if (vendev != mapped_vendev)
debug("Device ID mapped to %#08x\n", mapped_vendev);
x86: Move VGA option rom macros to Kconfig Move X86_OPTION_ROM_FILE & X86_OPTION_ROM_ADDR to arch/x86/Kconfig and rename them to VGA_BIOS_FILE & VGA_BIOS_ADDR which depend on HAVE_VGA_BIOS. The new names are consistent with other x86 binary blob options like HAVE_FSP/FSP_FILE/FSP_ADDR. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-06 08:31:33 +00:00
#ifdef CONFIG_VGA_BIOS_ADDR
rom_address = CONFIG_VGA_BIOS_ADDR;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
#else
x86: Access the VGA ROM when needed Add code to the generic pci_rom file to access the VGA ROM in PCI space when needed. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-15 04:37:04 +00:00
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
dm_pci_read_config32(dev, PCI_ROM_ADDRESS, &rom_address);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
if (rom_address == 0x00000000 || rom_address == 0xffffffff) {
debug("%s: rom_address=%x\n", __func__, rom_address);
return -ENOENT;
}
/* Enable expansion ROM address decoding. */
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
dm_pci_write_config32(dev, PCI_ROM_ADDRESS,
rom_address | PCI_ROM_ADDRESS_ENABLE);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
#endif
debug("Option ROM address %x\n", rom_address);
drivers/pci/pci_rom.c: fix compile warning under 64bit mode Fix this: drivers/pci/pci_rom.c:95:15: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] rom_header = (struct pci_rom_header *)rom_address; Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
2015-01-22 05:21:55 +00:00
rom_header = (struct pci_rom_header *)(unsigned long)rom_address;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
debug("PCI expansion ROM, signature %#04x, INIT size %#04x, data ptr %#04x\n",
x86: Correct endianness isues in pci_rom This code is too x86-dependent at present. Correct it so that it can run on big-endian machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:23 +00:00
le16_to_cpu(rom_header->signature),
rom_header->size * 512, le16_to_cpu(rom_header->data));
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
x86: Correct endianness isues in pci_rom This code is too x86-dependent at present. Correct it so that it can run on big-endian machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:23 +00:00
if (le16_to_cpu(rom_header->signature) != PCI_ROM_HDR) {
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
printf("Incorrect expansion ROM header signature %04x\n",
x86: Correct endianness isues in pci_rom This code is too x86-dependent at present. Correct it so that it can run on big-endian machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:23 +00:00
le16_to_cpu(rom_header->signature));
pci: Disable expansion ROM address decoding when signature check fails We should not leave the expansion ROM address window open when there is not a valid ROM. Suggested-by: Matt Porter <mporter@konsulko.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-08 05:06:41 +00:00
#ifndef CONFIG_VGA_BIOS_ADDR
/* Disable expansion ROM address decoding */
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
dm_pci_write_config32(dev, PCI_ROM_ADDRESS, rom_address);
pci: Disable expansion ROM address decoding when signature check fails We should not leave the expansion ROM address window open when there is not a valid ROM. Suggested-by: Matt Porter <mporter@konsulko.com> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-08 05:06:41 +00:00
#endif
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
return -EINVAL;
}
x86: Correct endianness isues in pci_rom This code is too x86-dependent at present. Correct it so that it can run on big-endian machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:23 +00:00
rom_data = (((void *)rom_header) + le16_to_cpu(rom_header->data));
rom_vendor = le16_to_cpu(rom_data->vendor);
rom_device = le16_to_cpu(rom_data->device);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
debug("PCI ROM image, vendor ID %04x, device ID %04x,\n",
x86: Correct endianness isues in pci_rom This code is too x86-dependent at present. Correct it so that it can run on big-endian machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:23 +00:00
rom_vendor, rom_device);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
/* If the device id is mapped, a mismatch is expected */
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
if ((pplat->vendor != rom_vendor || pplat->device != rom_device) &&
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
(vendev == mapped_vendev)) {
printf("ID mismatch: vendor ID %04x, device ID %04x\n",
x86: Correct endianness isues in pci_rom This code is too x86-dependent at present. Correct it so that it can run on big-endian machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:23 +00:00
rom_vendor, rom_device);
x86: pci: Don't stop when we get a vendor/device mismatch These are quite common and we may as well press on and not be so picky. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:27 +00:00
/* Continue anyway */
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
}
pci: Option rom class is a 24-bit number We should pass a u32 class number to pci_rom_probe() instead of a u16. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-24 07:48:03 +00:00
rom_class = (le16_to_cpu(rom_data->class_hi) << 8) | rom_data->class_lo;
debug("PCI ROM image, Class Code %06x, Code Type %02x\n",
rom_class, rom_data->type);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
if (pplat->class != rom_class) {
pci: Option rom class is a 24-bit number We should pass a u32 class number to pci_rom_probe() instead of a u16. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-24 07:48:03 +00:00
debug("Class Code mismatch ROM %06x, dev %06x\n",
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
rom_class, pplat->class);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
}
*hdrp = rom_header;
return 0;
}
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
/**
* pci_rom_load() - Load a ROM image and return a pointer to it
*
* @rom_header: Pointer to ROM image
* @ram_headerp: Returns a pointer to the image in RAM
* @allocedp: Returns true if @ram_headerp was allocated and needs
* to be freed
doc: replace @return by Return: Sphinx expects Return: and not @return to indicate a return value. find . -name '*.c' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; find . -name '*.h' -exec \ sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \; Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-19 17:05:50 +00:00
* Return: 0 if OK, -ve on error. Note that @allocedp is set up regardless of
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
* the error state. Even if this function returns an error, it may have
* allocated memory.
*/
static int pci_rom_load(struct pci_rom_header *rom_header,
struct pci_rom_header **ram_headerp, bool *allocedp)
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
{
struct pci_rom_data *rom_data;
unsigned int rom_size;
unsigned int image_size = 0;
void *target;
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
*allocedp = false;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
do {
/* Get next image, until we see an x86 version */
rom_header = (struct pci_rom_header *)((void *)rom_header +
image_size);
rom_data = (struct pci_rom_data *)((void *)rom_header +
x86: Correct endianness isues in pci_rom This code is too x86-dependent at present. Correct it so that it can run on big-endian machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:23 +00:00
le16_to_cpu(rom_header->data));
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
x86: Correct endianness isues in pci_rom This code is too x86-dependent at present. Correct it so that it can run on big-endian machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:23 +00:00
image_size = le16_to_cpu(rom_data->ilen) * 512;
} while ((rom_data->type != 0) && (rom_data->indicator == 0));
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
if (rom_data->type != 0)
return -EACCES;
rom_size = rom_header->size * 512;
x86: Support ROMs on other archs We shouldn't assume that the VGA ROM can always be loaded at c0000. This is only true on x86 machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:24 +00:00
#ifdef PCI_VGA_RAM_IMAGE_START
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
target = (void *)PCI_VGA_RAM_IMAGE_START;
x86: Support ROMs on other archs We shouldn't assume that the VGA ROM can always be loaded at c0000. This is only true on x86 machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:24 +00:00
#else
target = (void *)malloc(rom_size);
if (!target)
return -ENOMEM;
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
*allocedp = true;
x86: Support ROMs on other archs We shouldn't assume that the VGA ROM can always be loaded at c0000. This is only true on x86 machines. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2014-12-30 02:32:24 +00:00
#endif
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
if (target != rom_header) {
x86: video: Add debug option to time the BIOS copy This can be very slow - typically 80ms even on a fast machine since it uses the SPI flash to read the data. Add an option to display the time taken. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-01 23:18:01 +00:00
ulong start = get_timer(0);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
debug("Copying VGA ROM Image from %p to %p, 0x%x bytes\n",
rom_header, target, rom_size);
memcpy(target, rom_header, rom_size);
if (memcmp(target, rom_header, rom_size)) {
printf("VGA ROM copy failed\n");
return -EFAULT;
}
x86: video: Add debug option to time the BIOS copy This can be very slow - typically 80ms even on a fast machine since it uses the SPI flash to read the data. Add an option to display the time taken. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-01 23:18:01 +00:00
debug("Copy took %lums\n", get_timer(start));
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
}
*ram_headerp = target;
return 0;
}
video: Rename structs and functions to avoid VBE Rename these to VESA, itself an abbreviation, to avoid a conflict with Verified Boot for Embedded. Rename this to avoid referencing VBE. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-07-30 21:52:05 +00:00
struct vesa_state mode_info;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
x86: Configure VESA parameters before loading Linux kernel Store VESA parameters to Linux setup header so that vesafb driver in the kernel could work. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Jian Luo <jian.luo4@boschrexroth.de>
2015-07-06 08:31:36 +00:00
void setup_video(struct screen_info *screen_info)
{
struct vesa_mode_info *vesa = &mode_info.vesa;
x86: Sanity test on vesa parameters before setting up kernel screen_info We should not set up kernel screen_info when the vesa parameters are insane, otherwise kernel will panic. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-07-30 10:49:13 +00:00
/* Sanity test on VESA parameters */
if (!vesa->x_resolution || !vesa->y_resolution)
return;
x86: Configure VESA parameters before loading Linux kernel Store VESA parameters to Linux setup header so that vesafb driver in the kernel could work. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Jian Luo <jian.luo4@boschrexroth.de>
2015-07-06 08:31:36 +00:00
screen_info->orig_video_isVGA = VIDEO_TYPE_VLFB;
screen_info->lfb_width = vesa->x_resolution;
screen_info->lfb_height = vesa->y_resolution;
screen_info->lfb_depth = vesa->bits_per_pixel;
screen_info->lfb_linelength = vesa->bytes_per_scanline;
screen_info->lfb_base = vesa->phys_base_ptr;
screen_info->lfb_size =
ALIGN(screen_info->lfb_linelength * screen_info->lfb_height,
65536);
screen_info->lfb_size >>= 16;
screen_info->red_size = vesa->red_mask_size;
screen_info->red_pos = vesa->red_mask_pos;
screen_info->green_size = vesa->green_mask_size;
screen_info->green_pos = vesa->green_mask_pos;
screen_info->blue_size = vesa->blue_mask_size;
screen_info->blue_pos = vesa->blue_mask_pos;
screen_info->rsvd_size = vesa->reserved_mask_size;
screen_info->rsvd_pos = vesa->reserved_mask_pos;
}
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
int dm_pci_run_vga_bios(struct udevice *dev, int (*int15_handler)(void),
int exec_method)
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
{
dm: treewide: Rename ..._platdata variables to just ..._plat Try to maintain some consistency between these variables by using _plat as a suffix for them. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-03 23:55:23 +00:00
struct pci_child_plat *pplat = dev_get_parent_plat(dev);
pci_rom: fix may be used uninitialized warning Building pci_rom.c with my toolchain complains about may be used uninitialized rom varaible: ---8<--- +drivers/pci/pci_rom.c:269:25: note: 'rom' was declared here w+drivers/pci/pci_rom.c: In function 'dm_pci_run_vga_bios': w+drivers/pci/pci_rom.c:154:14: warning: 'rom' may be used uninitialized in this function [-Wmaybe-uninitialized] --->8--- Fix this as done in 55616b86c745fcac5a791268ab8e7cba36965c0f the ram variable. Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com> Acked-by: Anatolij Gustschin <agust@denx.de>
2016-02-16 22:29:31 +00:00
struct pci_rom_header *rom = NULL, *ram = NULL;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
int vesa_mode = -1;
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
bool emulate, alloced;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
int ret;
/* Only execute VGA ROMs */
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
if (((pplat->class >> 8) ^ PCI_CLASS_DISPLAY_VGA) & 0xff00) {
debug("%s: Class %#x, should be %#x\n", __func__, pplat->class,
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
PCI_CLASS_DISPLAY_VGA);
return -ENODEV;
}
pci: Add board_ prefix to should_load_oprom() and make it weak For consistency with board_should_run_oprom(), do the same to should_load_oprom(). Board support codes can provide this one to override the default weak one. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-06-14 09:02:40 +00:00
if (!board_should_load_oprom(dev))
pci: Add a little more debugging to pci_rom Add some logging on failure. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-10-01 18:22:44 +00:00
return log_msg_ret("Should not load OPROM", -ENXIO);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
dm: pci: video: Convert video and pci_rom to use DM PCI API Adjust these files to use the driver-model PCI API instead of the legacy functions. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:57 +00:00
ret = pci_rom_probe(dev, &rom);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
if (ret)
return ret;
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
ret = pci_rom_load(rom, &ram, &alloced);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
if (ret)
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
goto err;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
if (!board_should_run_oprom(dev)) {
ret = -ENXIO;
goto err;
}
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
#if defined(CONFIG_FRAMEBUFFER_SET_VESA_MODE) && \
defined(CONFIG_FRAMEBUFFER_VESA_MODE)
vesa_mode = CONFIG_FRAMEBUFFER_VESA_MODE;
#endif
x86: pci: Display vesa modes in hex The hex value is more commonly understood, so use that instead of decimal. Add a 0x prefix to avoid confusion. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-01 23:18:05 +00:00
debug("Selected vesa mode %#x\n", vesa_mode);
x86: video: Allow video ROM execution to fall back to the other method If the BIOS emulator is not available, allow use of native execution if available, and vice versa. This can be controlled by the caller. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:34 +00:00
if (exec_method & PCI_ROM_USE_NATIVE) {
#ifdef CONFIG_X86
emulate = false;
#else
if (!(exec_method & PCI_ROM_ALLOW_FALLBACK)) {
printf("BIOS native execution is only available on x86\n");
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
ret = -ENOSYS;
goto err;
x86: video: Allow video ROM execution to fall back to the other method If the BIOS emulator is not available, allow use of native execution if available, and vice versa. This can be controlled by the caller. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:34 +00:00
}
emulate = true;
#endif
} else {
#ifdef CONFIG_BIOSEMU
emulate = true;
#else
if (!(exec_method & PCI_ROM_ALLOW_FALLBACK)) {
printf("BIOS emulation not available - see CONFIG_BIOSEMU\n");
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
ret = -ENOSYS;
goto err;
x86: video: Allow video ROM execution to fall back to the other method If the BIOS emulator is not available, allow use of native execution if available, and vice versa. This can be controlled by the caller. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-28 05:13:34 +00:00
}
emulate = false;
#endif
}
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
if (emulate) {
#ifdef CONFIG_BIOSEMU
BE_VGAInfo *info;
dm: pci: Convert bios_emu to use the driver model PCI API At present this BIOS emulator uses a bus/device/function number. Change it to use a device if CONFIG_DM_PCI is enabled. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-01-17 23:11:09 +00:00
ret = biosemu_setup(dev, &info);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
if (ret)
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
goto err;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
biosemu_set_interrupt_handler(0x15, int15_handler);
dm: pci: Convert bios_emu to use the driver model PCI API At present this BIOS emulator uses a bus/device/function number. Change it to use a device if CONFIG_DM_PCI is enabled. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-01-17 23:11:09 +00:00
ret = biosemu_run(dev, (uchar *)ram, 1 << 16, info,
true, vesa_mode, &mode_info);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
if (ret)
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
goto err;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
#endif
} else {
x86: Support PCI VGA ROM when TPL is used When TPL is in use, U-Boot proper should support initing the VGA ROM even though the 32-bit init portion is in SPL. Update the condition to handle this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-04-26 03:59:08 +00:00
#if defined(CONFIG_X86) && (CONFIG_IS_ENABLED(X86_32BIT_INIT) || CONFIG_TPL)
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
bios_set_interrupt_handler(0x15, int15_handler);
dm: x86: pci: Adjust bios_run_on_x86() to use the DM PCI API This function should take a struct udevice rather than pci_dev_t. Update it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-29 20:17:58 +00:00
bios_run_on_x86(dev, (unsigned long)ram, vesa_mode,
&mode_info);
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
#endif
}
x86: pci: Display vesa modes in hex The hex value is more commonly understood, so use that instead of decimal. Add a 0x prefix to avoid confusion. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-01-01 23:18:05 +00:00
debug("Final vesa mode %#x\n", mode_info.video_mode);
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
ret = 0;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
dm: pci: Avoid a memory leak when allocating the ROM Adjust pci_rom_load() to return an indication of whether it allocated memory or not. Adjust the caller to free it. This fixes a memory leak when PCI_VGA_RAM_IMAGE_START is not used. Reported-by: Coverity (CID: 134194) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 12:23:22 +00:00
err:
if (alloced)
free(ram);
return ret;
pci: Add general support for execution of video ROMs Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
2014-11-15 03:56:33 +00:00
}
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
efi: Support a 64-bit frame buffer address The current vesa structure only provides a 32-bit value for the frame buffer. Many modern machines use an address outside the range. It is still useful to have this common struct, but add a separate frame-buffer address as well. Add a comment for vesa_setup_video_priv() while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-03-10 20:47:13 +00:00
int vesa_setup_video_priv(struct vesa_mode_info *vesa, u64 fb,
video: Rename structs and functions to avoid VBE Rename these to VESA, itself an abbreviation, to avoid a conflict with Verified Boot for Embedded. Rename this to avoid referencing VBE. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-07-30 21:52:05 +00:00
struct video_priv *uc_priv,
struct video_uc_plat *plat)
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
{
if (!vesa->x_resolution)
pci: Add a little more debugging to pci_rom Add some logging on failure. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2018-10-01 18:22:44 +00:00
return log_msg_ret("No x resolution", -ENXIO);
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
uc_priv->xsize = vesa->x_resolution;
uc_priv->ysize = vesa->y_resolution;
video: Allow driver to specify the line length At present line_length is always calculated in video_post_probe(). But some hardware may use a different line length, e.g. with a 1366-wide display. Allow the driver to set this value if needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de>
2018-11-29 22:08:52 +00:00
uc_priv->line_length = vesa->bytes_per_scanline;
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
switch (vesa->bits_per_pixel) {
case 32:
case 24:
uc_priv->bpix = VIDEO_BPP32;
break;
case 16:
uc_priv->bpix = VIDEO_BPP16;
break;
default:
return -EPROTONOSUPPORT;
}
video: pci: Set up the copy framebuffer When using a copy framebuffer we need to tell the video subsystem its address. U-Boot's normally allocated framebuffer is used as the working buffer, but nothing is displayed until it is copied to the copy framebuffer. For this to work the video driver must request that a framebuffer be allocated separately from the hardware framebuffer, so add a check for that. Also add a log category so that logging appears correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-03 03:12:30 +00:00
/* Use double buffering if enabled */
video: Fix video on coreboot with the copy buffer The copy buffer, if enabled, prevents booting from coreboot correctly, since no memory is allocated for it. Allow it to fall back to disabled in this situation. This ensures that a console is displayed, even if it is slow. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-15 05:00:26 +00:00
if (IS_ENABLED(CONFIG_VIDEO_COPY) && plat->base)
efi: Support a 64-bit frame buffer address The current vesa structure only provides a 32-bit value for the frame buffer. Many modern machines use an address outside the range. It is still useful to have this common struct, but add a separate frame-buffer address as well. Add a comment for vesa_setup_video_priv() while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-03-10 20:47:13 +00:00
plat->copy_base = fb;
video: Fix video on coreboot with the copy buffer The copy buffer, if enabled, prevents booting from coreboot correctly, since no memory is allocated for it. Allow it to fall back to disabled in this situation. This ensures that a console is displayed, even if it is slow. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-03-15 05:00:26 +00:00
else
efi: Support a 64-bit frame buffer address The current vesa structure only provides a 32-bit value for the frame buffer. Many modern machines use an address outside the range. It is still useful to have this common struct, but add a separate frame-buffer address as well. Add a comment for vesa_setup_video_priv() while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-03-10 20:47:13 +00:00
plat->base = fb;
video: pci: Set up the copy framebuffer When using a copy framebuffer we need to tell the video subsystem its address. U-Boot's normally allocated framebuffer is used as the working buffer, but nothing is displayed until it is copied to the copy framebuffer. For this to work the video driver must request that a framebuffer be allocated separately from the hardware framebuffer, so add a check for that. Also add a log category so that logging appears correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-03 03:12:30 +00:00
log_debug("base = %lx, copy_base = %lx\n", plat->base, plat->copy_base);
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
plat->size = vesa->bytes_per_scanline * vesa->y_resolution;
return 0;
}
video: Rename structs and functions to avoid VBE Rename these to VESA, itself an abbreviation, to avoid a conflict with Verified Boot for Embedded. Rename this to avoid referencing VBE. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-07-30 21:52:05 +00:00
int vesa_setup_video(struct udevice *dev, int (*int15_handler)(void))
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
{
dm: treewide: Rename ..._platdata variables to just ..._plat Try to maintain some consistency between these variables by using _plat as a suffix for them. Signed-off-by: Simon Glass <sjg@chromium.org>
2020-12-03 23:55:23 +00:00
struct video_uc_plat *plat = dev_get_uclass_plat(dev);
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
int ret;
/* If we are running from EFI or coreboot, this can't work */
dm: video: Output verbose information in vbe_setup_video() With DM conversion, information like "Video: 1024x768x16" is not shown anymore. Now add these verbose output back. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-09 11:14:12 +00:00
if (!ll_boot_init()) {
printf("Not available (previous bootloader prevents it)\n");
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
return -EPERM;
dm: video: Output verbose information in vbe_setup_video() With DM conversion, information like "Video: 1024x768x16" is not shown anymore. Now add these verbose output back. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-09 11:14:12 +00:00
}
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
bootstage_start(BOOTSTAGE_ID_ACCUM_LCD, "vesa display");
ret = dm_pci_run_vga_bios(dev, int15_handler, PCI_ROM_USE_NATIVE |
PCI_ROM_ALLOW_FALLBACK);
bootstage_accum(BOOTSTAGE_ID_ACCUM_LCD);
if (ret) {
debug("failed to run video BIOS: %d\n", ret);
return ret;
}
efi: Support a 64-bit frame buffer address The current vesa structure only provides a 32-bit value for the frame buffer. Many modern machines use an address outside the range. It is still useful to have this common struct, but add a separate frame-buffer address as well. Add a comment for vesa_setup_video_priv() while we are here. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-03-10 20:47:13 +00:00
ret = vesa_setup_video_priv(&mode_info.vesa,
mode_info.vesa.phys_base_ptr, uc_priv,
plat);
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
if (ret) {
video: pci: Set up the copy framebuffer When using a copy framebuffer we need to tell the video subsystem its address. U-Boot's normally allocated framebuffer is used as the working buffer, but nothing is displayed until it is copied to the copy framebuffer. For this to work the video driver must request that a framebuffer be allocated separately from the hardware framebuffer, so add a check for that. Also add a log category so that logging appears correctly. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-03 03:12:30 +00:00
if (ret == -ENFILE) {
/*
* See video-uclass.c for how to set up reserved memory
* in your video driver
*/
log_err("CONFIG_VIDEO_COPY enabled but driver '%s' set up no reserved memory\n",
dev->driver->name);
}
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
debug("No video mode configured\n");
return ret;
}
pci: video: Only print out when everything is OK If video initialization fails, the "Video:" output message will be mixed with the next console log. Change to print out such message only when everything is OK, which improves the boot log readability. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-04-12 05:02:18 +00:00
printf("Video: %dx%dx%d\n", uc_priv->xsize, uc_priv->ysize,
dm: video: Output verbose information in vbe_setup_video() With DM conversion, information like "Video: 1024x768x16" is not shown anymore. Now add these verbose output back. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-09 11:14:12 +00:00
mode_info.vesa.bits_per_pixel);
dm: video: Add driver-model support to vesa graphics Provide a function to run the Vesa BIOS for a given PCI device and obtain the resulting configuration (e.g. display size) for use by the video uclass. This makes it easier to write a video driver that uses vesa and supports driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2016-10-06 02:42:17 +00:00
return 0;
}
Reference in a new issue Copy permalink