We should not set up kernel screen_info when the vesa parameters are
insane, otherwise kernel will panic.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

We should not leave the expansion ROM address window open when there
is not a valid ROM.
Suggested-by: NMatt Porter <mporter@konsulko.com>
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NSimon Glass <sjg@chromium.org>
Acked-by: NSimon Glass <sjg@chromium.org>

Currently PCI expansion ROM address is assigned by a call to
pciauto_setup_rom() outside of the pci auto config process.
This does not work when expansion ROM is on a device behind
PCI bridge where bridge's memory limit register was already
programmed to a value that does not cover the newly assigned
expansion ROM address. To fix this, we should configure the
ROM address during the auto config process.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Tested-by: NSimon Glass <sjg@chromium.org>
Acked-by: NSimon Glass <sjg@chromium.org>

Store VESA parameters to Linux setup header so that vesafb driver
in the kernel could work.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NJian Luo <jian.luo4@boschrexroth.de>

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: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

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: NJian Luo <jian.luo4@boschrexroth.de>
Acked-by: NSimon Glass <sjg@chromium.org>
Tested-by: NBin Meng <bmeng.cn@gmail.com>

pci_rom_load() does not use its parameter 'class', so remove it.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

We should pass a u32 class number to pci_rom_probe() instead of a u16.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

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: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

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: NMinghuan Lian <Minghuan.Lian@freescale.com>

Add code to the generic pci_rom file to access the VGA ROM in PCI space
when needed.
Signed-off-by: NSimon Glass <sjg@chromium.org>

These are quite common and we may as well press on and not be so picky.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

We shouldn't assume that the VGA ROM can always be loaded at c0000. This
is only true on x86 machines.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

This code is too x86-dependent at present. Correct it so that it can run on
big-endian machines.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

The hex value is more commonly understood, so use that instead of decimal.
Add a 0x prefix to avoid confusion.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

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: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

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: NSimon Glass <sjg@chromium.org>

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: NSimon Glass <sjg@chromium.org>