summaryrefslogtreecommitdiffstats
path: root/arch/x86/cpu/coreboot
Commit message (Collapse)AuthorAgeFilesLines
* SPDX-License-Identifier: convert BSD-3-Clause filesWolfgang Denk2013-08-191-22/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini Don't remove some copyrights by accident] Signed-off-by: Tom Rini <trini@ti.com>
* config: don't define CONFIG_ARCH_DEVICE_TREEStephen Warren2013-08-021-7/+0
| | | | | | | Now that nothing uses CONFIG_ARCH_DEVICE_TREE, stop defining it. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-247-106/+7
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* x86: Add coreboot timestampsSimon Glass2013-05-131-0/+3
| | | | | | | Add selected coreboot timestamps into bootstage to get a unified view of the boot timings. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Support adding coreboot timestanps to bootstageSimon Glass2013-05-131-0/+38
| | | | | | | Coreboot provides a lot of useful timing information. Provide a facility to add this to bootstage on start-up. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Add TSC timerSimon Glass2013-05-131-1/+3
| | | | | | | | | | | | | | 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: Implement panic output for corebootSimon Glass2013-05-131-0/+10
| | | | | | | | panic_puts() can be called in early boot to display a message. It might help with early debugging. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
* x86: Fix DRAM bank size init with generic boardSimon Glass2013-04-151-1/+6
| | | | | | | | | | | | | The intention of the memory init code is that it should work the same with CONFIG_SYS_GENERIC_BOARD and without. This is tricky because dram_init() is called prior to relocation with generic board (matching other archs) and after relocation without generic board. Adjust the init sequence so that dram_init() is not called in the generic board case, which seems like the easiest fix for now. Also ensure that relocation addresses are still calculated. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Use sections header to obtain link symbolsSimon Glass2013-03-151-0/+1
| | | | | | | These are defined in asm-generic/sections.h, so remove them from architecture-specific files. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Permit bootstage and timer data to be used prior to relocationSimon Glass2013-03-041-9/+6
| | | | | | | | | It is useful to be able to access the timer before U-Boot has relocated so that we can fully support bootstage. Add new global_data members to support this. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Add function to get top of usable ramSimon Glass2013-03-041-14/+4
| | | | | | | | | | | | | The memory layout calculations are done in calculate_relocation_address(), and coreboot has its own version of this function. But in fact all we really need is to set the top of usable RAM, and then the base version will work as is. So instead of allowing the whole calculate_relocation_address() function to be replaced, create board_get_usable_ram_top() which can be used by a board to specify the top of the area where U-Boot relocations to. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: drop unused code in coreboot.cStefan Reinauer2012-12-061-7/+0
| | | | | | | | | | | The function setup_pcat_compatibility() is weak and implemented as empty function in board.c hence we don't have to override that with another empty function. monitor_flash_len is unused, drop it. Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Remove coreboot_ from file nameStefan Reinauer2012-12-062-2/+1
| | | | | | | ... because that information is already "encoded" in the directory name. Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Provide a way to throttle port80 accessesVadim Bendebury2012-12-061-0/+21
| | | | | | | | | | | | | | | | | | | | | | | Some systems (like Google Link device) provide the ability to keep a history of the target CPU port80 accesses, which is extremely handy for debugging. The problem is that the EC handling port 80 access is orders of magnitude slower than the AP. This causes random loss of trace data. This change allows to throttle port 80 accesses such that in case the AP is trying to post faster than the EC can handle, a delay is introduced to make sure that the post rate is throttled. Experiments have shown that on Link the delay should be at least 350,000 of tsc clocks. Throttling is not being enabled by default: to enable it one would have to set MIN_PORT80_KCLOCKS_DELAY to something like 400 and rebuild the u-boot image. With upcoming EC code optimizations this number could be decreased (new new value should be established experimentally). Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Issue SMI to finalize Coreboot in final stageDuncan Laurie2012-12-061-0/+4
| | | | | | | | | This will write magic value to APMC command port which will trigger an SMI and cause coreboot to lock down the ME, chipset, and CPU. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Fix MTRR clear to detect which MTRR to useDuncan Laurie2012-12-061-4/+15
| | | | | | | | | | | | Coreboot was always using MTRR 7 for the write-protect cache entry that covers the ROM and U-boot was removing it. However with 4GB configs we need more MTRRs for the BIOS and so the WP MTRR needs to move. Instead coreboot will always use the last available MTRR that is normally set aside for OS use and U-boot can clear it before the OS. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Emit port 80 post codes in show_boot_progress()Stefan Reinauer2012-12-061-0/+2
| | | | | | | | | This helps us monitor boot progress and determine where U-Boot dies if there are any problems. Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: coreboot: Set CONFIG_ARCH_DEVICE_TREE correctlyGabe Black2012-12-061-0/+23
| | | | | | | | We will use coreboot.dtsi as our fdt include file. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Override calculate_relocation_address to use the e820 mapGabe Black2012-12-061-6/+55
| | | | | | | | | | | | | | Because calculate_relocation_address now uses the e820 map, it will be able to avoid addresses over 32 bits and regions that are at high addresses but not big enough for U-Boot. It also means we can remove the hack which limitted U-Boot's idea of the size of memory to less than 4GB. Also take into account the space needed for the heap and stack, so we avoid picking a very small region those areas might overlap with something it shouldn't. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Ignore memory >4GB when parsing Coreboot tablesDuncan Laurie2012-12-061-0/+4
| | | | | | | | U-boot is unable to actually use that memory and it can cause problems with relocation if it tries to. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Clean up MTRR 7 right before jumping to the kernelStefan Reinauer2012-12-061-0/+18
| | | | | | | | This cleans up the rom caching optimization implemented in coreboot (and needed throughout U-Boot runtime). Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Fill in the dram info using the e820 map on coreboot/x86Gabe Black2012-12-061-0/+15
| | | | | | | | | | | | | | | This way when that dram "banks" are displayed, there's some useful information there. The number of "banks" we claim to have needs to be adjusted so that it covers the number of RAM e820 regions we expect to have/care about. This needs to be done after "RAM" initialization even though we always run from RAM. The bd pointer in the global data structure doesn't automatically point to anything, and it isn't set up until "RAM" is available since, I assume, it would take too much space in the very constrained pre-RAM environment. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Enable coreboot timestamp facility support in u-boot.Vadim Bendebury2012-12-063-0/+66
| | | | | | | | | | | | | | | | | | | | | This change turns on the code which allows u-boot to add timestamps to the timestamp table created by coreboot. Since u-boot does not use the tsc_t like structure to represent HW counter readings, this structure is being replaced by 64 bit integer. The timestamp_init() function is now initializing the base timer value used by u-boot to calculate the HW counter increments. Timestamp facility is initialized as soon as the timestamp table pointer is found in the coreboot table. The u-boot generated timer events' ID will start at 1000 to clearly separate u-boot events from coreboot events in the timer trace. Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: coreboot: Decode additional coreboot sysinfo tagsSimon Glass2012-11-301-22/+87
| | | | | | | | | | | Add support for decoding tags for GPIOs, compile/build info, cbmem and other features. Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: coreboot: Drop sysinfo.cStefan Reinauer2012-11-303-40/+8
| | | | | | | | | | sysinfo.c only contains the lib_sysinfo data structure which is used/filled by tables.c. This split was introduced by importing code from libpayload originally, but to keep the code simple, add the single line of actual code to tables.c Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: coreboot: Implement recursively scanning PCI bussesGabe Black2012-11-281-3/+23
| | | | | | | | | | | | | | | | | | | | | | A hook is installed to configure PCI bus bridges as they encountered by u-boot. The hook extracts the secondary bus number from the bridge's config space and then recursively scans that bus. On Coreboot, the PCI bus address space has identity mapping with the physical address space, so declare it as such to ensure that the "pci_map_bar" function used by some PCI drivers is behaving properly. This fixes the EHCI PCI driver initialization on Stumpy. This was tested as follows: Ran the PCI command on Alex, saw devices on bus 0, the OXPCIe 952 on bus 1, and empty busses 2 through 5. This matches the bridges reported on bus 0 and the PCI configuration output from coreboot. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: coreboot: Tell u-boot about PCI bus 0 when initializingGabe Black2012-11-281-0/+15
| | | | | | | | | | | | | | | | | U-boot needs a host controller or "hose" to interact with the PCI busses behind them. This change installs a host controller during initialization of the coreboot "board" which implements some of X86's basic PCI semantics. This relies on some existing generic code, but also duplicates a little bit of code from the sc520 implementation. Ideally we'd eliminate that duplication at some point. It looks like in order to scan buses beyond bus 0, we'll need to tell u-boot's generic PCI configuration code what to do if it encounters a bridge, specifically to scan the bus on the other side of it. Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Graeme Russ <graeme.russ@gmail.com>
* x86: coreboot: Move non-board specific files to coreboot arch directoryStefan Reinauer2012-11-283-0/+119
| | | | | | | | | | coreboot.c and coreboot_pci.c don't contain board specific but only coreboot specific code. Hence move it to the coreboot directory in arch/x86/cpu (which should probably be moved out of cpu/ in another commit) Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Add infrastructure to extract an e820 table from the coreboot tablesGabe Black2011-12-191-1/+37
| | | | | | | | Also approximate the size of RAM using the largest RAM address available in the tables. There may be areas which are marked as reserved which are actually at the end of RAM. Signed-off-by: Gabe Black <gabeblack@chromium.org>
* x86: Import code from coreboot's libpayload to parse the coreboot tableGabe Black2011-12-194-0/+279
| | | | | | | | | | | | | This change also forces the lib_sysinfo structure to be in the .data section. Otherwise it ends up in the .bss section. U-boot assumes that it doesn't need to copy it over during relocation, and instead fills that whole section with zeroes. If we really were booting from ROM that would be appropriate, but we need some information from the coreboot tables (memory size) before then and have to fill that structure before relocation. We skirt u-boot's assumption by putting this in .data where it assumes there is still read only but non-zero data. Signed-off-by: Gabe Black <gabeblack@chromium.org>
* x86: Initial commit for running as a coreboot payloadGabe Black2011-12-194-0/+148
Add a target for running u-boot as a coreboot payload in boards.cfg, a board, CPU and a config. This is a skeleton implementation which always reports the size of memory as 64 MB. Signed-off-by: Gabe Black <gabeblack@chromium.org>
OpenPOWER on IntegriCloud