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

344 lines
8.7 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>
#include <errno.h>
#include <malloc.h>
#include <pci.h>
#include <pci_rom.h>
#include <vbe.h>
#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
#ifdef CONFIG_HAVE_ACPI_RESUME
#include <asm/acpi.h>
#endif
__weak bool board_should_run_oprom(pci_dev_t dev)
{
return true;
}
static bool should_load_oprom(pci_dev_t dev)
{
#ifdef CONFIG_HAVE_ACPI_RESUME
if (acpi_get_slp_type() == 3)
return false;
#endif
if (IS_ENABLED(CONFIG_ALWAYS_LOAD_OPROM))
return 1;
if (board_should_run_oprom(dev))
return 1;
return 0;
}
__weak uint32_t board_map_oprom_vendev(uint32_t vendev)
{
return vendev;
}
static int pci_rom_probe(pci_dev_t dev, uint class,
struct pci_rom_header **hdrp)
{
struct pci_rom_header *rom_header;
struct pci_rom_data *rom_data;
u16 vendor, device;
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;
pci_read_config_word(dev, PCI_VENDOR_ID, &vendor);
pci_read_config_word(dev, PCI_DEVICE_ID, &device);
vendev = vendor << 16 | device;
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
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_read_config_dword(dev, PCI_ROM_ADDRESS, &rom_address);
if (rom_address == 0x00000000 || rom_address == 0xffffffff) {
debug("%s: rom_address=%x\n", __func__, rom_address);
return -ENOENT;
}
/* Enable expansion ROM address decoding. */
pci_write_config_dword(dev, PCI_ROM_ADDRESS,
rom_address | PCI_ROM_ADDRESS_ENABLE);
#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 */
pci_write_config_dword(dev, PCI_ROM_ADDRESS, rom_address);
#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 */
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 ((vendor != rom_vendor || 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
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
if (class != rom_class) {
debug("Class Code mismatch ROM %06x, dev %06x\n",
rom_class, 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;
}
pci: Remove parameter 'class' of pci_rom_load() pci_rom_load() does not use its parameter 'class', so remove it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-24 07:48:04 +00:00
int pci_rom_load(struct pci_rom_header *rom_header,
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 **ram_headerp)
{
struct pci_rom_data *rom_data;
unsigned int rom_size;
unsigned int image_size = 0;
void *target;
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;
#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;
}
static struct vbe_mode_info mode_info;
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)
{
#ifdef CONFIG_FRAMEBUFFER_SET_VESA_MODE
struct vesa_mode_info *vesa = &mode_info.vesa;
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;
#endif
}
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
int pci_run_vga_bios(pci_dev_t 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
{
struct pci_rom_header *rom, *ram;
int vesa_mode = -1;
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
uint class;
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
bool emulate;
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 */
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
pci_read_config_dword(dev, PCI_REVISION_ID, &class);
if (((class >> 16) ^ PCI_CLASS_DISPLAY_VGA) & 0xff00) {
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("%s: Class %#x, should be %#x\n", __func__, class,
PCI_CLASS_DISPLAY_VGA);
return -ENODEV;
}
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
class >>= 8;
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 (!should_load_oprom(dev))
return -ENXIO;
ret = pci_rom_probe(dev, class, &rom);
if (ret)
return ret;
pci: Remove parameter 'class' of pci_rom_load() pci_rom_load() does not use its parameter 'class', so remove it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-04-24 07:48:04 +00:00
ret = pci_rom_load(rom, &ram);
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;
if (!board_should_run_oprom(dev))
return -ENXIO;
#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");
return -ENOSYS;
}
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");
return -ENOSYS;
}
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;
ret = biosemu_setup(dev, &info);
if (ret)
return ret;
biosemu_set_interrupt_handler(0x15, int15_handler);
ret = biosemu_run(dev, (uchar *)ram, 1 << 16, info, true,
vesa_mode, &mode_info);
if (ret)
return ret;
#endif
} else {
#ifdef CONFIG_X86
bios_set_interrupt_handler(0x15, int15_handler);
bios_run_on_x86(dev, (unsigned long)ram, vesa_mode,
&mode_info);
#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);
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 0;
}
Reference in a new issue Copy permalink