summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-10-22omap5: omap_die_id supportPaul Kocialkowski
This introduces omap5 support for omap_die_id, which matches the common omap_die_id definition. It replaces board-specific code to grab the die id bits. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-10-22omap4: omap_die_id supportPaul Kocialkowski
This introduces omap4 support for omap_die_id, which matches the common omap_die_id definition. It replaces board-specific code to grab the die id bits. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-10-22omap3: omap_die_id supportPaul Kocialkowski
This replaces the previous get_dieid definition with omap_die_id, that matches the common omap_die_id definition. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-10-22omap-common: Common omap_die_id definitionPaul Kocialkowski
This introduces a common definition for omap_die_id, that aims at providing a common interface for accessing omap platform's die id bits. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-10-22ARM Fix pandaboard es and a4 revision IDdbatzle@dcbcyber.com
board_name environment variable was not getting set correctly for Pandaboard A4 and ES Signed-off-by: David Batzle <dbatzle@dcbcyber.com> CC: Albert Aribaud <albert.u.boot@aribaud.net>; Tom Rini <trini@ti.com>; Peter Robinson <pbrobinson@gmail.com>
2015-10-21Merge git://git.denx.de/u-boot-x86Tom Rini
2015-10-21x86: Add support for Advantech SOM-6896George McCollister
Advantech SOM-6896 is a Broadwell U based COM Express Compact Module Type 6. This patch adds support for it as a coreboot payload. On board SATA and SPI are functional. On board Ethernet isn't functional but since it's optional and ties up a PCIe x4 that is otherwise brought out, this isn't a concern at the moment. USB doesn't work since the xHCI driver appears to be broken. Signed-off-by: George McCollister <george.mccollister@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-10-21x86: ivybridge: Enable the MRC cacheBin Meng
This works correctly now, so enable it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Dropped malloc() and adjusted commit message: Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21x86: ivybridge: Measure the MRC code execution timeSimon Glass
This code takes about 450ms without the MRC cache and about 27ms with the cache. Add a debug timer so that this time can be displayed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21x86: ivybridge: Fix car_uninit() to correctly set run stateSimon Glass
At present a missing $ causes this code to hang when using the MRC cache/ Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21x86: ivybridge: Check the RTC return valueSimon Glass
The RTC can fail, so check the return value for reads. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21x86: ivybridge: Use 'ret' instead of 'rcode'Simon Glass
For consistency, use 'ret' to handle a return value. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21dm: rtc: Correct rtc_read32() return valueSimon Glass
The current check is incorrect and will fail when any non-zero byte is read. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21rtc: mc146818: Use probe() to set up the deviceSimon Glass
At present this driver uses bind() to set up the device. The bind() method should not touch the hardware, so move the init code to probe(). Signed-off-by: Simon Glass <sjg@chromium.org>
2015-10-21rtc: mc146818: Add a comment to the #endifSimon Glass
Add a comment to make it clear to which block the #endif relates. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21x86: chromebook_link: Enable the debug UARTSimon Glass
Add support for the debug UART on link. This is useful for early debugging. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21x86: Init the debug UART if enabledSimon Glass
If the debug UART is enabled, get it ready for use at the earliest possible opportunity. This is not actually very early, but until we have a stack it is difficult to make it work. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21debug_uart: Add an option to announce the debug UARTSimon Glass
It is useful to see a message from the debug UART early during boot so that you know things are working. Add an option to enable this. The message will be displayed as soon as debug_uart_init() is called. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21debug_uart: Support board-specific UART initialisationSimon Glass
Some boards need to set things up before the debug UART can be used. On these boards a call to debug_uart_init() is insufficient. When this option is enabled, the function board_debug_uart_init() will be called when debug_uart_init() is called. You can put any code here that is needed to set up the UART ready for use, such as set pin multiplexing or enable clocks. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21debug_uart: Adjust the declaration of debug_uart_init()Simon Glass
We want to be able to add other common code to this function. So change the driver's version to have an underscore before it, just like _debug_uart_putc(). Define debug_uart_init() to call this version. Update all drivers to this new method. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21x86: spi: Add support for Wildcat PointGeorge McCollister
Add the Wildcat Point ID so Broadwell U based boards can use SPI. Signed-off-by: George McCollister <george.mccollister@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21x86: pci: Add PCI IDs for Wildcat PointGeorge McCollister
Add Wildcat Point AHCI and LPC PCI IDs which are present on Broadwell U based (and possibly other) boards. Signed-off-by: George McCollister <george.mccollister@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-10-21x86: Pass correct cpu_index to ap_init()Bin Meng
In sipi_vector.S, cpu_index (passed as %eax) is wrongly overwritten by the ap_init() function address. Correct it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: galileo: Enable mrc cacheBin Meng
Now that we have added MRC cache on quark support codes, enable it on Intel Galileo board. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: quark: Implement mrc cacheBin Meng
Using existing mrccache library to implement mrc cache support for Intel Quark. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: ivybridge: Correct two typos for MRCBin Meng
It should be MRC, not MCR. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: Remove unused rw-mrc-cache properties in the link and panther dts filesBin Meng
"type" and "wipe-value" are never used by the mrccache codes. Remove them to avoid confusion. This also removes the alignment comment in the panther dts file. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: baytrail: Issue full system reset in reset_cpu()Bin Meng
With MRC cache enabled, when typing 'reset' in the U-Boot shell, BayTrail FSP initialization hangs at "Configuring Memory Start": Setting BootMode to 0 Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE About to call MrcInit(); BayleyBay Platform Type CurrentMrcData.BootMode = 4 Taking Fastboot path! Configuring Memory Start... Changing reset_cpu() to do a full system reset fixes this issue. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: Enable mrc cache for bayleybay and minnowmaxBin Meng
Now that we have added MRC cache for Intel FSP and BayTrail codes, enable it for all BayTrail boards (Bayley Bay and Minnow Max). Note it turns out that FSP for Intel Atom E6xx does not produce the HOB for NV storage, so we don't have such functionality on Intel Crown Bay board. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: baytrail: Save mrc cache to spi flashBin Meng
Save MRC cache to SPI flash in arch_misc_init(). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: fsp: Pass mrc cache to fsp_init() and save it to gd after fsp_init()Bin Meng
fsp_init() call has a parameter nvs_buf which is used by FSP as the MRC cache but currently is blindly set to NULL. Retreive the MRC cache from SPI flash and pass it to fsp_init() call. After the call, save FSP produced MRC cache to SPI flash too. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: Use struct mrc_region to describe a mrc regionBin Meng
Currently struct fmap_entry is used to describe a mrc region. However this structure contains some other fields that are not related to mrc cache and causes confusion. Besides, it does not include a base address field to store SPI flash's base address. Instead in the mrccache.c it tries to use CONFIG_ROM_SIZE to calculate the SPI flash base address, which unfortunately is not 100% correct as CONFIG_ROM_SIZE may not match the whole SPI flash size. Define a new struct mrc_region and use it instead. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: ivybridge: Use APIs provided in the mrccache libBin Meng
Remove the call to custom mrc cache APIs, and use the ones provided in the mrccache lib. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: Add more common routines to manipulate mrc cacheBin Meng
This adds mrccache_reserve(), mrccache_get_region() and mrccache_save() APIs to the mrccache codes. They are ported from the ivybridge implementation, but with some changes. For example, in the mrccache_reserve(), ivybridge version only reserves the pure MRC data, which causes additional malloc() when saving the cache as the save API needs some meta data. Now we change it to save the whole MRC date plus the meta data to elinimate the need for the malloc() later. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: Add various minor tidy-ups in mrccache codesBin Meng
Fix some nits, improve some comments and reorder some codes a little bit. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: Do sanity test on the cache record in mrccache_update()Bin Meng
For the cache record to write in mrccache_update(), we should perform a sanity test to see if it is a valid one. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: Move mrccache.[c|h] to a common placeBin Meng
mrccache implementation can be common for all boards. Move it from ivybridge cpu directory to the common lib directory. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: Add ENABLE_MRC_CACHE Kconfig optionBin Meng
Create a Kconfig option for enabling MRC cache. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: fsp: Add a hdr sub-command to show header informationBin Meng
It would be helpful to have a command to show FSP header. So far it only supports FSP header which conforms to FSP spec 1.0. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: fsp: Make hob command a sub-command to fspBin Meng
Introduce a new fsp command and make the existing hob command a sub-command to fsp for future extension. Also move cmd_hob.c to the dedicated fsp sub-directory in arch/x86/lib. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: fsp: Print GUID whenever applicable in the hob command outputBin Meng
When examining a HOB, it's useful to see which GUID this HOB belongs to. Add GUID output in the hob command to aid this. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: fsp: Compact the output of hob commandBin Meng
Compact hob command output, especially by making hob type string a little bit shorter so that we can leave room for future extension. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21x86: Add SMBIOS table supportBin Meng
System Management BIOS (SMBIOS) is a specification for how motherboard and system vendors present management information about their products in a standard format by extending the BIOS interface on Intel architecture systems. As of today the latest spec is 3.0 and can be downloaded from DMTF website. This commit adds a simple and minimum required implementation. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21Makefile: Generate U_BOOT_DMI_DATE for SMBIOSBin Meng
Add U_BOOT_DMI_DATE (format mm/dd/yyyy) generation to be used by SMBIOS tables, as required by SMBIOS spec 3.0 [1]. See chapter 7.1, BIOS information structure offset 08h for details. [1] http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.0.0.pdf Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21doc: Complement document about booting VxWorksBin Meng
Current document about how to boot VxWorks is limited. Add several chapters in README.vxworks to document this. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-10-21cmd: bootvx: Add asmlinkage to the VxWorks x86 entryBin Meng
VxWorks on x86 uses stack to pass parameters. Reported-by: Jian Luo <jian.luo4@boschrexroth.de> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-10-21cmd: bootvx: Pass E820 information to an x86 VxWorks kernelBin Meng
E820 is critical to the kernel as it provides system memory map information. Pass it to an x86 VxWorks kernel. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Jian Luo <jian.luo4@boschrexroth.de>
2015-10-21cmd: bootvx: Always get VxWorks bootline from envBin Meng
So far VxWorks bootline can be contructed from various environment variables, but when these variables do not exist we get these from corresponding config macros. This is not helpful as it requires rebuilding U-Boot, and to make sure these config macros take effect we should not have these environment variables. This is a little bit complex and confusing. Now we change the logic to always contruct the bootline from environments (the only single source), by adding two new variables "bootdev" and "othbootargs", and adding some comments about network related settings mentioning they are optional. The doc about the bootline handling is also updated. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>
2015-10-21cmd: bootvx: Pass netmask and gatewayip to VxWorks bootlineBin Meng
There are fields in VxWorks bootline for netmask and gatewayip. We can get these from U-Boot environment variables and pass them to VxWorks, just like ipaddr and serverip. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2015-10-21cmd: bootvx: Avoid strlen() calls when constructing VxWorks bootlineBin Meng
Remember the position in the VxWorks bootline buffer to avoid the call to strlen() each time. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>