Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-18 10:48:51 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/drivers/pci/pci_rom.c

413 lines
11 KiB
C
Raw Normal View History

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>
* SPDX-License-Identifier: GPL-2.0
*/
#include <common.h>
#include <bios_emul.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>
#include <malloc.h>
#include <pci.h>
#include <pci_rom.h>
#include <vbe.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>
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 <video_fb.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
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
{
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: 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
struct pci_child_platdata *pplat = dev_get_parent_platdata(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
* @return 0 if OK, -ve on error. Note that @allocedp is set up regardless of
* 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: coreboot: Save VESA mode for future use When booting as a coreboot payload, the framebuffer details are passed from coreboot via configuration tables. We save these information into vesa_mode_info structure for future use. Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2015-08-13 07:29:16 +00:00
struct vbe_mode_info 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
int vbe_get_video_info(struct graphic_device *gdev)
{
#ifdef CONFIG_FRAMEBUFFER_SET_VESA_MODE
struct vesa_mode_info *vesa = &mode_info.vesa;
gdev->winSizeX = vesa->x_resolution;
gdev->winSizeY = vesa->y_resolution;
gdev->plnSizeX = vesa->x_resolution;
gdev->plnSizeY = vesa->y_resolution;
gdev->gdfBytesPP = vesa->bits_per_pixel / 8;
switch (vesa->bits_per_pixel) {
video: Add 32-bit color depth support for VBE The TunnelCreek IGD VBE reports 32-bit color depth regardless 24-bit color depth is configured. Since 24-bit mode already uses 4 bytes internally, it should be OK to just add this option in switch case. Signed-off-by: Jian Luo <jian.luo4@boschrexroth.de> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Bin Meng <bmeng.cn@gmail.com>
2015-07-06 08:31:29 +00:00
case 32:
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
case 24:
gdev->gdfIndex = GDF_32BIT_X888RGB;
break;
case 16:
gdev->gdfIndex = GDF_16BIT_565RGB;
break;
default:
gdev->gdfIndex = GDF__8BIT_INDEX;
break;
}
gdev->isaBase = CONFIG_SYS_ISA_IO_BASE_ADDRESS;
gdev->pciBase = vesa->phys_base_ptr;
gdev->frameAdrs = vesa->phys_base_ptr;
gdev->memSize = vesa->bytes_per_scanline * vesa->y_resolution;
gdev->vprBase = vesa->phys_base_ptr;
gdev->cprBase = vesa->phys_base_ptr;
x86: pci: Don't return a vesa mode when there is not video If the video has not been set up, we should not return a success code. This can be detected by seeing if any of the variables are non-zero. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-01-01 23:18:00 +00:00
return gdev->winSizeX ? 0 : -ENOSYS;
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
return -ENOSYS;
#endif
}
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: 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
struct pci_child_platdata *pplat = dev_get_parent_platdata(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 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 -ENXIO;
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: Don't try to run the VGA BIOS in 64-bit mode This is not supported, so disable it for now. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-01-16 14:04:09 +00:00
#if defined(CONFIG_X86) && CONFIG_IS_ENABLED(X86_32BIT_INIT)
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
#ifdef CONFIG_DM_VIDEO
vbe: Make vbe_setup_video_priv() public vbe_setup_video_priv() might be useful to other drivers. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2016-10-09 11:14:15 +00:00
int vbe_setup_video_priv(struct vesa_mode_info *vesa,
struct video_priv *uc_priv,
struct video_uc_platdata *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)
return -ENXIO;
uc_priv->xsize = vesa->x_resolution;
uc_priv->ysize = vesa->y_resolution;
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;
}
plat->base = vesa->phys_base_ptr;
plat->size = vesa->bytes_per_scanline * vesa->y_resolution;
return 0;
}
int vbe_setup_video(struct udevice *dev, int (*int15_handler)(void))
{
struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
int ret;
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
printf("Video: ");
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 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;
}
ret = vbe_setup_video_priv(&mode_info.vesa, uc_priv, plat);
if (ret) {
debug("No video mode configured\n");
return ret;
}
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
printf("%dx%dx%d\n", uc_priv->xsize, uc_priv->ysize,
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;
}
#endif
Reference in a new issue Copy permalink