summaryrefslogtreecommitdiff
path: root/src/lib/hardwaremain.c
AgeCommit message (Collapse)Author
2015-01-27CBMEM: Add timestamp_reinit()Kyösti Mälkki
This avoids the need for separate timestamp_reinit() calls made via CAR_MIGRATE() that is not implemented for ARM. Change-Id: Ia683162f3cb5d3cb3d4b7983a4b7e13306b0cfc8 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8033 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2015-01-05timestamps: Switch from tsc_t to uint64_tStefan Reinauer
Cherry-pick from chromium and adjusted for added boards and changed directory layout for arch/arm. Timestamp implementation for ARMv7 Abstract the use of rdtsc() and make the timestamps uint64_t in the generic code. The ARM implementation uses the monotonic timer. Original-Signed-off-by: Stefan Reinauer <reinauer@google.com> BRANCH=none BUG=chrome-os-partner:18637 TEST=See cbmem print timestamps Original-Change-Id: Id377ba570094c44e6895ae75f8d6578c8865ea62 Original-Reviewed-on: https://gerrit.chromium.org/gerrit/63793 (cherry-picked from commit cc1a75e059020a39146e25b9198b0d58aa03924c) Change-Id: Ic51fb78ddd05ba81906d9c3b35043fa14fbbed75 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8020 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-10-19ACPI: Allocate S3 resume backup in CBMEM earlierKyösti Mälkki
These allocations are not really part of write_tables() and the move opens possibilities to use CBMEM instead of SPI Flash to restore some parts of system state after S3 resume. Change-Id: I0c36bcee3f1da525af077fc1d18677ee85097e4d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7097 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-09-13arm: Move exception_init() close to console_init()Julius Werner
This patch adds stub implementations of exception_init() to all archs so that it can be called from src/lib/hardwaremain.c. It also moves/adds all other invocations of exception_init() (which needs to be rerun in every stage) close to console_init(), in the hopes that it will be less likely overlooked when creating future boards. Also added (an ineffective) one to the armv4 bootblock implementations for consistency and in case we want to implement it later. Change-Id: Iecad10172d25f6c1fc54b0fec8165d7ef60e3414 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/176764 Reviewed-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 2960623f4a59d841a13793ee906db8d1b1c16c5d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6884 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2014-07-03ACPI: Recover type of wakeup in acpi_is_wakeup()Kyösti Mälkki
Update acpi_slp_type early in ramstage. Change-Id: I30ec2680d28b880171217e896f48606f8691b099 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/6142 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-03-03coreboot: unify infrastructure for loading payloadsAaron Durbin
A payload can be loaded either from a vboot region or from cbfs. Provide a common place for choosing where the payload is loaded from. Additionally, place the logic in the 'loaders' directory similarly to the ramstage loader infrastructure. Change-Id: I6b0034ea5ebd04a3d058151819ac77a126a6bfe2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5296 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-11-26Clean up POST codes for Boot State machineDuncan Laurie
Now that there is a clearly defined boot state machine we can add some useful post codes to indicate the current point in the state machine by having it log a post code before the execution of each state. This removes the currently defined POST codes that were used by hardwaremain in favor of a new contiguous range that are defined for each boot state. The reason for this is that the existing codes are mostly used to indicate when something is done, which is confusing for actual debug because POST code debugging relies on knowing what is about to happen (to know what may be at fault) rather than what has just finished. One additonal change is added during device init step as this step often does the bulk of the work, and frequently logs POST codes itself. Therefore in order to keep better track of what device is being initialized POST_BS_DEV_INIT is logged before each device is initialized. interrupted boot with reset button and gathered the eventlog. Mosys has been extended to decode the well-known POST codes: 26 | 2013-06-10 10:32:48 | System boot | 120 27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize 28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0 29 | 2013-06-10 10:32:48 | Reset Button 30 | 2013-06-10 10:32:48 | System Reset Change-Id: Ida1e1129d274d28cbe8e49e4a01483e335a03d96 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58106 Reviewed-on: http://review.coreboot.org/4231 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-11-08Add new finalize functions for devices and chipsMarc Jones
Many chipset devices require additional configuration after device init. It is not uncommmon for a device early in the devicetree list to need to change a setting after a device later in the tree does PCI init. A final function call has been added to device ops to handle this case. It is called prior to coreboot table setup. Another problem that is often seen is that the chipset or mainboard need to do some final cleanup just before loading the OS. The chip finalize has been added for this case. It is call after all coreboot tables are setup and the payload is ready to be called. Similar functionality could be implemented with the hardwaremain states, but those don't fit well in the device tree function pointer structure and should be used sparingly. Change-Id: Ib37cce104ae41ec225a8502942d85e54d99ea75f Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/4012 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-09-21CBMEM: Always select CAR_MIGRATIONKyösti Mälkki
If romstage does not make cbmem_initialize() call, linker should optimize the code for CAR migration away. This simplifies design of CBMEM console by a considerable amount. As console buffer is now migrated within cbmem_initialize() call there is no longer need for cbmemc_reinit() call made at end of romstage. Change-Id: I8675ecaafb641fa02675e9ba3f374caa8e240f1d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3916 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-21timestamps: Use stash before CBMEM is usableKyösti Mälkki
Change-Id: I9e927abdb1d7d9c233de5620a9a65b419e803ebf Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3909 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-10Drop ELF remains from boot codeStefan Reinauer
This stuff is not used, so let's drop it. Change-Id: I671a5e87855b4c59622cafacdefe466ab3d70143 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3660 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Rename hardwaremain() to main()Stefan Reinauer
... and drop the wrapper on ARMv7 Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3639 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-20fix bootstate typo (bs_dev_eanble -> bs_dev_enable)David Hendricks
Change-Id: I2e3fd58404c48e863a3a1b255337fb397086651b Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3506 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-14coreboot: add thread cooperative multitaskingAaron Durbin
The cooperative multitasking support allows the boot state machine to be ran cooperatively with other threads of work. The main thread still continues to run the boot state machine (src/lib/hardwaremain.c). All callbacks from the state machine are still ran synchronously from within the main thread's context. Without any other code added the only change to the boot sequence when cooperative multitasking is enabled is the queueing of an idlle thread. The idle thread is responsible for ensuring progress is made by calling timer callbacks. The main thread can yield to any other threads in the system. That means that anyone that spins up a thread must ensure no shared resources are used from 2 or more execution contexts. The support is originally intentioned to allow for long work itesm with busy loops to occur in parallel during a boot. Note that the intention on when to yield a thread will be on calls to udelay(). Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3206 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-08hardwaremain: drop boot_complete parameterStefan Reinauer
it has been unused since 9 years or so, hence drop it. Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3212 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-07boot state: remove drain timers optionAaron Durbin
Internally there were states that had an attribute to indicate that the timers needed to be drained. Now that there is a way to block state transitions rely on this ability instead of draining timers. The timers will drain themselves when a state is blocked. Change-Id: I59be9a71b2fd5a17310854d2f91c2a8957aafc28 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3205 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-07boot state: add ability to block state transitionsAaron Durbin
In order to properly sequence the boot state machine it's important that outside code can block the transition from one state to the next. When timers are not involved there's no reason for any of the existing code to block a state transition. However, if there is a timer callback that needs to complete by a certain point in the boot sequence it is necessary to place a block for the given state. To that end, 4 new functions are added to provide the API for blocking a state. 1. boot_state_block(boot_state_t state, boot_state_sequence_t seq); 2. boot_state_unblock(boot_state_t state, boot_state_sequence_t seq); 3. boot_state_current_block(void); 4. boot_state_current_unblock(void); Change-Id: Ieb37050ff652fd85a6b1e0e2f81a1a2807bab8e0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3204 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-01boot state: run timers on state entryAaron Durbin
When TIMER_QUEUE is configured on call the timer callbacks on entry into a state but before its entry callbacks. In addition provide a barrier to the following states so that timers are drained before proceeding. This allows for blocking state traversal for key components of boot. BS_OS_RESUME BS_WRITE_TABLES BS_PAYLOAD_LOAD BS_PAYLOAD_BOOT Future functionality consists of evaluating the timer callbacks within the device tree. One example is dev_initialize() as that seems state seems to take 90% of the boot time. The timer callbacks could then be ran in a more granular manner. Change-Id: Idb549ea17c5ec38eb57b4f6f366a1c2183f4a6dd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3159 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot state: track times for each stateAaron Durbin
When the MONOTONIC_TIMER is available track the entry, run, and exit times for each state. It should be noted that the times for states that vector to OS or a payload do not have their times reported. Change-Id: I6af23fe011609e0b1e019f35ee40f1fbebd59c9d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3156 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot state: rebalance payload load vs actual bootAaron Durbin
The notion of loading a payload in the current boot state machine isn't actually loading the payload. The reason is that cbfs is just walked to find the payload. The actual loading and booting were occuring in selfboot(). Change this balance so that loading occurs in one function and actual booting happens in another. This allows for ample opportunity to delay work until just before booting. Change-Id: Ic91ed6050fc5d8bb90c8c33a44eea3b1ec84e32d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3139 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot: remove cbmem_post_handling()Aaron Durbin
The cbmem_post_handling() function was implemented by 2 chipsets in order to save memory configuration in flash. Convert both of these chipsets to use the boot state machine callbacks to perform the saving of the memory configuration. Change-Id: I697e5c946281b85a71d8533437802d7913135af3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3137 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01cbmem: use boot state machineAaron Durbin
There were previously 2 functions, init_cbmem_pre_device() and init_cbmem_post_device(), where the 2 cbmem implementations implemented one or the other. These 2 functions are no longer needed to be called in the boot flow once the boot state callbacks are utilized. Change-Id: Ida71f1187bdcc640ae600705ddb3517e1410a80d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3136 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01coverage: use boot state callbacksAaron Durbin
Utilize the static boot state callback scheduling to initialize and tear down the coverage infrastructure at the appropriate points. The coverage initialization is performed at BS_PRE_DEVICE which is the earliest point a callback can be called. The tear down occurs at the 2 exit points of ramstage: OS resume and payload boot. Change-Id: Ie5ee51268e1f473f98fa517710a266e38dc01b6d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3135 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01acpi: split resume check and actual resume codeAaron Durbin
It's helpful to provide a distinct state that affirmatively describes that OS resume will occur. The previous code included the check and the actual resuming in one function. Because of this grouping one had to annotate the innards of the ACPI resume path to perform specific actions before OS resume. By providing a distinct state in the boot state machine the necessary actions can be scheduled accordingly without modifying the ACPI code. Change-Id: I8b00aacaf820cbfbb21cb851c422a143371878bd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3134 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot state: schedule static callbacksAaron Durbin
Many of the boot state callbacks can be scheduled at compile time. Therefore, provide a way for a compilation unit to inform the boot state machine when its callbacks should be called. Each C module can export the callbacks and their scheduling requirements without changing the shared boot flow code. Change-Id: Ibc4cea4bd5ad45b2149c2d4aa91cbea652ed93ed Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3133 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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-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-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-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-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-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-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-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)
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-13 15:58:28 +0000