summaryrefslogtreecommitdiff
path: root/src/lib
AgeCommit message (Collapse)Author
2013-05-01ramstage: introduce boot state machineAaron Durbin
The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01rmodule: put all code/data bits in one sectionAaron Durbin
While debugging a crash it was discovered that ld was inserting address space for sections that were empty depending on section address boundaries. This led to the assumption breaking down that on-disk payload (code/data bits) was contiguous with the address space. When that assumption breaks down relocation updates change the wrong memory. Fix this by making the rmodule.ld linker script put all code/data bits into a payload section. Change-Id: Ib5df7941bbd64662090136e49d15a570a1c3e041 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3149 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-04-20Eliminate use of pointers in coreboot tableStefan Reinauer
Because pointers can be 32bit or 64bit big, using them in the coreboot table requires the OS and the firmware to operate in the same mode which is not always the case. Hence, use 64bit for all pointers stored in the coreboot table. Guess we'll have to fix this up once we port to the first 128bit machines. Change-Id: I46fc1dad530e5230986f7aa5740595428ede4f93 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3115 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-04-18spkmodem consoleVladimir Serbinenko
Change-Id: Ie497e4c8da05001ffe67c4a541bd24aa859ac0e2 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/2987 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08Fix read_option invocation in uart8250mem.cStefan Reinauer
read_option was unified between ramstage and romstage a while ago. However, it seems some invocations were not fixed accordingly. This patch switches uart8250mem.c to use the new scheme. Change-Id: I03cef4f6ee9188a6412c61d7ed34fbaff808a32b Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3033 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08Fix compilation when coverage debugging is enabledStefan Reinauer
With CONFIG_DEBUG_COVERAGE enabled, the build currently fails with src/lib/gcov-glue.c: In function 'fseek': src/lib/gcov-glue.c:87:2: error: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Werror=format] src/lib/gcov-glue.c:87:2: error: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Werror=format] Change-Id: Iddaa601748c210d9dad06ae9dab2a3deaa635b2c Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3032 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01lynxpoint: Move ACPI NVS into separate CBMEM tableDuncan Laurie
The ACPI NVS region was setup in place and there was a CBMEM table that pointed to it. In order to be able to use NVS earlier the CBMEM region is allocated for NVS itself during the LPC device init and the ACPI tables point to it in CBMEM. The current cbmem region is renamed to ACPI_GNVS_PTR to indicate that it is really a pointer to the GNVS and does not actually contain the GNVS. Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2970 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-01boot: add disable_cache_rom() functionAaron Durbin
On certain architectures such as x86 the bootstrap processor does most of the work. When CACHE_ROM is employed it's appropriate to ensure that the caching enablement of the ROM is disabled so that the caching settings are symmetric before booting the payload or OS. Tested this on an x86 machine that turned on ROM caching. Linux did not complain about asymmetric MTRR settings nor did the ROM show up as cached in the MTRR settings. Change-Id: Ia32ff9fdb1608667a0e9a5f23b9c8af27d589047 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2980 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29memrange: add 2 new range_entry routinesAaron Durbin
Two convenience functions are added to operate on a range_entry: - range_entry_update_tag() - update the entry's tag - memranges_next_entry() - get the next entry after the one provide These functions will be used by a follow on patch to the MTRR code to allow hole punching in WB region when the default MTRR type is UC. Change-Id: I3c2be19c8ea1bbbdf7736c867e4a2aa82df2d611 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2924 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29x86: add rom cache variable MTRR index to tablesAaron Durbin
Downstream payloads may need to take advantage of caching the ROM for performance reasons. Add the ability to communicate the variable range MTRR index to use to perform the caching enablement. An example usage implementation would be to obtain the variable MTRR index that covers the ROM from the coreboot tables. Then one would disable caching and change the MTRR type from uncacheable to write-protect and enable caching. The opposite sequence is required to tearn down the caching. Change-Id: I4d486cfb986629247ab2da7818486973c6720ef5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2919 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29lib: add memrange infrastructureAaron Durbin
The memrange infrastructure allows for keeping track of the machine's physical address space. Each memory_range entry in a memory_ranges structure can be tagged with an arbitrary value. It supports merging and deleting ranges as well as filling in holes in the address space with a particular tag. The memrange infrastructure will serve as a shared implementation for address tracking by the MTRR and coreboot mem table code. Change-Id: Id5bea9d2a419114fca55c59af0fdca063551110e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2888 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29coreboot table: use memrange libraryAaron Durbin
Use the memrange library for keeping track of the address space region types. The memrange library is built to do just that for both the MTRR code and the coreboot memtable code. Change-Id: Iee2a7c37a3f4cf388db87ce40b580f274384ff3c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2917 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-26Revert "coreboot table: use memrange library"Aaron Durbin
This reverts commit 56075eaefcd7ef51464206166b24a0a47a59147f Change-Id: I8a37ce1f5ce36e4a120941ec264140abc9447ff5 Reviewed-on: http://review.coreboot.org/2915 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-26coreboot table: use memrange libraryAaron Durbin
Use the memrange library for keeping track of the address space region types. The memrange library is built to do just that for both the MTRR code and the coreboot memtable code. Change-Id: Ic667df444586c2b5b5f2ee531370bb790d683a42 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2896 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23dynamic cbmem: fix memconsole and timestampsAaron Durbin
There are assumptions that COLLECT_TIMESTAMPS and CONSOLE_CBMEM rely on EARLY_CBMEM_INIT. This isn't true in the face of DYNAMIC_CBMEM as it provides the same properties as EARLY_CBMEM_INIT. Therefore, allow one to select COLLECT_TIMESTAMPS and CONSOLE_CBMEM when DYNAMIC_CBMEM is selected. Lastly, don't hard code the cbmem implementation when COLLECT_TIMESTAMPS is selected. Change-Id: I053ebb385ad54a90a202da9d70b9d87ecc963656 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2895 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23rmodule: align ld script with latest x86 ld scriptAaron Durbin
The x86 linker script added a .textfirst section. In order to properly link ramstage as a relocatable module the .textfirst section needs to be included. Also, the support for code coverage was added by including the constructor section and symbols. Coverage has not been tested as I suspect it might not work in a relocatable environment without some tweaking. However, the section and symbols are there if needed. Change-Id: Ie1f6d987d6eb657ed4aa3a8918b2449dafaf9463 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2883 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23cbfs: fix relocation ramstage compiler errorsAaron Durbin
There were some cbfs calls that did not get transitioned to the new cbfs API. Fix the callsites to conform to the actual cbfs, thus fixing the copilation errors. Change-Id: Ia9fe2c4efa32de50982e21bd01457ac218808bd3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2880 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22Unify coreboot table generationStefan Reinauer
coreboot tables are, unlike general system tables, a platform independent concept. Hence, use the same code for coreboot table generation on all platforms. lib/coreboot_tables.c is based on the x86 version of the file, because some important fixes were missed on the ARMv7 version lately. Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d Signed-off-by: Stefan Reinauer <reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/2863 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-22romstage: add support for vboot firmware selectionAaron Durbin
This patch implements support for vboot firmware selection. The vboot support is comprised of the following pieces: 1. vboot_loader.c - this file contains the entry point, vboot_verify_firmware(), for romstage to call in order to perform vboot selection. The loader sets up all the data for the wrapper to use. 2. vboot_wrapper.c - this file contains the implementation calling the vboot API. It calls VbInit() and VbSelectFirmware() with the data supplied by the loader. The vboot wrapper is compiled and linked as an rmodule and placed in cbfs as 'fallback/vboot'. It's loaded into memory and relocated just like the way ramstage would be. After being loaded the loader calls into wrapper. When the wrapper sees that a given piece of firmware has been selected it parses firmware component information for a predetermined number of components. Vboot result information is passed to downstream users by way of the vboot_handoff structure. This structure lives in cbmem and contains the shared data, selected firmware, VbInitParams, and parsed firwmare components. During ramstage there are only 2 changes: 1. Copy the shared vboot data from vboot_handoff to the chromeos acpi table. 2. If a firmware selection was made in romstage the boot loader component is used for the payload. Noteable Information: - no vboot path for S3. - assumes that all RW firmware contains a book keeping header for the components that comprise the signed firmware area. - As sanity check there is a limit to the number of firmware components contained in a signed firmware area. That's so that an errant value doesn't cause the size calculation to erroneously read memory it shouldn't. - RO normal path isn't supported. It's assumed that firmware will always load the verified RW on all boots but recovery. - If vboot requests memory to be cleared it is assumed that the boot loader will take care of that by looking at the out flags in VbInitParams. Built and booted. Noted firmware select worked on an image with RW firmware support. Also checked that recovery mode worked as well by choosing the RO path. Change-Id: I45de725c44ee5b766f866692a20881c42ee11fa8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2854 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22cbmem: add vboot cmbem idAaron Durbin
The vboot firmware selection from romstage will need to pass the resulting vboot data to other consumers. This will be done using a cbmem entry. Change-Id: I497caba53f9f3944513382f3929d21b04bf3ba9e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2851 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22coreboot: dynamic cbmem requirementAaron Durbin
Dynamic cbmem is now a requirement for relocatable ramstage. This patch replaces the reserve_* fields in the romstage_handoff structure by using the dynamic cbmem library. The haswell code is not moved over in this commit, but it should be safe because there is a hard requirement for DYNAMIC_CBMEM when using a reloctable ramstage. Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2849 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22x86: Unify arch/io.h and arch/romcc_io.hStefan Reinauer
Here's the great news: From now on you don't have to worry about hitting the right io.h include anymore. Just forget about romcc_io.h and use io.h instead. This cleanup has a number of advantages, like you don't have to guard device/ includes for SMM and pre RAM anymore. This allows to get rid of a number of ifdefs and will generally make the code more readable and understandable. Potentially in the future some of the code in the io.h __PRE_RAM__ path should move to device.h or other device/ includes instead, but that's another incremental change. Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2872 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21rmodule: correct ordering of bss clearingAaron Durbin
This patch fixes an issue for rmodules which are copied into memory at the final load/link location. If the bss section is cleared for that rmodule the relocation could not take place properly since the relocation information was wiped by act of clearing the bss. The reason is that the relocation information resides at the same address as the bss section. Correct this issue by performing the relocation before clearing the bss. Change-Id: I01a124a8201321a9eaf6144c743fa818c0f004b4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2822 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-21cbmem: dynamic cbmem supportAaron Durbin
This patch adds a parallel implementation of cbmem that supports dynamic sizing. The original implementation relied on reserving a fixed-size block of memory for adding cbmem entries. In order to allow for more flexibility for adding cbmem allocations the dynamic cbmem infrastructure was developed as an alternative to the fixed block approach. Also, the amount of memory to reserve for cbmem allocations does not need to be known prior to the first allocation. The dynamic cbmem code implements the same API as the existing cbmem code except for cbmem_init() and cbmem_reinit(). The add and find routines behave the same way. The dynamic cbmem infrastructure uses a top down allocator that starts allocating from a board/chipset defined function cbmem_top(). A root pointer lives just below cbmem_top(). In turn that pointer points to the root block which contains the entries for all the large alloctations. The corresponding block for each large allocation falls just below the previous entry. It should be noted that this implementation rounds all allocations up to a 4096 byte granularity. Though a packing allocator could be written for small allocations it was deemed OK to just fragment the memory as there shouldn't be that many small allocations. The result is less code with a tradeoff of some wasted memory. +----------------------+ <- cbmem_top() | +----| root pointer | | | +----------------------+ | | | |--------+ | +--->| root block |-----+ | | +----------------------+ | | | | | | | | | | | | | | alloc N |<----+ | | +----------------------+ | | | | | | | | | \|/ | alloc N + 1 |<-------+ v +----------------------+ In addition to preserving the previous cbmem API, the dynamic cbmem API allows for removing blocks from cbmem. This allows for the boot process to allocate memory that can be discarded after it's been used for performing more complex boot tasks in romstage. In order to plumb this support in there were some issues to work around regarding writing of coreboot tables. There were a few assumptions to how cbmem was layed out which dictated some ifdef guarding and other runtime checks so as not to incorrectly tag the e820 and coreboot memory tables. The example shown below is using dynamic cbmem infrastructure. The reserved memory for cbmem is less than 512KiB. coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-000000007bf80fff: RAM 8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES 9. 000000007c000000-000000007e9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf coreboot table: 948 bytes. CBMEM ROOT 0. 7bfff000 00001000 MRC DATA 1. 7bffe000 00001000 ROMSTAGE 2. 7bffd000 00001000 TIME STAMP 3. 7bffc000 00001000 ROMSTG STCK 4. 7bff7000 00005000 CONSOLE 5. 7bfe7000 00010000 VBOOT 6. 7bfe6000 00001000 RAMSTAGE 7. 7bf98000 0004e000 GDT 8. 7bf97000 00001000 ACPI 9. 7bf8b000 0000c000 ACPI GNVS 10. 7bf8a000 00001000 SMBIOS 11. 7bf89000 00001000 COREBOOT 12. 7bf81000 00008000 And the corresponding e820 entries: BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16 BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16 BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2848 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21cbfs: Change false ERROR print to a WARNING.Shawn Nematbakhsh
Change "ERROR" to "WARNING" -- not finding the indicated file is usually not a fatal error. Change-Id: I0600964360ee27484c393125823e833f29aaa7e7 Signed-off-by: Shawn Nematbakhsh <shawnn@google.com> Reviewed-on: http://review.coreboot.org/2833 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21rmodule: add string functions to rmodules classAaron Durbin
The standard string functions memcmp(), memset(), and memcpy() are needed by most programs. The rmodules class provides a way to build objects for the rmodules class. Those programs most likely need the string functions. Therefore provide those standard functions to be used by any generic rmodule program. Change-Id: I2737633f03894d54229c7fa7250c818bf78ee4b7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2821 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21coreboot: add caching loaded ramstage interfaceAaron Durbin
Instead of hard coding the policy for how a relocated ramstage image is saved add an interface. The interface consists of two functions. cache_loaded_ramstage() and load_cached_ramstage() are the functions to cache and load the relocated ramstage, respectively. There are default implementations which cache and load the relocated ramstage just below where the ramstage runs. Change-Id: I4346e873d8543e7eee4c1cd484847d846f297bb0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2805 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21ramstage: cache relocated ramstage in RAMAaron Durbin
Accessing the flash part where the ramstage resides can be slow when loading it. In order to save time in the S3 resume path a copy of the relocated ramstage is saved just below the location the ramstage was loaded. Then on S3 resume the cached version of the relocated ramstage is copied back to the loaded address. This is achieved by saving the ramstage entry point in the romstage_handoff structure as reserving double the amount of memory required for ramstage. This approach saves the engineering time to make the ramstage reentrant. The fast path in this change will only be taken when the chipset's romstage code properly initializes the s3_resume field in the romstage_handoff structure. If that is never set up properly then the fast path will never be taken. e820 entries from Linux: BIOS-e820: [mem 0x000000007bf21000-0x000000007bfbafff] reserved BIOS-e820: [mem 0x000000007bfbb000-0x000000007bffffff] type 16 The type 16 is the cbmem table and the reserved section contains the two copies of the ramstage; one has been executed already and one is the cached relocated program. With this change the S3 resume path on the basking ridge CRB shows to be ~200ms to hand off to the kernel: 13 entries total: 1:95,965 2:97,191 (1,225) 3:131,755 (34,564) 4:132,890 (1,135) 8:135,165 (2,274) 9:135,840 (675) 10:135,973 (132) 30:136,016 (43) 40:136,581 (564) 50:138,280 (1,699) 60:138,381 (100) 70:204,538 (66,157) 98:204,615 (77) Change-Id: I9c7a6d173afc758eef560e09d2aef5f90a25187a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2800 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21ramstage: Add cbmem_get_table_location()Aaron Durbin
When CONFIG_EARLY_CBMEM_INIT is selected romstage is supposed to have initialized cbmem. Therefore provide a weak function for the chipset to implement named cbmem_get_table_location(). When CONFIG_EARLY_CBMEM_INIT is selected cbmem_get_table_location() will be called to get the cbmem location and size. After that cbmem_initialize() is called. Change-Id: Idc45a95f9d4b1d83eb3c6d4977f7a8c80c1ffe76 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2797 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21romstage_handoff: provide common logic for setupAaron Durbin
The romstage_handoff structure can be utilized from different components of the romstage -- some in the chipset code, some in coreboot's core libarary. To ensure that all users handle initialization of a newly added romstage_handoff structure properly, provide a common function to handle structure initialization. Change-Id: I3998c6bb228255f4fd93d27812cf749560b06e61 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2795 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21coreboot: introduce CONFIG_RELOCATABLE_RAMSTAGEAaron Durbin
This patch adds an option to build the ramstage as a reloctable binary. It uses the rmodule library for the relocation. The main changes consist of the following: 1. The ramstage is loaded just under the cmbem space. 2. Payloads cannot be loaded over where ramstage is loaded. If a payload is attempted to load where the relocatable ramstage resides the load is aborted. 3. The memory occupied by the ramstage is reserved from the OS's usage using the romstage_handoff structure stored in cbmem. This region is communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem. 4. There is no need to reserve cbmem space for the OS controlled memory for the resume path because the ramsage region has been reserved in #3. 5. Since no memory needs to be preserved in the wake path, the loading and begin of execution of a elf payload is straight forward. Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2792 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-03-21cbmem: add CBMEM_ID_ROMSTAGE_INFO idAaron Durbin
Introduce a new cbmem id to indicate romstage information. Proper coordination with ramstage and romstage can use this cbmem entity to communicate between one another. Change-Id: Id785f429eeff5b015188c36eb932e6a6ce122da8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2790 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-21rmodule: add ability to calculate module placementAaron Durbin
There is a need to calculate the proper placement for an rmodule in memory. e.g. loading a compressed rmodule from flash into ram can be an issue. Determining the placement is hard since the header is not readable until it is decompressed so choosing the wrong location may require a memmove() after decompression. This patch provides a function to perform this calculation by finding region below a given address while making an assumption on the size of the rmodule header.. Change-Id: I2703438f58ae847ed6e80b58063ff820fbcfcbc0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2788 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-20x86: don't clear bss in ramstage entryAaron Durbin
The cbfs stage loading routine already zeros out the full memory region that a stage will be loaded. Therefore, it is unnecessary to to clear the bss again after once ramstage starts. Change-Id: Icc7021329dbf59bef948a41606f56746f21b507f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2865 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-20link/graphics: Add support for EDIDRonald G. Minnich
This code is taken from an EDID reader written at Red Hat. The key function is int decode_edid(unsigned char *edid, int size, struct edid *out) Which takes a pointer to an EDID blob, and a size, and decodes it into a machine-independent format in out, which may be used for driving chipsets. The EDID blob might come for IO, or a compiled-in EDID BLOB, or CBFS. Also included are the changes needed to use the EDID code on Link. Change-Id: I66b275b8ed28fd77cfa5978bdec1eeef9e9425f1 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2837 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-19rmodule: add ramstage supportAaron Durbin
Coreboot's ramstage defines certain sections/symbols in its fixed static linker script. It uses these sections/symbols for locating the drivers as well as its own program information. Add these sections and symbols to the rmodule linker script so that ramstage can be linked as an rmodule. These sections and symbols are a noop for other rmodule-linked programs, but they are vital to the ramstage. Also add a comment in coreboot_ram.ld to mirror any changes made there to the rmodule linker script. Change-Id: Ib9885a00e987aef0ee1ae34f1d73066e15bca9b1 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2786 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-19cbfs: alternative support for cbfs_load_payload()Aaron Durbin
In certain situations boot speed can be increased by providing an alternative implementation to cbfs_load_payload(). The ALT_CBFS_LOAD_PAYLOAD option allows for the mainboard or chipset to provide its own implementation. Booted baskingridge board with alternative and regular cbfs_load_payload(). Change-Id: I547ac9881a82bacbdb3bbdf38088dfcc22fd0c2c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2782 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-18rmodule: include heap in bss sectionAaron Durbin
By including the heap in the bss output section the size is accounted for in a elf PT_LOAD segment. Without this change the heap wasn't being put into a PT_LOAD segment. The result is a nop w.r.t. functionality, but readelf and company will have proper MemSiz fields. Change-Id: Ibfe9bb87603dcd4c5ff1c57c6af910bbba96b02b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2750 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18lib: add rmodule supportAaron Durbin
A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-08Eliminate do_div().David Hendricks
This eliminates the use of do_div() in favor of using libgcc functions. This was tested by building and booting on Google Snow (ARMv7) and Qemu (x86). printk()s which use division in vtxprintf() look good. Change-Id: Icad001d84a3c05bfbf77098f3d644816280b4a4d Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2606 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-07Fix build by adding `cbmem.c` to `COLLECT_TIMESTAMPS`Kyösti Mälkki
A board without HAVE_ACPI_RESUME did not build with COLLECT_TIMESTAMPS enabled as `cbmem.c` was not built. Change-Id: I9c8b575d445ac566a2ec533d73080bcccc3dfbca Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2549 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-01GPLv2 notice: Unify all files to just use one space in »MA 02110-1301«Paul Menzel
In the file `COPYING` in the coreboot repository and upstream [1] just one space is used. The following command was used to convert all files. $ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/' [1] http://www.gnu.org/licenses/gpl-2.0.txt Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2490 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-02-28Drop CONFIG_WRITE_HIGH_TABLESStefan Reinauer
It's been on for all boards per default since several years now and the old code path probably doesn't even work anymore. Let's just have one consistent way of doing things. Change-Id: I58da7fe9b89a648d9a7165d37e0e35c88c06ac7e Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2547 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-27selfboot: Report correct entry point address in debug message.Hung-Te Lin
Entry point in payload segment header is a 64 bit integer (ntohll). The debug message is currently reading that as a 32 bit integer (which will produce 00000000 for most platforms). Change-Id: I931072bbb82c099ce7fae04f15c8a35afa02e510 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2535 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-02-22libcbfs: Fix legacy CBFS API, typosHung-Te Lin
Pulling CBFS fix from libpayload: http://review.coreboot.org/#/c/2455/2 get_cbfs_header expects CBFS_HEADER_INVALID_ADDRESS (0xffffffff) instead of NULL when something is wrong. Also, fix typo. Change-Id: I7f393f7c24f74a3358f7339a3095b0d845bdc02d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2457 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-02-12fix an error message in checkstack()David Hendricks
The order of some printk arguments were reversed. Change-Id: I5e8f70b79050b92ebe8cfa5aae94b6cd1a5fd547 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2364 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-07cbfs: Fix CBFS max size calculation.Hung-Te Lin
For x86, the old CBFS search behavior was to bypass bootblock and we should keep that. This will speed up searching if a file does not exist in CBFS. For arm, the size in header is correct now so we can remove the hack by CONFIG_ROM_SIZE. Change-Id: I541961bc4dd083a583f8a80b69e293694fb055ef Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2292 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-02-06cbfs: Revise debug messages.Hung-Te Lin
Some variables are using incorrect data type in debug messages. Also corrects a typo (extra 'x'). Change-Id: Ia3014ea018f8c1e4733c54a7d9ee196d0437cfbb Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2294 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-03armv7: Add 'bootblock' build class.Hung-Te Lin
For ARM platform, the bootblock may need more C source files to initialize UART / SPI for loading romstage. To preventing making complex and implicit dependency by using #include inside bootblock.c, we should add a new build class "bootblock". Also #ifdef __BOOT_BLOCK__ can be used to detect if the source is being compiled for boot block. For x86, the bootblock is limited to fewer assembly files so it's not using this class. (Some files shared by x86 and arm in top level or lib are also changed but nothing should be changed in x86 build process.) Change-Id: Ia81bccc366d2082397d133d9245f7ecb33b8bc8b Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2252 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-02-01lib: Prevent unaligned memory access and fix endianess in LZMA decode library.Hung-Te Lin
LZMA decode library used to retrieve output size by: outSize = *(UInt32 *)(src + LZMA_PROPERTIES_SIZE); 'src' is aligned but LZMA_PROPERTIES_SIZE may refer to an unaligned address like src+5, and using that as integer pointer may fail on platforms like ARM. Also this will fail on systems using big-endian (outSize was encoded in little-endian). To fix this, reconstruct outSize in little-endian way. Change-Id: If678e735cb270c3e5e29f36f1fad318096bf7d59 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2246 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-30Extend CBFS to support arbitrary ROM source media.Hung-Te Lin
Summary: Isolate CBFS underlying I/O to board/arch-specific implementations as "media stream", to allow loading and booting romstage on non-x86. CBFS functions now all take a new "media source" parameter; use CBFS_DEFAULT_MEDIA if you simply want to load from main firmware. API Changes: cbfs_find => cbfs_get_file. cbfs_find_file => cbfs_get_file_content. cbfs_get_file => cbfs_get_file_content with correct type. CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM, the ROM may come from USB, UART, or SPI -- any serial devices and not available for memory mapping. To support these devices (and allowing CBFS to read from multiple source at the same time), CBFS operations are now virtual-ized into "cbfs_media". To simplify porting existing code, every media source must support both "reading into pre-allocated memory (read)" and "read and return an allocated buffer (map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*" provides simple memory mapping simulation. Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA is defined for CBFS functions to automatically initialize a per-board default media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS function names relying on memory mapped backend (ex, "cbfs_find" => actually loads files). Now we only have two getters: struct cbfs_file *entry = cbfs_get_file(media, name); void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type); Test results: - Verified to work on x86/qemu. - Compiles on ARM, and follow up commit will provide working SPI driver. Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2182 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-22src/lib/timestamp.c: Fix spelling of tim*e*stampPaul Menzel
Change-Id: I96d41882c92e577ce816264c493376d2f2d950f6 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2181 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
2013-01-19Update gcov patch in documentationStefan Reinauer
.. to reflect the recent changes w.r.t avoiding trouble with the coreboot pre-commit hooks. and fix two whitespace errors. Change-Id: I6c94e95dd439940cf3b44231c8aab5126e9d45c7 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2158 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-01-14Make the pre-commit-hook happy about the code in libgcov.cRonald G. Minnich
Make the comments match what pre-commit-hook wants. Change-Id: Ib99a6583f97221df3638bd3b7723f51d5f9c223c Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2143 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-12Implement GCC code coverage analysisStefan Reinauer
In order to provide some insight on what code is executed during coreboot's run time and how well our test scenarios work, this adds code coverage support to coreboot's ram stage. This should be easily adaptable for payloads, and maybe even romstage. See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for more information. To instrument coreboot, select CONFIG_COVERAGE ("Code coverage support") in Kconfig, and recompile coreboot. coreboot will then store its code coverage information into CBMEM, if possible. Then, run "cbmem -CV" as root on the target system running the instrumented coreboot binary. This will create a whole bunch of .gcda files that contain coverage information. Tar them up, copy them to your build system machine, and untar them. Then you can use your favorite coverage utility (gcov, lcov, ...) to visualize code coverage. For a sneak peak of what will expect you, please take a look at http://www.coreboot.org/~stepan/coreboot-coverage/ Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2052 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Martin Roth <martin@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-08Only include libgcc wrappers on x86Stefan Reinauer
ARM does not need them, and they're causing trouble Change-Id: I6c70a52c68fdcdbf211217d30c96e1c2877c7f90 Signed-off-by: David Hendricks <dhendrix@chromium.org> Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2009 Tested-by: build bot (Jenkins)
2012-12-06Unify assembler function handlingStefan Reinauer
Instead of adding regparm(0) to each assembler function called by coreboot, add an asmlinkage macro (like the Linux kernel does) that can be different per architecture (and that is empty on ARM right now) Change-Id: I7ad10c463f6c552f1201f77ae24ed354ac48e2d9 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1973 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-30Drop boot directoryStefan Reinauer
It only has two files, move them to src/lib Change-Id: I17943db4c455aa3a934db1cf56e56e89c009679f Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1959 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2012-11-30src/lib/Makefile.inc: Add license headerStefan Reinauer
Change-Id: If8bce4ebde9101ac9087fcbd43adc0e08c26352d Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/1957 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-30Make set_boot_successful depend on PC80_SYSTEMStefan Reinauer
Set_boot_successful depends on CMOS parts that non-PC80 platforms do not have. For now, make the current path depend on CONFIG_PC80_SYSTEM, and make the alternative empty. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: I68cf63367c8054d09a7a22303e7c04fb35ad0153 Reviewed-on: http://review.coreboot.org/1954 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2012-11-30Make libgcc wrappers arch-specific, add ARMv7David Hendricks
Change-Id: Ia0bbd3bec6588219ce24951c0bcebefc6b6ec80e Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/1940 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2012-11-27Get rid of drivers classPatrick Georgi
The use of ramstage.a required the build system to handle some object files in a special way, which were put in the drivers class. These object files didn't provide any symbols that were used directly (but only via linker magic), and so the linker never considered them for inclusion. With ramstage.a gone, we can drop this special class, too. Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/1872 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-14Tell CBMEM code about ACPI GNVS sectionStefan Reinauer
We moved GNVS to it's own section, but forgot to tell the cbmem code about it. This is purely cosmetical, but add it anyways. Change-Id: Icb3788c0325ea79cc1efff4a876412d07da7936e Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1782 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-13Clean up stack checking codeStefan Reinauer
Several small improvements of the stack checking code: - move the CPU0 stack check right before jumping to the payload and out of hardwaremain (that file is too crowded anyways) - fix prototype in lib.h - print size of used stack - use checkstack function both on CPU0 and CPU1-x - print amount of stack used per core Signed-off-by: Stefan Reinauer <reinauer@google.com> Test: Boot coreboot on Link, see the following output: ... CPU1: stack: 00156000 - 00157000, lowest used address 00156c68, stack used: 920 bytes CPU2: stack: 00155000 - 00156000, lowest used address 00155c68, stack used: 920 bytes CPU3: stack: 00154000 - 00155000, lowest used address 00154c68, stack used: 920 bytes ... Jumping to boot code at 1110008 CPU0: stack: 00157000 - 00158000, lowest used address 00157af8, stack used: 1288 bytes Change-Id: I7b83eeee0186559a0a62daa12e3f7782990fd2df Reviewed-on: http://review.coreboot.org/1787 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-13Add method for delaying adding of timestampsStefan Reinauer
In hardwaremain() we can't add timestamps before we actually reinitialized the cbmem area. Hence we kept the timestamps in an array and added them later. This is ugly and intrusive and helped hiding a bug that prevented any timestamps to be logged in hardwaremain() when coming out of an S3 resume. The problem is solved by moving the logic to keep a few timestamps around into the timestamp code. This also gets rid of a lot of ugly ifdefs in hardwaremain.c Change-Id: I945fc4c77e990f620c18cbd054ccd87e746706ef Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1785 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-30USBDEBUG: retry harder for slow devicesSven Schnelle
Some usb debug devices don't respond fast enough. The linux kernel (which uses almost the same usbdebug code) added a bit more retry code, so let's copy that. Even if it might look stupid, i pass the DBG_LOOPS argument through all functions to keep the code at least a bit in sync with the linux kernel code. Change-Id: I7c4b63b8bf1d2270fd6b8c8aa835e2cb324820bd Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-on: http://review.coreboot.org/1375 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-07-26USBDEBUG: buffer up to 8 bytesSven Schnelle
EHCI debug allows to send message with 8 bytes length, but we're only sending one byte in each transaction. Buffer up to 8 bytes to speed up debug output. Change-Id: I9dbb406833c4966c3afbd610e1b13a8fa3d62f39 Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-on: http://review.coreboot.org/1357 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.huber@secunet.com>
2012-07-24SMM: Add support for malloc in SMM if using TSEGDuncan Laurie
This is used by the SPI driver and ELOG. It requires SMM TSEG and a _heap/_eheap region defined in the linker script. The first time malloc is called in SMM the start and end pointers to the heap region will be relocated for the TSEG region. Enable SPI flash and ELOG in SMM and successfully allocate memory. The allocated addresses are verified to be sure they are within the TSEG heap region: smm.elf:00014000 B _eheap smm.elf:00010000 B _heap TSEG base is 0xad000000 Memory allocated in ELOG: ELOG: MEM @0xad018030 Change-Id: I5cca38e4888d597cbbfcd9983cd6a7ae3600c2a3 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/1312 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-24Implement stack overflow checking for the BSPRonald G. Minnich
Previous patches implemented stack overflow checking for the APs. This patch builds on the BSP stack poisoning patch to implement stack overflow checking for the BSP, and also prints out maximum stack usage. It reveals that our 32K stack is ridiculously oversized, especially now that the lzma decoder doesn't use a giant 16K on-stack array. Break the stack checking out into a separate function, which we will later use for the APs. CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8 To test failure, change the DEADBEEF stack poison value in c_start.S to something else. Then we should get an error like this: Stack overrun on BSP.Increase stack from current 32768 bytes CPU0: stack from 00180000 to 00188000:Lowest stack address 00180000 Separate the act of loading from the act of starting the payload. This allows us better error management and reporting of stack use. Now we see: CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8 Tested for both success and failure on Link. At the same time, feel free to carefully check my manipulation of _estack. Change-Id: Ibb09738b15ec6a5510ac81e45dd82756bfa5aac2 Signed-off-by: Ronald G. Minnich <rminnich@chromium.org> Reviewed-on: http://review.coreboot.org/1286 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-24Shrink the stack sizes we need in corebootRonald G. Minnich
We accomplish this goal by getting rid of the huge auto array in the ram stage. This will in turn let us reduce CONFIG_STACK_SIZE. We have to leave it on the stack in CAR as that's the simple way to keep it private. It does not matter then as there is only one core that is active. Change-Id: Ie37a057ccae088b7f3bb4aab6de2713e64d96df6 Signed-off-by: Ronald G. Minnich <rminnich@chromium.org> Reviewed-on: http://review.coreboot.org/1271 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-24Remove unused free() functionStefan Reinauer
Since coreboot is running very short, we don't free memory. Hence, drop (dummy) free() Change-Id: I6e2737f07c6b9f73ebfad7d124b97a57cb7454a3 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1274 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-24malloc/memalign: Remove unneeded linker checkStefan Reinauer
This check got in the code when some Linux distros shipped broken linkers around 1999. Since then, the code around that check was changed, and it does not make sense anymore to have this check. Change-Id: I37c6b690d72f55c18ba4c34e8541a6a441e5e67a Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/1275 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-24Make memalign print useful messages on failureRonald G. Minnich
Brevity is the soul of wit, except for error messages; then it's a sign of witlessness. I can say this because this error message may be my fault, although it is lost in the 20th century code base so who knows. Anyway, when memalign dies, it's not a bad idea to have a lot of information about what went wrong. So instead of the terse single bit of "something failed" this patch changes things to be a bit more useful. Change-Id: I8851502297e0ae9773912839ebfdf4f9574c8087 Signed-off-by: Ronald G. Minnich <rminnich@chromium.org> Reviewed-on: http://review.coreboot.org/1270 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2012-05-08Don't loop infinitely long on serial comm failuresStefan Reinauer
If serial uart (8250/16x50) takes abnormally long to respond, give up on logging to serial console and instead let the system boot. Also reference bit in LSR register with correct name. Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Ported from 9dd3ef165a1bf1bc404056d3e54337de1a15ac90 to uart8250mem.c: Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: Iaca4f57389c887110e6406d45053935891c96838 Reviewed-on: http://review.coreboot.org/826 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Peter Stuge <peter@stuge.se> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2012-05-04Make CBFS output more consistentStefan Reinauer
- Prefix all CBFS output messages with CBFS: - Add an option DEBUG_CBFS that is off by default. Without DEBUG_CBFS enabled, the code will no longer print all the files it walks for every file lookup. - Add DEBUG() macro next to LOG() and ERROR() to specify which messages should only be visible with DEBUG_CBFS printed. - Actually print a message when the file we're looking for was found. :) old: Searching for fallback/coreboot_ram Check cmos_layout.bin Check pci8086,0106.rom Check fallback/romstage Check fallback/coreboot_ram Change-Id: I2d731fae17a5f6ca51d435cfb7a58d6e017efa24 Stage: loading fallback/coreboot_ram @ 0x100000 (540672 bytes), entry @ 0x100000 Stage: done loading. new: CBFS: Looking for 'fallback/coreboot_ram' CBFS: found. CBFS: loading stage fallback/coreboot_ram @ 0x100000 (507904 bytes), entry @ 0x100000 CBFS: stage loaded. Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/993 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-05-03Tell CBMEM pretty printer about MRC cacheStefan Reinauer
Sandybridge memory initialization produces some amount of training data that has to be kept around in CBMEM. Add a descriptive name to the CBMEM pretty printer to prevent it from just printing the hex value. Change-Id: I587c0bc3dfcf389ba298d445d2594eef73bc69a8 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/990 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-04-16S3 code in coreboot public folder.zbao
1. Move the Stack to high memory. 2. Restore the MTRR before Coreboot jump to the wakeup vector. Change-Id: I9872e02fcd7eed98e7f630aa29ece810ac32d55a Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: zbao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/623 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marcj303@gmail.com>
2012-04-12Add support for aligned allocationRon Minnich
Add a memalign function and have malloc use it. Also, change the default alignment for malloc to u64-aligned. Change-Id: I0788637008f5cb5ac801d8bbdc430ca992c98e81 Signed-off-by: Ron Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/887 Tested-by: build bot (Jenkins) Reviewed-by: Mathias Krause <minipli@googlemail.com>
2012-04-04Use fast memset in SMM mode, tooStefan Reinauer
... and always include IP checksumming in romstage. It's generally useful and our upcoming port needs it. Change-Id: I248402d96a23e58354744e053b9d5cca6b74ad3a Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/827 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-30Add native memset() function on x86Stefan Reinauer
Change-Id: Ia118ebe0a4b59bdcefd78895141a365170f6aed2 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/737 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2012-03-30Add faster, architecture dependent memcpy()Stefan Reinauer
Change-Id: I38d15f3f1ec65f0cb7974d2dd4ae6356433bddd8 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: http://review.coreboot.org/736 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2012-03-29Add infrastructure for global data in the CAR phase of bootGabe Black
The cbmem console structure and car global data are put in their own section, with the cbmem console coming after the global data. These areas are linked to be where CAR is available and at the very bottom of the stack. There is one shortcoming of this change: The section created by this change needs to be stripped out by the Makefile since leaving it in confuses cbfstool when it installs the stage in the image. I would like to make the tools link those symbols at the right location but leave allocation of that space out of the ELF. Change-Id: Iccfb99b128d59c5b7d6164796d21ba46d2a674e0 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/727 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-03-29CBMEM CONSOLE: Enable coreboot CBMEM console.Vadim Bendebury
The appropriate Makefiles are modified to include the required source code in compilation. Change-Id: I91842b1ba0f89d611d3249b63c020a2713a9124f Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/722 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-29CBMEM CONSOLE: Add CBMEM type for console buffer.Vadim Bendebury
Add CBMEM type for the console buffer section. Change-Id: I02757c06d71e46af77b02b90b0e6018a37b62406 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/720 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-29CBMEM CONSOLE: Add CBMEM console driver implementation.Vadim Bendebury
The CBMEM console driver saves console output in a CBMEM area, which then is made available to Linux applications for perusing. There are some system limitations which need to be worked around to achieve this goal: - some console traffic is generated before DRAM is initialized, leave alone CBMEM initialized. - after the RAM based stage starts, a lot of traffic is generated before CBMEM is initialized. As a result, the console log lives in three different places - the bottom of the cache as RAM space, the CBMEM buffer (where it is expected to be) and a static buffer used early in the RAM stage. When execution starts (in the cache as RAM mode), the console buffer is allocated at the bottom of the cache as RAM memory address range. Once DRAM is initialized, the CBMEM structure is initialized, and then the console buffer contents are copied from the bottom of the cache as RAM space into the CBMEM area right before the cache as RAM mode is disabled. The src/lib/cbmem_console.c:cbmemc_reinit() takes care of the copying. At this point the cache as RAM memory is about to be disabled, but the ROM stage is still going generating console output. To make sure this output is not lost, cbmemc_reinit() saves the new buffer address at a fixed location (0x600 was chosen for this), and the actual "printing" function checks to see if the RAM is already initialized (the stack is in RAM), and if so, gets the console buffer pointer from this location instead of using the cache as RAM address. When the RAM stage starts, a static buffer is used to store the console output, as the CBMEM buffer location is not known. Then, when CBMEM is reinitialized, cbmemc_reinit() again takes care of the copying. In case the allocated buffers are not large enough, the excessive data is dropped, and the copying routine adds some text to the output buffer to indicate that there has been data lost and how many characters were dropped. Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/719 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-28Include arch/acpi.h instead of manually adding acpi_slp_type.Stefan Reinauer
acpi_slp_type is defined in arch/acpi.h, so let's use that instead of manually spreading extern u8 acpi_slp_type throughout the code. Change-Id: Ia5eb420364c15ab5a764bc328bbd201ca9cb7837 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/714 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-28Add timestamp collecting to coreboot.Vadim Bendebury
This patch adds code to initialize the time stamp collection facility in coreboot. It adds a table in the CBMEM section, which provides the base timer reading value (all other readings are offsets of this one) and an array of timestamp id/timestamp value pairs. Just two values are being added now, this will have to be used more extensively and also integrated into payloads to provide more comprehensive boot process time measurements. Also, since the CBMEM area could already contain a section (from the previous run, before reset), when processing a section addition request we should check if a section already exists and return its address, if so. Change-Id: I7ed9f5c400bc5432f228348b41fd19a67c36d533 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/713 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2012-03-28Initialize CBMEM early.Vadim Bendebury
We want to be able to share data between different phases of firmware (rom stage/ram stage/payload). Coreboot CBMEM seems an appropriate location for this data, but normally it is not initialized until coreboot reaches the ram stage. This change initializes the CBMEM while still in rom stage in case CONFIG_EARLY_CBMEM_INIT is set. Note that there is a discrepancy in how coreboot determines the size of DRAM at rom and ram stages, get_top_of_ram() is used at rom stage and is not defined for all platforms. Those platforms will have to define this function should they enable the CONFIG_EARLY_CBMEM_INIT flag. Change-Id: I81691d45e28de59496fb227f2cca4e8c15ece717 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/711 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-25Replace ramtest pattern to assist in DIMM configurationKyösti Mälkki
This is developer's testtool. Output from a "rotate ones" -style pattern helps figure out how DIMM addresses are encoded or routed on a certain mainboard. Scattered test should cover every data and address lines on the memory bus, but is probably limited to the first bank of first DIMM. Change-Id: I533a7a873bcc434f99e7faed9dc9337d9ab64196 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> [pg: rebase] Reviewed-on: http://review.coreboot.org/294 Tested-by: build bot (Jenkins) Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
2012-03-11malloc: size is unsigned, don't test for size < 0Patrick Georgi
clang complains Change-Id: Ifadf73cf377c0d1808e20731803e01101bad7e1d Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/780 Tested-by: build bot (Jenkins) Reviewed-by: Mathias Krause <minipli@googlemail.com>
2012-03-09Fix dependency problem for uart8250.c as wellStefan Reinauer
If you build in parallel, option_table.h will occasionally not be there yet and the build will fail. Change-Id: I828956ab2e05c48d20c2f7c55616cc8fa19e1227 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/698 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-03-09Fix compilation with CONFIG_USE_OPTION_TABLE enabledStefan Reinauer
Change-Id: I6c5d973442bc1770702180a8964f1bf6ed6062ed Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/696 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-09Add support for the Startech PEX1XS1PMINIStefan Reinauer
It has a smaller footprint than the already supported MPEX2S952 Change-Id: Ie36b67f9628882d516ca34ff164f0e8918955a5b Signed-off-by: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: http://review.coreboot.org/690 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-09Add an implementation for the memchr library functionGabe Black
Change-Id: Icded479d246f7cce8a3d2154c69f75178fa513e1 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/708 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Mathias Krause <minipli@googlemail.com>
2012-03-07Move C labels to start-of-linePatrick Georgi
Also mark the corresponding lint test stable. Change-Id: Ib7c9ed88c5254bf56e68c01cdbd5ab91cd7bfc2f Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/772 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-02-17Remove whitespace.Patrick Georgi
Fix issues reported by new lint test. Change-Id: I077a829cb4a855cbb3b71b6eb5c66b2068be6def Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/646 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-02-07Don't loop infinitely long on serial comm failuresKyösti Mälkki
If serial uart (8250/16x50) takes abnormally long to respond, give up on logging to serial console and instead let the system boot. Also reference bit in LSR register with correct name. Change-Id: I3796efc3e8690425f04a130af4bc99541b64d335 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/611 Tested-by: build bot (Jenkins) Reviewed-by: Peter Stuge <peter@stuge.se>
2012-01-12lib: add ram_check_nodieSven Schnelle
The current implementation calls die() if memory checking fails. This isn't always what we want: one might want to print error registers, or do some other error handling. Introduce ram_check_nodie() for that reason. It returns 0 if ram check succeeded, otherwise 1. Change-Id: Ib9a9279120755cf63b5b3ba5e0646492c3c29ac2 Signed-off-by: Sven Schnelle <svens@stackframe.org> Reviewed-on: http://review.coreboot.org/532 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2011-11-02don't scan beyond end of CBFSFlorian Zumbiehl
Change-Id: I66e535f77e513dbfa5fc906ecf288193af78ae62 Signed-off-by: Florian Zumbiehl <florz@florz.de> Reviewed-on: http://review.coreboot.org/369 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2011-11-01remove trailing whitespaceStefan Reinauer
Change-Id: Ib91889a374515d36a2b12b53aeb12b6ea6e22732 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/364 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>