summaryrefslogtreecommitdiffstats
path: root/arch/x86/lib/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* x86: Move common FSP code into a common locationSimon Glass2015-02-051-0/+1
| | | | | | 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: Add an 'mtrr' command to list and adjust MTRRsSimon Glass2015-01-131-0/+1
| | | | | | | | | | | | | It is useful to be able to see the MTRR setup in U-Boot. Add a command to list the state of the variable MTRR registers and allow them to be changed. Update the documentation to list some of the available commands. This does not support fixed MTRRs as yet. Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Add a simple command to show FSP HOB informationBin Meng2014-12-131-0/+1
| | | | | | | | | | | | | | FSP builds a series of data structures called the Hand-Off-Blocks (HOBs) as it progresses through initializing the silicon. These data structures conform to the HOB format as described in the Platform Initialization (PI) specification Volume 3 Shared Architectual Elements specification, which is part of the UEFI specification. Create a simple command to parse the HOB list to display the HOB address, type and length in bytes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Add support for running option ROMs nativelySimon Glass2014-11-251-0/+3
| | | | | | | | On x86 machines we can use an emulator to run option ROMS as with other architectures. But with some additional effort (mostly due to the 16-bit nature of option ROMs) we can run them natively. Add support for this. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: ivybridge: Implement SDRAM initSimon Glass2014-11-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: set CONFIG_USE_PRIVATE_LIBGCC to yMasahiro Yamada2014-10-231-3/+3
| | | | | | | | | | | | | | | | | | The motivation of this commit is to change CONFIG_USE_PRIVATE_LIBGCC to a boolean macro so we can move it to Kconfig. In the current implementation, there are two forms of syntax for this macro: - CONFIG_USE_PRIVATE_LIBGCC=y - CONFIG_USE_PRIVATE_LIBGCC=path/to/private/libgcc The latter is only used by x86 architecture. With a little bit refactoring, it can be converted to the former. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Tested-by: Simon Glass <sjg@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
* kbuild, x86: use a short log for arch/x86/lib/libgcc.aMasahiro Yamada2014-03-121-2/+3
| | | | | Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Simon Glass <sjg@chromium.org>
* kbuild: change out-of-tree buildMasahiro Yamada2014-02-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the working directory where the build process occurs. Before this commit, build process occurred under the source tree for both in-tree and out-of-tree build. That's why we needed to add $(obj) prefix to all generated files in makefiles like follows: $(obj)u-boot.bin: $(obj)u-boot Here, $(obj) is empty for in-tree build, whereas it points to the output directory for out-of-tree build. And our old build system changes the current working directory with "make -C <sub-dir>" syntax when descending into the sub-directories. On the other hand, Kbuild uses a different idea to handle out-of-tree build and directory descending. The build process of Kbuild always occurs under the output tree. When "O=dir/to/store/output/files" is given, the build system changes the current working directory to that directory and restarts the make. Kbuild uses "make -f $(srctree)/scripts/Makefile.build obj=<sub-dir>" syntax for descending into sub-directories. (We can write it like "make $(obj)=<sub-dir>" with a shorthand.) This means the current working directory is always the top of the output directory. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Tested-by: Gerhard Sittig <gsi@denx.de>
* x86: convert makefiles to Kbuild styleMasahiro Yamada2013-11-011-37/+19
| | | | | Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Simon Glass <sjg@chromium.org>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-241-17/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* Build arch/$ARCH/lib/bootm.o depending on CONFIG_CMD_BOOTMDirk Eibach2013-07-161-1/+1
| | | | | | | | MAKEALL is fine for ppc4xx and mpc85xx. Run checks were done on our controlcenterd hardware. Signed-off-by: Dirk Eibach <dirk.eibach@gdsys.cc> Signed-off-by: Andy Fleming <afleming@freescale.com>
* x86: Re-enable PCAT timer 2 for beepingSimon Glass2013-05-131-1/+1
| | | | | | | | While we don't want PCAT timers for timing, we want timer 2 so that we can still make a beep. Re-purpose the PCAT driver for this, and enable it in coreboot. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Remove ISR timerSimon Glass2013-05-131-1/+0
| | | | | | | | This is no longer used since we prefer the more accurate TSC timer, so remove the dead code. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Graeme Russ <graeme.russ@gmail.com>
* x86: Add TSC timerSimon Glass2013-05-131-0/+1
| | | | | | | | | | | | | | This timer runs at a rate that can be calculated, well over 100MHz. It is ideal for accurate timing and does not need interrupt servicing. Tidy up some old broken and unneeded implementations at the same time. To provide a consistent view of boot time, we use the same time base as coreboot. Use the base timestamp supplied by coreboot as U-Boot's base time. Signed-off-by: Simon Glass <sjg@chromium.org>base Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Remove legacy board init codeSimon Glass2013-05-131-5/+0
| | | | | | | Since we use CONFIG_SYS_GENERIC_BOARD on x86, we don't need this anymore. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Graeme Russ <graeme.russ@gmail.com>
* x86: Remove unused bios/pci codeSimon Glass2013-05-131-1/+0
| | | | | | | Graeme Russ pointed out that this code is no longer used. Remove it. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Graeme Russ <graeme.russ@gmail.com>
* x86: Enable generic board supportSimon Glass2013-03-151-0/+3
| | | | | | | This enables generic board support so that x86 boards can define CONFIG_SYS_GENERIC_BOARD. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Remove unused real mode codeSimon Glass2013-02-141-10/+0
| | | | | | | This code is pretty old and we want to support only 32-bit systems now. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Graeme Russ <graeme.russ@gmail.com>
* x86: Build vga video code only if CONFIG_VIDEO_VGA is definedSimon Glass2012-12-061-2/+2
| | | | | | | When running from coreboot we don't want this code, so make it optional. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Implement arch_phys_memset so that it can wipe memory above 4GBGabe Black2012-12-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | Implement arch_phys_memset so that it can set memory at physical addresses above 4GB using PAE paging. Because there are only 5 page tables in PAE mode, 1 PDPT and 4 PDTs, those tables are statically allocated in the BSS. The tables must be 4K page aligned and are declared that way, and because U-Boot starts as 4K aligned and the relocation code relocates it to a 4K aligned address, the tables work as intended. While paging is turned on, all 4GB are identity mapped except for one 2MB page which is used as the window into high memory. This way, U-Boot will continue to work as expected when running code that expects to access memory freely, but the code can still get at high memory through its window. The window is put at 2MB so that it's 2MB page aligned, low in memory to be out of the way of things U-Boot is likely to care about, and above the lowest 1MB where lots of random things live. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Allow compiling out realmode/bios codeGabe Black2012-11-301-3/+6
| | | | | | | | We don't want this for coreboot, so provide a way of compiling it out. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Split init functions out of board.cGraeme Russ2012-01-041-0/+2
| | | | | | This patch moves towards reducing board.c to simply a set of init cores for the three initialisation phases (Flash, Flash/RAM, and RAM), a set of three init function arrays and a init function array processing function
* x86: Move relocation code out of board.cGraeme Russ2012-01-041-0/+1
|
* x86: Move do_go_exec() out of board.cGraeme Russ2012-01-041-0/+1
| | | | | | -- Changes for v2: - None
* x86: Wrap small helper functions from libgcc to avoid an ABI mismatchGabe Black2011-11-291-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When gcc compiles some 64 bit operations on a 32 bit machine, it generates calls to small functions instead of instructions which do the job directly. Those functions are defined in libgcc and transparently provide whatever functionality was necessary. Unfortunately, u-boot can be built with a non-standard ABI when libgcc isn't. More specifically, u-boot uses -mregparm. When the u-boot and libgcc are linked together, very confusing bugs can crop up, for instance seemingly normal integer division or modulus getting the wrong answer or even raising a spurious divide by zero exception. This change borrows (steals) a technique and some code from coreboot which solves this problem by creating wrappers which translate the calling convention when calling the functions in libgcc. Unfortunately that means that these instructions which had already been turned into functions have even more overhead, but more importantly it makes them work properly. To find all of the functions that needed wrapping, u-boot was compiled without linking in libgcc. All the symbols the linker complained were undefined were presumed to be the symbols that are needed from libgcc. These were a subset of the symbols covered by the coreboot code, so it was used unmodified. To prevent symbols which are provided by libgcc but not currently wrapped (or even known about) from being silently linked against by code generated by libgcc, a new copy of libgcc is created where all the symbols are prefixed with __normal_. Without being purposefully wrapped, these symbols will cause linker errors instead of silently introducing very subtle, confusing bugs. Another approach would be to whitelist symbols from libgcc and strip out all the others. The problem with this approach is that it requires the white listed symbols to be specified three times, once for objcopy, once so the linker inserts the wrapped, and once to generate the wrapper itself, while this implementation needs it to be listed only twice. There isn't much tangible difference in what each approach produces, so this one was preferred. Signed-off-by: Gabe Black <gabeblack@chromium.org>
* x86: Import the glibc memset implementationGabe Black2011-11-291-0/+1
| | | | | | | The new implementation is about twice as fast as the old. This is from glibc-2.14, sysdeps/i386/memset.c. Signed-off-by: Gabe Black <gabeblack@chromium.org>
* x86: Provide more configuration granularityGraeme Russ2011-11-291-9/+9
| | | | | | Planned future ports requires more granularity for some options Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
* x86: Rename i386 to x86Graeme Russ2011-04-131-0/+59
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
OpenPOWER on IntegriCloud