summaryrefslogtreecommitdiffstats
path: root/arch/x86
Commit message (Collapse)AuthorAgeFilesLines
* x86: coreboot: Remove the dummy pch driverBin Meng2016-06-292-27/+0
| | | | | | | | | There is a dummy pch driver in the coreboot directory. This causes drivers of its children fail to function due to empty ops. Remove the whole file since it is no longer needed. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Probe pinctrl driver in cpu_init_r()Bin Meng2016-06-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | At present pinctrl driver gets probed in ich6_gpio driver's probe routine, which has two issues: - Pin's PADs only gets configured when GPIO driver is probed, which is not done by default. This leaves the board in a partially functional state as we must initialize PADs correctly to get perepherals fully working. - The probe routine of pinctrl driver is called multiple times, as normally there are multiple GPIO controllers. It should really be called just once. Move the call to syscon_get_by_driver_data() from ich6_gpio driver to cpu_init_r(). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: George McCollister <george.mccollister@gmail.com> Tested-by: George McCollister <george.mccollister@gmail.com>
* x86: baytrail: Configure card detect pin of the SD controllerBin Meng2016-06-123-0/+45
| | | | | | | | | | | | | | | | | | | | | As of today, the latest version FSP (gold4) for BayTrail misses the PAD configuration of the SD controller's Card Detect signal. The default PAD value for the CD pin sets the pin to work in GPIO mode, which causes card detect status cannot be reflected by the Present State register in the SD controller (bit 16 & bit 18 are always zero). Add a configuration for this pin in the pinctrl node. Note I've checked the PAD configuration for all the pins in all the 3 controllers (eMMC/SDIO/SD). Only this SDMMC3_CD_B pin does not get initialized to correct mode by FSP. With fsp,emmc-boot-mode set to 2 (eMMC 4.1), eMMC pins are initialized to func 1, but if we set fsp,emmc-boot-mode to 1 (auto), those pins are initialized to func 3 which is correct according to datasheet. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: baytrail: Change fsp, emmc-boot-mode to "auto"Bin Meng2016-06-123-3/+3
| | | | | | | | | | | | | | | | | | At present all BayTrail boards configure fsp,emmc-boot-mode to 2, which means "eMMC 4.1" per FSP documentation. However, eMMC 4.1 only shows up on some early stepping silicon of BayTrail SoC. Newer stepping SoC integrates an eMMC 4.5 controller. Intel FSP provides a config option fsp,emmc-boot-mode which tells FSP which eMMC controller it initializes. Instead of hardcoded to 2, now we change it to 1 which means "auto". With this change, MinnowMax board (with a D0 stepping BayTrail SoC) can see the eMMC 4.5 controller at PCI address 00.17.00 via U-Boot 'pci' command. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: baytrail: Add 'reg' property in the pinctrl nodeBin Meng2016-06-123-0/+7
| | | | | | | | | | | | Without a 'reg' property, pinctrl driver probe routine fails in its pre_probe() with a return value of -EINVAL. Add 'reg' property for all BayTrail boards. Note for BayleyBay, the pinctrl node is newly added. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: acpi: Fix madt lapic generationGeorge McCollister2016-06-121-6/+6
| | | | | | | | | | An accumulated length was incorrectly added to current each pass through the loop. On system with more than 2 cores this caused a corrupt MADT to be generated. Signed-off-by: George McCollister <george.mccollister@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: baytrail: acpi: Fix I/O APIC ID in the MADT tableBin Meng2016-05-301-1/+1
| | | | | | | | So far this is hardcoded to 2, but it should really be read from the I/O APIC register. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: quark: Generate ACPI FADT/MADT tablesBin Meng2016-05-302-0/+164
| | | | | | | Generate quark platform-specific FADT/MADT tables. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: quark: Add platform ASL filesBin Meng2016-05-307-0/+433
| | | | | | | | This adds basic quark platform ASL files. They are intended to be included in dsdt.asl of any board that is based on this platform. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: quark: Prepare device.h for inclusion by ASLBin Meng2016-05-301-6/+15
| | | | | | | | | There is a device.h for quark on-chip devices, mainly for definitions of internal PCI device numbers, but it's not ready to be included by ASL files. Update to use hex numbers for PCI dev and __ASSEMBLY__. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: acpi: Make irqroute.asl commonBin Meng2016-05-303-2/+2
| | | | | | | | | | The irqroute.asl file is already common enough to all x86 platforms. Platform ASL files need only provide a irqroute.h to describe how internal PCI devices and PCIe downstream port devices' INTx pins are routed to which PIRQ pin. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: acpi: Create a common irqlinks ASL fileBin Meng2016-05-302-21/+35
| | | | | | | | | | | Move the irqlinks.asl file currently in the BayTrail directory to a common place to be shared among all x86 platforms. As the PIRQ routing control programming interface is common to Intel chipsets, leave the common part in the common file, and move the platform specific part to the platform files. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Switch to use SMBIOS Kconfig options when writing SMBIOS tablesBin Meng2016-05-231-5/+5
| | | | | | | | Make use of the newly added Kconfig options of board manufacturer and product name to write SMBIOS tables. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: kconfig: Add two options for SMBIOS manufacturer and product nameBin Meng2016-05-231-0/+16
| | | | | | | | This introduces two Kconfig options to be used by SMBIOS tables: board manufacturer and product name. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: broadwell: Correct I/O APIC IDBin Meng2016-05-231-1/+2
| | | | | | | | | Currently ID 2 is assgined to broadwell I/O APIC, however per chromebook_samus.dts 2 is the core#2 LAPIC ID. Now we change I/O APIC ID to 4 to avoid conflict. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: quark: Assign a unique I/O APIC IDBin Meng2016-05-231-0/+4
| | | | | | | | | | | | | | | | | | | | | | | After power-on, both LAPIC and I/O APIC appear with the same APIC ID zero, which creates an ID conflict. When generating MP table, U-Boot reports zero as the LAPIC ID in the processor entry, and zero as the I/O APIC ID in the I/O APIC as well as the I/O interrupt assignment entries. Such MP table confuses Linux kernel and finally a kernel panic is seen during boot: BUG: unable to handle kernel paging request at ffff9000 IP: [<c101d462>] native_io_apic_write+0x22/0x30 *pdpt = 00000000014fb001 *pde = 00000000014ff067 *pte = 0000000000000000 Oops: 0002 [#1] Modules linked in: Pid: 1, comm: swapper Tainted: G W 3.8.7 #3 intel galileo/galileo EIP: 0060:[<c101d462>] EFLAGS: 00010086 CPU: 0 EIP is at native_io_apic_write+0x22/0x30 ... Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Call lapic_setup() in interrupt_init()Bin Meng2016-05-233-7/+5
| | | | | | | Let's configure LAPIC in a common place - interrupt_init(). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Remove SMP limitation in lapic_setup()Bin Meng2016-05-231-6/+1
| | | | | | | | | At present LAPIC is enabled and configured as virtual wire mode in lapic_setup() only when CONFIG_SMP is on. This limitation is however not necessary as for uniprocessor this is still needed. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Don't touch IA32_APIC_BASE MSR on Intel QuarkBin Meng2016-05-231-12/+16
| | | | | | | | | | | Intel Quark processor core provides an integrated Local APIC but does not support the IA32_APIC_BASE MSR. As a result, the Local APIC is always globally enabled and the Local APIC base address is fixed at 0xfee00000. Attempting to access the IA32_APIC_BASE MSR causes a general protection fault. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: galileo: Enable CPU driverBin Meng2016-05-231-0/+12
| | | | | | | Add a cpu node in the device tree and enable CPU driver. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Use latest microcode for all BayTrail boardsBin Meng2016-05-235-6574/+6
| | | | | | | | | Update board device tree to include latest microcode, and remove the old no longer needed microcode. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
* x86: baytrail: Update to latest microcodeBin Meng2016-05-232-0/+6568
| | | | | | | | Update BayTrail microcde to rev 325 (for CPUID 30673), rev 907 (for CPUID 30679). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Add some notes for MRC cache with Intel FSPBin Meng2016-05-231-0/+7
| | | | | | | | | MRC cache relies on Intel FSP to produce a special GUID that contains the MRC cache data. Add such information in the CONFIG_ENABLE_MRC_CACHE help entry. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: baytrail: Add GPIO ASL descriptionBin Meng2016-05-232-0/+98
| | | | | | | | | Since BayTrail, Intel starts to use new GPIO IPs in their chipset. This adds the GPIO ASL, so that OS can load corresponding drivers for it. On Linux, this is BayTrail pinctrl driver. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: baytrail: Add internal UART ASL descriptionBin Meng2016-05-232-0/+64
| | | | | | | | | | | | | | | BayTrail integrates an internal ns15550 compatible UART (PNP0501). Its IRQ is hardwired to IRQ3 in old revision chipset, but in newer revision one IRQ4 is being used for ISA compatibility. Handle this correctly in the ASL file. Linux does not need this ASL, but Windows need this to correctly discover a COM port existing in the system so that Windows can show it in the 'Device Manager' window, and expose this COM port to any terminal emulation application. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: acpi: Remove header length check when writing tablesBin Meng2016-05-231-16/+10
| | | | | | | | | | Before moving 'current' pointer during ACPI table writing, we always check the table length to see if it is larger than the table header. Since our purpose is to generate valid tables, the check logic is always true, which can be avoided. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: acpi: Remove the unnecessary checksum calculation of DSDTBin Meng2016-05-231-6/+0
| | | | | | | | The generated AmlCode[] from IASL already has the calculated DSDT table checksum in place. No need for us to calculate it again. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: acpi: Switch to ACPI mode by ourselves instead of requested by OSPMBin Meng2016-05-232-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Per ACPI spec, during ACPI OS initialization, OSPM can determine that the ACPI hardware registers are owned by SMI (by way of the SCI_EN bit in the PM1_CNT register), in which case the ACPI OS issues the ACPI_ENABLE command to the SMI_CMD port. The SCI_EN bit effectively tracks the ownership of the ACPI hardware registers. However since U-Boot does not support SMI, we report all 3 fields in FADT (SMI_CMD, ACPI_ENABLE, ACPI_DISABLE) as zero, by following the spec who says: these fields are reserved and must be zero on system that does not support System Management mode. U-Boot seems to behave in a correct way that the ACPI spec allows, at least Linux does not complain, but apparently Windows does not think so. During Windows bring up debugging, it is observed that even these 3 fields are zero, Windows are still trying to issue SMI with hardcoded SMI port address and commands, and expecting SCI_EN to be changed by the firmware. Eventually Windows gives us a BSOD (Blue Screen of Death) saying ACPI_BIOS_ERROR and refuses to start. To fix this, turn on the SCI_EN bit by ourselves. With this patch, now U-Boot can install and boot Windows 8.1/10 successfully with the help of SeaBIOS using legacy interface (non-UEFI mode). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Use high_table_malloc() for tables passing to SeaBIOSBin Meng2016-05-231-3/+1
| | | | | | | | Now that we already reserved high memory for configuration tables, call high_table_malloc() to allocate tables from the region. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Reserve configuration tables in high memoryBin Meng2016-05-231-3/+8
| | | | | | | When SeaBIOS is on, reserve configuration tables in reserve_arch(). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Unify reserve_arch() for all x86 boardsBin Meng2016-05-235-27/+12
| | | | | | | | Instead of asking each platform to provide reserve_arch(), supply it in arch/x86/cpu/cpu.c in a unified way. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Prepare configuration tables in dedicated high memory regionBin Meng2016-05-234-0/+68
| | | | | | | | | | Currently when CONFIG_SEABIOS is on, U-Boot allocates configuration tables via normal malloc(). To simplify, use a dedicated memory region which is reserved on the stack before relocation for this purpose. Add functions for reserve and malloc. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Compile coreboot_table.c only for SeaBIOSBin Meng2016-05-231-1/+1
| | | | | | | coreboot_table.c only needs to be built when SeaBIOS is used. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Fix up PIRQ routing table checksum earlierBin Meng2016-05-232-4/+4
| | | | | | | | | | | | | | | | PIRQ routing table checksum is fixed up in copy_pirq_routing_table(), which is fine if we only write the configuration table once. But with the SeaBIOS case, when we write the table for the second time, the checksum will be fixed up to zero per the checksum algorithm, which is caused by the checksum field not being zero before fix up, since the checksum has already been calculated in the first run. To fix this, move the checksum fixup to create_pirq_routing_table(), so that copy_pirq_routing_table() only does what its function name suggests: copy the table to somewhere else. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: Call board_final_cleanup() in last_stage_init()Bin Meng2016-05-233-18/+21
| | | | | | | | | | | At present board_final_cleanup() is called before booting a Linux kernel. This actually needs to be done before booting anything, like SeaBIOS, VxWorks or Windows. Move the call to last_stage_init() instead. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: qemu: rename qemu/acpi_table.cMiao Yan2016-05-232-2/+1
| | | | | | | | Rename qemu/acpi_table.c to qemu/e820.c, because ACPI stuff is moved to qfw core, this file only contains code for installing e820 table. Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* cmd: qfw: bring ACPI generation code into qfw coreMiao Yan2016-05-231-209/+0
| | | | | | | | Loading ACPI table from QEMU's fw_cfg interface is not x86 specific (ARM64 may also make use of it). So move the code to common place. Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* cmd: qfw: rename qemu_fw_cfg.[c|h] to qfw.[c|h]Miao Yan2016-05-234-4/+4
| | | | | | | Make file names consistent with CONFIG_QFW and CONFIG_CMD_QFW Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: qemu: add comment about qfw register endiannessMiao Yan2016-05-231-1/+8
| | | | | | | This patch adds some comments about qfw register endianness for clarity. Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: qemu: move x86 specific operations out of qfw coreMiao Yan2016-05-231-1/+38
| | | | | | | | | | | The original implementation of qfw includes several x86 specific operations, like directly calling outb/inb and using some inline assembly code which prevents it being ported to other architectures. This patch adds callback functions and moves those to arch/x86/ Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: qemu: split qfw command interface and qfw coreMiao Yan2016-05-234-4/+7
| | | | | | | | | | | | This patch splits qfw command interface and qfw core function into two files, and introduces a new Kconfig option (CONFIG_QFW) for qfw core. Now when qfw command interface is enabled, it will automatically select qfw core. This patch also makes the ACPI table generation select CONFIG_QFW. Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* cmd: qfw: remove qemu_fwcfg_free_files()Miao Yan2016-05-231-2/+11
| | | | | | | | | | | This patch is part of the qfw refactor work. The qemu_fwcfg_free_files() function is only used in error handling in ACPI table generation, let's not make this a core function and move it to the right place. Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: qemu: fix ACPI Kconfig optionsMiao Yan2016-05-233-11/+3
| | | | | | | | | | | | | | | CONFIG_GENENRATE_ACPI_TABLE controls the generation of ACPI table which uses U-Boot's built-in methods and CONFIG_QEMU_ACPI_TABLE controls whether to load ACPI table from QEMU's fw_cfg interface. But with commit "697ec431469ce0a4c2fc2c02d8685d907491af84 x86: qemu: Drop our own ACPI implementation", there is only one way to support ACPI table for QEMU targets which is the fw_cfg interface. Having two Kconfig options for this purpose is not necessary any more, so this patch consolidates the two. Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: qemu: Move qfw command over to cmd and add Kconfig entryTom Rini2016-05-238-732/+249
| | | | | | | | | | - Move the command portion of arch/x86/cpu/qemu/fw_cfg.c into cmd/qemu_fw_cfg.c - Move arch/x86/include/asm/fw_cfg.h to include/qemu_fw_cfg.h - Rename ACPI table portion to arch/x86/cpu/qemu/acpi_table.c Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: baytrail: Generate ACPI FADT/MADT tablesBin Meng2016-05-232-0/+164
| | | | | | | FADT/MADT tables are platform specific. Generate them for BayTrail. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: baytrail: Add platform ASL filesBin Meng2016-05-2313-0/+1348
| | | | | | | | | | | This adds basic BayTrail platform ASL files. They are intended to be included in dsdt.asl of any board that is based on this platform. Note: ACPI mode support for GPIO/LPSS/SCC/LPE are not supported for now. They will be added in the future. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: acpi: Return table length in acpi_create_madt_lapics()Bin Meng2016-05-232-4/+6
| | | | | | | | Like other MADT table write routines, make acpi_create_madt_lapics() return how many bytes it has written instead of the table end addr. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: acpi: Add some generic ASL librariesBin Meng2016-05-233-0/+331
| | | | | | | | | | | | | | This adds several generic ASL libraries that can be included by other ASL files, which are: - debug.asl: for debug output using POST I/O port and legacy serial port - globutil.asl: for string compare routines - statdef.asl: for _STA status values Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Tested-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: acpi: Clean up table header revisionsBin Meng2016-05-232-18/+4
| | | | | | | | | | | | | | The comment of initializing table header revision says: /* ACPI 1.0/2.0: 1, ACPI 3.0: 2, ACPI 4.0: 3 */ which might mislead it may increase per ACPI spec revision. However this is not the case. It's actually a fixed number as defined in ACPI spec, and in the laest ACPI spec 6.1, some table header revisions are still 1. Clean these up. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: acpi: Align FACS table to a 64 byte boundaryBin Meng2016-05-231-1/+5
| | | | | | | | | | Per ACPI spec, the FACS table address must be aligned to a 64 byte boundary (Windows checks this, but Linux does not). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Tested-by: Stefan Roese <sr@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
OpenPOWER on IntegriCloud