summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
...
* | ARM: DRA74-evm: Use SMA_1 spare register to workaround DP83865 phy on SR2.0Nishanth Menon2015-08-28-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DP83865 ethernet phy used on DRA74x-evm is quirky and the datasheet provided IODELAY values for standard RGMII phys do not work. Silicon Revision(SR) 2.0 provides an alternative bit configuration that allows us to do a "gross adjustment" to launch the data off a different internal clock edge. Manual IO Delay overrides are still necessary to fine tune the clock-to-data delays. This is a necessary workaround for the quirky ethernet Phy we have on the platform. NOTE: SMA registers are spare "kitchen sink" registers that does contain bits for other workaround as necessary as well. Hence the control for the same is introduced in a generic SoC specific, board generic location. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* | ARM: DRA74-evm: Add iodelay values for SR2.0Nishanth Menon2015-08-28-11/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Silicon revision 2.0 has new signal routing hence has an updated set of iodelay parameters to be used. Update the configuration for the same. Padmux remains the same. Based on data from VayuES2_EVM_Base_Config-20150807. NOTE: With respect to the RGMII values, the Manual IODelay values are used for the fine adjusments needed to meet the tight RGMII specification. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* | ARM: DRA7: Add detection of ES2.0Nishanth Menon2015-08-28-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for detection of ES2.0 version of DRA7 family of processors. ES2.0 is an incremental revision with various fixes including the following: - reset logic fixes - few assymetric aging logic fixes - MMC clock rate fixes - Ethernet speed fixes - edma fixes for mcasp [ravibabu@ti.com: posted internal for an older bootloader] Signed-off-by: Ravi Babu <ravibabu@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* | Makefile: Use correct timezone for U_BOOT_TZChris Packham2015-08-28-4/+10
| | | | | | | | | | | | | | | | | | | | | | When building with SOURCE_DATE_EPOCH the timezone is in UTC. When building normally the timezone is taken from the build machine's locale setting. Signed-off-by: Chris Packham <judge.packham@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Paul Kocialkowski <contact@paulk.fr> Tested-by: Andreas Bießmann <andreas.devel@googlemail.com>
* | lib/display_options: Fix print_freqSuriyan Ramasami2015-08-28-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Build without CONFIG_SPL_SERIAL_SUPPORT does not print the cpu freq. I have seen this in the odroid U3 board, where on boot one sees this: CPU: Exynos4412 @ GHz instead of: CPU: Exynos4412 @ 1 GHz I am assuming that this change was done to get rid of compiler warnings related to unused variables when building with CONFIG_SPL_SERIAL_SUPPORT not being defined in an SPL build. Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
* | NDS32: Generic Board Support and UnsupportKun-Hua Huang2015-08-28-1731/+0
| | | | | | | | | | | | Remove ag101 and ag102 support Signed-off-by: Kun-Hua Huang <kunhua@andestech.com>
* | NDS32: Generic Board Support and UnsupportKun-Hua Huang2015-08-28-427/+104
| | | | | | | | | | | | Add nds32 ag101p generic board support. Signed-off-by: Kun-Hua Huang <kunhua@andestech.com>
* | rpi: set fdt_addr_r to 0x00000100 to match default device_tree_addressJonathan Liu2015-08-28-2/+2
| | | | | | | | | | | | | | Raspberry Pi by default loads the FDT to 0x00000100 so set fdt_addr_r to match and move scriptaddr to 0x02000000 to avoid clobbering the FDT. Signed-off-by: Jonathan Liu <net147@gmail.com>
* | image: Fix loop condition to avoid warningThierry Reding2015-08-28-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC 5.1 starts warning for comparisons such as !a > 0, assuming that the negation was meant to apply to the whole expression rather than just the left operand. Indeed the comparison in the FIT loadable code is confusingly written, though it does end up doing the right thing. Rewrite the condition to be more explicit, that is, iterate over strings until they're exhausted. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* | Merge git://git.denx.de/u-boot-x86Tom Rini2015-08-26-635/+5954
|\ \
| * | dm: pci: Document binding of pci device driversBin Meng2015-08-26-3/+68
| | | | | | | | | | | | | | | | | | | | | Document how pci devices are bound to device drivers. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: crownbay: Support Topcliff integrated pci uart devices with driver modelBin Meng2015-08-26-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to make a pci uart device node to be properly bound to its driver, we need make sure its parent node has a compatible string which matches a driver that scans all of its child device nodes in the device tree. Change all pci bridge nodes under root pci node to use "pci-bridge" compatible driver, as well as corresponding <reg> properties to indicate its devfn. At last, adding "u-boot,dm-pre-reloc" to each of these nodes for driver model to initialize them before relocation. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | dm: core: Fix code reentrancy issue in device_probe_child()Bin Meng2015-08-26-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The device might have already been probed during the call to device_probe() on its parent device (e.g. PCI bridge devices). In its parent device's probe routine, it might probe all of its child devices via device_probe() thus the codes reenter device_probe_child(). To support code reentrancy, test these allocated memory against NULL to avoid memory leak, and return to the caller if dev->flags has DM_FLAG_ACTIVATED set after device_probe() returns, so that we don't mess up the device. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | dm: pci: Optimize pci_uclass_post_bind()Bin Meng2015-08-26-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | If there is no pci device listed in the device tree, don't bother scanning the device tree. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | video: ct69000: Remove unused codesBin Meng2015-08-26-21/+0
| | | | | | | | | | | | | | | | | | | | | | | | Remove unused CONFIG_USE_CPCIDVI wrapped codes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
| * | x86: crownbay: Enable on-board SMSC superio keyboard controllerBin Meng2015-08-26-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far we only enabled one legacy serial port on the SMSC LPC47m superio chipset on Intel Crown Bay board. As the board also has dual PS/2 ports routed out, enable the keyboard controller which is i8042 compatible so that we can use PS/2 keyboard and mouse. In order to make PS/2 keyboard work with the VGA console, remove CONFIG_VGA_AS_SINGLE_DEVICE. To boot Linux kernel with PIC mode using PIRQ routing table, adjust the mask in the device tree to reserve irq12 which is used by PS/2 mouse. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | video: cfb_console: Allow VGA device to work without i8042 keyboardBin Meng2015-08-26-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far if CONFIG_VGA_AS_SINGLE_DEVICE is not defined, the VGA device will try to initialize a keyboard device (for x86, it is i8042). But if i8042 controller initialization fails (eg: there is no keyboard connected to the PS/2 port), drv_video_init() just simply returns. This kills the opportunity of using a usb keyboard later with the vga console, as the vga initialization part is actually ok, only keyboard part fails. Change the code logic to allow this. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
| * | x86: i8042: Correctly initialize the controllerBin Meng2015-08-26-22/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing i8042 keyboard controller driver has some issues. First of all, it does not issue a self-test command (0xaa) to the controller at the very beginning. Without this, the controller does not respond to any command at all. Secondly, it initializes the configuration byte register to turn on the keyboard's interrupt, as U-Boot does not normally allow interrupts to be processed. Finally, at the end of the initialization routine, it wrongly sets the controller to disable all interfaces including both keyboard and mouse. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: i8042: Clean up the driver per coding conventionBin Meng2015-08-26-156/+177
| | | | | | | | | | | | | | | | | | | | | | | | | | | - Rename CamelCase variables to conform U-Boot coding convention - Rename wait_until_kbd_output_full() to kbd_output_full() - Change to use macros for i8042 command and control register bits Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: i8042: Reorder static functionsBin Meng2015-08-26-268/+222
| | | | | | | | | | | | | | | | | | | | | | | | Reorder those static function so that their declarations can be removed. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: i8042: Remove unused codesBin Meng2015-08-26-17/+0
| | | | | | | | | | | | | | | | | | | | | Remove unused CONFIG_USE_CPCIDVI wrapped codes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: gpio: Tidy up gpio_ich6_get_base() and callersSimon Glass2015-08-26-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function can return an error. Correct the detection of this error so that it works even with large 32-bit addresses. The return value is set up for returning an I/O address but the function is also used to return a memory-mapped address. Adjust the return code to make this work. Also add a bit more debugging. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: gpio: Correct calls to _ich6_gpio_set_direction()Simon Glass2015-08-26-2/+2
| | | | | | | | | | | | | | | | | | | | | These calls seem to be incorrect. The function expects an I/O address but the existing callers pass the value at an I/O address. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: minnowmax: Correct pad-offset value for host_en1Simon Glass2015-08-26-1/+1
| | | | | | | | | | | | | | | | | | | | | This should be 0x250, not 0x258. Fix it. Reported-by: Andrew Bradford <andrew.bradford@kodakalaris.com> Signed-off-by: Simon Glass <sjg@chromium.org>
| * | dm: pci: Add a comment to help find pci_hose_read_config_byte, etc.Simon Glass2015-08-26-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | These functions are defined by macros so do not show up with grep. Add a comment to help. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * | x86: minnowmax: Add access to GPIOs E0, E1, E2Simon Glass2015-08-26-0/+27
| | | | | | | | | | | | | | | | | | | | | These GPIOs are accessible on the pin header. Add pinctrl settings for them so that we they can be adjusted using the 'gpio' command. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Add DSDT table for supporting ACPI on QEMUSaket Sinha2015-08-26-1/+712
| | | | | | | | | | | | | | | | | | | | | | | | The DSDT table contains a bytecode that is executed by a driver in the kernel. Signed-off-by: Saket Sinha <saket.sinha89@gmail.com> Tested with QEMU '-M q35' Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * | x86: Add ACPI table support to QEMUSaket Sinha2015-08-26-0/+177
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch mainly adds ACPI support to QEMU. Verified by booting Linux kernel on QEMU Q35. Signed-off-by: Saket Sinha <saket.sinha89@gmail.com> Minor whitespace fixes and dropped mention of i440FX in commit message: Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Generate a valid ACPI tableSaket Sinha2015-08-26-0/+855
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement write_acpi_table() to create a minimal working ACPI table. This includes writing FACS, XSDT, RSDP, FADT, MCFG, MADT, DSDT & SSDT ACPI table entries. Use a Kconfig option GENERATE_ACPI_TABLE to tell U-Boot whether we need actually write the APCI table just like we did for PIRQ routing, MP table and SFI tables. With ACPI table existence, linux kernel gets control of power management, thermal management, configuration management and monitoring in hardware. Signed-off-by: Saket Sinha <saket.sinha89@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tidied up whitespace and aligned some tabs: Signed-off-by: Simon Glass <sjg@chromium.org>
| * | dm: pci: Save devfn without bus number in pci_uclass_child_post_bind()Bin Meng2015-08-26-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | In pci_uclass_child_post_bind(), bdf is extracted from fdt_pci_addr. Mask bus number before save it to pplat->devfn. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | fdtdec: Fix possible infinite loop in fdtdec_get_pci_vendev()Bin Meng2015-08-26-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | When there is no valid compatible string in current list, we should advance to next one in the compatible string list. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | patman: use -D option for git format-patchMasahiro Yamada2015-08-26-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This allows Patman to generate smaller patches for file removal. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
| * | x86: superio: Add keyboard controller support to smsc_lpc47m driverBin Meng2015-08-26-5/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add an api to enable and configure the integrated keyboard controller on SMSC LPC47m superio chipset. It also adds several macros to help future extension. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: fsp: Call fsp_init_phase_pci() in pci_uclass_post_probe()Bin Meng2015-08-26-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Per Intel FSP specification, we should call FSP notify API to inform FSP that PCI enumeration has been done so that FSP will do any necessary initialization as required by the chipset's BIOS Writer's Guide (BWG). Unfortunately we have to put this call here as with driver model, the enumeration is all done on a lazy basis as needed, so until something is touched on PCI it won't happen. Note we only call this after U-Boot is relocated and root bus has finished probing. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: baytrail: Remove the fsp_init_phase_pci() callBin Meng2015-08-26-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that calling fsp_init_phase_pci() in arch_misc_init() is subject to break pci device drivers as with driver model, when the bus enumeration happens is not deterministic. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: queensbay: Move unprotect_spi_flash() to arch_misc_init()Bin Meng2015-08-26-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With dm pci conversion, pci config read/write in unprotect_spi_flash() silently fails as at that time dm pci is not ready and bus enumeration is not done yet. Actually we don't need to do this in that early phase, hence we delay this call to arch_misc_init(). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: fsp: Add comments about U-Boot entering start.S twiceBin Meng2015-08-26-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add some comments in start.S for the fact that with FSP U-Boot actually enters the code twice. Also change to use fsp_init() and fsp_continue for accuracy. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: fsp: Enlarge the size of malloc() pool before relocationBin Meng2015-08-26-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After fsp_init() returns, the stack has already been switched to a place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR. Enlarge the size of malloc() pool before relocation since we have plenty of memory now. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: fsp: Delay x86_fsp_init() call a little bitBin Meng2015-08-26-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Move x86_fsp_init() call after initf_malloc() so that we can fix up the gd->malloc_limit later. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | dm: pci: Support selected device/driver binding before relocationBin Meng2015-08-26-11/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some platforms pci devices behind bridge need to be probed (eg: a pci uart on recent x86 chipset) before relocation. But we won't bind all devices found during the enumeration. Only devices whose driver with DM_FLAG_PRE_RELOC set will be bound. Any other generic devices except bridges won't be bound. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: ifdtool: Drop microcode from the device tree when collatingSimon Glass2015-08-26-2/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When ifdtool collates the microcode into one place it effectively creates a copy of the 'data' properties in the device tree microcode nodes. This is wasteful since we now have two copies of the microcode in the ROM. To avoid this, remove the microcode data from the device tree and shrink it down. This means that there is only one copy and the overall ROM space used by the microcode does not increase. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * | x86: ifdtool: Support collating microcode into one placeSimon Glass2015-08-26-10/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Intel Firmware Support Package (FSP) requires that microcode be provided very early before the device tree can be scanned. We already support adding a pointer to the microcode data in a place where early init code can access. However this just points into the device tree and can only point to a single lot of microcode. For boards which may have different CPU types we must support multiple microcodes and pass all of them to the FSP in one place. Enhance ifdtool to scan all the microcode, place it together in the ROM and update the microcode pointer to point there. This allows us to pass multiple microcode blocks to the FSP using its existing API. Enable the flag in the Makefile so that this feature is used by default for all boards. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * | x86: ifdtool: Split microcode linking into its own functionSimon Glass2015-08-26-27/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code to set up the microcode pointer in the ROM shares almost nothing with the write_uboot() function. Move it into its own function so it will be easier to extend. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * | x86: ifdtool: Check that U-Boot does not overlap other regionsSimon Glass2015-08-26-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since U-Boot and its device tree can grow we should check that it does not overlap the regions above it. Track the ROM offset that U-Boot reaches and check that other regions (written after U-Boot) do not interfere. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
| * | x86: baytrail: Support multiple microcode copiesBin Meng2015-08-26-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Intel FSP has the capability to walk through the microcode blocks which are passed as the TempRamInit() parameter from U-Boot and finds the most appropriate microcode which is suitable for the cpu on which it is running. Now we've seen several steppings for Intel BayTrail series processors, adding those microcodes to the Intel BayleyBay and MinnowMax board device tree files. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: baytrail: Add microcode for BayTrail-I D0 steppingBin Meng2015-08-26-0/+3284
| | | | | | | | | | | | | | | | | | | | | | | | This commit adds the microcode blob for BayTrail-I D0 stepping, CPUID signature 30679h. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Correct microcode documentationSimon Glass2015-08-26-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | This is incorrect since we require the -m parameter to the microcode tool. Update the two examples to show this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * | efi: Update README.efi to clarify build and test instructionsBin Meng2015-08-26-13/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | The doc has a misleading 'make menuconfig' when building the EFI application and payload. Clarify this and also update information on test with QEMU. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: Set up video framebuffer for coreboot before loading kernelBin Meng2015-08-26-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currenlty we only set up video framebuffer when VIDEO_VESA driver is used. With coreboot, VIDEO_COREBOOT driver is used instead. Since we already saved VESA mode in the VIDEO_COREBOOT driver, now we can also set up video framebuffer for coreboot before loading Linux kernel. Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
| * | video: coreboot: Save VESA mode for future useBin Meng2015-08-26-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.1 at 2024-11-14 13:07:57 +0000