summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
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-21Intel: Update CPU microcode for 6fx CPUsStefan Reinauer
Using the CPU microcode update script and Intel's Linux* Processor Microcode Data File from 2013-02-22 Change-Id: I9bb60bdc46f69db85487ba923e62315f6e5352f9 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2845 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21Intel: Update CPU microcode for 106cx CPUsStefan Reinauer
Using the CPU microcode update script and Intel's Linux* Processor Microcode Data File from 2013-02-22 Change-Id: Icaf0e39978daa9308cc2f0c4856d99fb6b7fdffa Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2844 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21Intel: Update CPU microcode scriptStefan Reinauer
for latest URL of their microcode tar ball Change-Id: I3da2bdac4b2ca7d3f48b20ed389f6a47275d24fe Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2842 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21Butterfly, Stout: Force SATA link speed to 3 GbpsShawn Nematbakhsh
Force link speed on these platforms to 3 Gbps to defeat buggy SATA drives. Change-Id: Ia38a7c486fb1f4469cd67ca5244bbf61f877d556 Signed-off-by: Shawn Nematbakhsh <shawnn@google.com> Reviewed-on: http://review.coreboot.org/2823 Tested-by: build bot (Jenkins) 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-21lynxpoint: Fix up handling for LynxPoint-LP chipsetsDuncan Laurie
This configures power management registers according to the 1.2.0 reference code drop. There are many inconsistencies with the documentation and I tried to note those with ?. This does not do the same for LynxPoint-H yet. Change-Id: I9b8f5c24a8b0931075a44398571c9b0d54cce6a6 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2819 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21lynxpoint: Change sata.c to get rid of #ifDuncan Laurie
This uses the new helper function added earlier. Change-Id: Icdb5d5c51f70eeb7e39e11062276ceb3eb3d9473 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2818 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21lynxpoint: Fix ELOG logging of power management eventsDuncan Laurie
This is updated to handle LynxPoint-H and LynxPoint-LP and a new wake event is added for the power button. Boot, suspend/resume, reboot, etc on WTM2 and then check the event log to see if expected events have been added. Change-Id: I15cbc3901d81f4fd77cc04de37ff5fa048f9d3e8 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2817 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell/lynxpoint: Use new PCH/PM helper functionsDuncan Laurie
This makes use of the new functions from pmutil.c that take care of the differences between -H and -LP chipsets. It also adds support for the LynxPoint-LP GPE0 register block and the SMI/SCI routing differences. The FADT is updated to report the new 256 byte GPE0 block on wtm2/wtm2 boards which is too big for the 64bit X_GPE0 address block so that part is zeroed to prevent IASL and the kernel from complaining about a mismatch. This was tested on WTM2. Unfortunately I am still unable to get an SCI delivered from the EC but I suspect that is due to a magic command needed to put the EC in ACPI mode. Instead I verified that all of the power management and GPIO registers were set to expected values. I also tested transitions into S3 and S5 from both the kernel and by pressing the power button at the developer mode screen and they all function as expected. Change-Id: Ice9e798ea5144db228349ce90540745c0780b20a Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2816 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21lynxpoint: Fix GPIO and PM base reservationsDuncan Laurie
The kernel ACPI was not happy with the Add inside a ResourceTemplate (or perhaps within the IO declaration) Instead make a buffer of IO reservations and turn _CRS into a method that updates the buffer depending on the chipset type. This adds an \ISLP() method that checks the chipset LPC device ID to see if it is -LP or -H. It also increases the PM base reservation to 256 bytes and moves both GPIO and PM base to above 0x1000 on -LP chipsets. Change-Id: I747b658588a4d8ed15a0134009a7c0d74b3916ba Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2815 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21lynxpoint: remove DEBUG_PERIODIC_SMISDuncan Laurie
This was put in for debugging and experimentation on i945 and has been copied around since. Drop it from lynxpoint. Change-Id: I0b53f4e1362cd3ce703625ef2b4988139c48b989 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2814 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21lynxpoint: Add power management helper functionsDuncan Laurie
There are subtle yet significant differences in some of the registers in the power management region between LynxPoint-H and LynxPoint-LP. In order to reduce code that is accessing these registers and would need special cases this adds a number of helper functions that can be used in both ramstage and SMM. This commit just adds the new functions, subsequent commits will start to use them. Change-Id: I411da75da519f5b3198a408078cbf3114e426992 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2813 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21lynxpoint: Add helper functions for reading PM and GPIO baseDuncan Laurie
These base addresses are used in several places and it is helpful to have one location that is reading it. Change-Id: Ibf589247f37771f06c18e3e58f92aaf3f0d11271 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2812 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21lynxpoint: Add function for checking for LP chipsetDuncan Laurie
Add a helper function pch_is_lp() that will return 1 if the current chipset is of the new "low power" variant used with Haswell ULT. Additionally these functions are added to SMM so it can be used there. Change-Id: I9acdea2c56076cd8d9627aba66cf0844c56a38fb Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2811 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21lynxpoint: Enable EC IO ports 0x62/0x66Duncan Laurie
In order to be able to talk to an EC via standard path. Change-Id: I3fe76882dec9a0596cbc1c844afa2ddb03ed771c Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2810 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: Drop the device ID check in graphics init pathDuncan Laurie
Change-Id: I10c4264d317b5fac02a44f50ed10b457e1865e17 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2809 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21lynxpoint: update MBP give up routineAaron Durbin
I'm not sure if I screwed this up originally or the Intel docs changed (I didn't bother to go back and check). According to ME BWG 1.1.0 the give up bit is in the host general status #2 register. Change-Id: Ieaaf524b93e9eb9806173121dda63d0133278c2d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2808 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: RESET_ON_INVALID_RAMSTAGE_CACHE optionAaron Durbin
The RESET_ON_INVALID_RAMSTAGE_CACHE option indicates what to do when the ramstage cache is found to be invalid on a S3 wake. If selected the system will perform a system reset on S3 wake when the ramstage cache is invalid. Otherwise it will signal to load the ramstage from cbfs. Change-Id: I8f21fcfc7f95fb3377ed2932868aa49a68904803 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2807 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: implement ramstage caching in SMM regionAaron Durbin
Cache the relocated ramstage into the SMM region. There is a reserved region within the final SMM region (TSEG). Use that space to cache the relocated ramstage program. That way, on S3 resume there is a copy that can be loaded quickly instead of accessing the flash. Caching the ramstage in the SMM space is also helpful in that it prevents the OS from tampering with the ramstage program. Change-Id: Ifa695ad1c350d5b504b14cc29d3e83c79b317a62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2806 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-21haswell: add multipurpose SMM memory regionAaron Durbin
The SMM region is available for multipurpose use before the SMM handler is relocated. Provide a configurable sized region in the TSEG for use before the SMM handler is relocated. This feature is implemented by making the reserved size a Kconfig option. Also make the IED region a Kconfig option as well. Lastly add some sanity checking on the Kconfig options. Change-Id: Idd7fccf925a8787146906ac766b7878845c75935 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2804 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: set TSEG as WB cacheable in romstageAaron Durbin
The TSEG region is accessible until the SMM handler is relocated to that region. Set the region as cacheable in romstage so that it can be used for other purposes with fast access. Change-Id: I92b83896e40bc26a54c2930e05c02492918e0874 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2803 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21LynxPoint: Move RCBA helper function to its own fileDuncan Laurie
So it can get used in both romstage and ramstage. Change-Id: Ief9eaafdd91df2a7b668de1a9b83aea3af3ff894 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2802 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: support for parallel SMM relocationAaron Durbin
The haswell processors support the ability to save their SMM state into MSR space instead of the memory. This feaure allows for parallel SMM relocation handlers as well as setting the same SMBASE for each CPU since the save state memory area is not used. The catch is that in order determine if this feature is available the CPU needs to be in SMM context. In order to implement parallel SMM relocation the BSP enters the relocation handler twice. The first time is to determine if that feature is available. If it is, then that feature is enabled the BSP exits the relocation handler without relocating SMBASE. It then releases the APs to run the SMM relocation handler. After the APs have completed the relocation the BSP will re-enter the SMM relocation handler to relocate its own SMBASE to the final location. If the parallel SMM feature is not available the BSP relocates its SMBASE as it did before. This change also introduces the BSP waiting for the APs to relocate their SMBASE before proceeding with the remainder of the boot process. Ensured both the parallel path and the serial path still continue to work on cold, warm, and S3 resume paths. Change-Id: Iea24fd8f9561f1b194393cdb77c79adb48039ea2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2801 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-21haswell: use s3_resume field in romstage_handoffAaron Durbin
Now that there is a way to disseminate the presence of s3 wake more formally use that instead of hard coded pointers in memory and stashing magic values in device registers. The northbridge code picks up the field's presence in the romstage_handoff structure and sets up the acpi_slp_type variable accordingly. Change-Id: Ida786728ce2950bd64610a99b7ad4f1ca6917a99 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2799 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: cbmem_get_table_location() implementationAaron Durbin
Provide the implemenation of cbmem_get_table_location() so that cbmem can be initialized early in ramstage when CONFIG_EARLY_CBMEM_INIT is enabled. The cbmem tables are located just below the TSEG region. Change-Id: Ia160ac6aff583fc52bf403d047529aaa07088085 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2798 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: add s3_resume fieldAaron Durbin
Provide a field in the romstage_handoff structure to indicate if the current boot is an ACPI S3 wake boot. There are currently quite a few non-standardized ways of passing this knowledge to ramstage from romstage. Many utilize stashing magic numbers in device-specific registers. The addition of this field adds a more formalized method passing along this information. However, it still requires the romstage chipset code to initialize this field. In short, this change does not make this a hard requirement for ramstage. Change-Id: Ia819c0ceed89ed427ef576a036fa870eb7cf57bc Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2796 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-21x86: protect against abi assumptions from compilerAaron Durbin
Some of the functions called from assembly assume the standard x86 32-bit ABI of passing all arguments on the stack. However, that calling ABI can be changed by compiler flags. In order to protect against the current implicit calling convention annotate the functions called from assembly with the cdecl function attribute. That tells the compiler to use the stack based parameter calling convention. Change-Id: I83625e1f92c6821a664b191b6ce1250977cf037a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2794 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: support for CONFIG_RELOCATABLE_RAMSTAGEAaron Durbin
Now that CONFIG_RELOCTABLE_RAMSTAGE is available support it on Haswell-based systems. This patch is comprised of the following changes: 1. Ensure that memory is not preserved when a relocatable ramstage is enabled. There is no need. 2. Pick the proper stack to use after cache-as-ram is torn down. When the ramstage is relocatable, finding a stack to use before vectoring into ramstage is impossible since the ramstage is a black box with an unknown layout. Change-Id: I2a07a497f52375569bae9c994432a8e7e7a40224 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2793 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-21Fix race condition building console codeStefan Reinauer
On ARMv7 the console code can also be built into the bootblock. Currently building the ARM targets on a reasonably fast machine can fail, because console.bootblock.o is attempted to build before build.h is created. This patch adds a specific rule for the bootblock variant of console.c, to match the other variants so that the race condition goes away. Change-Id: I52e4242c66a02f011ef26b854aa50c2606a1f81f Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2873 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-03-21coreboot: introduce romstage_handoff structureAaron Durbin
The romstage_handoff structure is intended to be a way for romstage and ramstage to communicate with one another instead of using sideband signals such as stuffing magic values in pci config or memory scratch space. Initially this structure just contains a single region that indicates to ramstage that it should reserve a memory region used by the romstage. Ramstage looks for a romstage_handoff structure in cbmem with an id of CBMEM_ID_ROMSTAGE_INFO. If found, it will honor reserving the region defined in the romstage_handoff structure. Change-Id: I9274ea5124e9bd6584f6977d8280b7e9292251f0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2791 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.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-21ramstage: prepare for relocationAaron Durbin
The current ramstage code contains uses of symbols that cause issues when the ramstage is relocatable. There are 2 scenarios resolved by this patch: 1. Absolute symbols that are actually sizes/limits. The symbols are problematic when relocating a program because there is no way to distinguish a symbol that shouldn't be relocated and one that can. The only way to handle these symbols is to write a program to post process the relocations and keep a whitelist of ones that shouldn't be relocated. I don't believe that is a route that should be taken so fix the users of these sizes/limits encoded as absolute symbols to calculate the size at runtime or dereference a variable in memory containing the size/limit. 2. Absoulte symbols that were relocated to a fixed address. These absolute symbols are generated by assembly files to be placed at a fixed location. Again, these symbols are problematic because one can't distinguish a symbol that can't be relocated. The symbols are again resolved at runtime to allow for proper relocation. For the symbols defining a size either use 2 symbols and calculate the difference or provide a variable in memory containing the size. Change-Id: I1ef2bfe6fd531308218bcaac5dcccabf8edf932c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2789 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-21armv7: add function for dcache_clean_by_mva()David Hendricks
This adds a function for using the DCCMVAC instruction (dcache clean by MVA at point of coherency (main memory)). We already have the inline defined, it's just not used by anything. Change-Id: Ia0641566a8881335bed8da2963e1db8321d74267 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2871 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: add a helper function for dcache ops by MVADavid Hendricks
This adds a helper function for dcache ops by MVA which will perform the specified operation on a given memory range. This will make it more trivial to add other data cache maintenance routines. Change-Id: I01d746d5fd2f4138257ca9cab9e9d738e73f8633 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2870 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: cosmetic changes to new cache codeDavid Hendricks
This clarifies and/or fixes formatting of some comments and alphabetizes some function prototypes and inlines. It also corrects references to "modified virtual address" (MVA). Change-Id: Ibcdda4febf915cc4a1996a5bbb4ffecbcb50a324 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2869 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: remove old isb() and dsb() macrosDavid Hendricks
This removes some old macros that we no longer use. Change-Id: I9d87beb5c2deca228cdf89a98e54b2779be0f0ea Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2868 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-21armv7: move armv7_invalidate_caches() to cache.cDavid Hendricks
This just moves cache maintenance stuff from the armv7 bootblock code to cache.c Change-Id: I0b3ab58a1d8a3fe3d9568e02e156a36b6f33ca0b Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2867 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
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-20f15tn/Include/OptionIdsInstall.h: Remove idle `… || )`Siyuan Wang
Change-Id: I4aba6cc490ab24c6db345c0c5a64a6a9985ed0ab Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/2864 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-20ARM: remove assembly code dump when stages.o is builtRonald G. Minnich
For diagnostic purposes we had been dumping the assembly code when stages.o was built. We've past the need to do this and it's confusing to watch. Change-Id: Ib84cb73ed9dad3454efcb2be90d990ce88575229 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2555 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-20ARM: Fix the ldscripts so that exit/enter stage work correctly.Ronald G. Minnich
Remove the spurious creation of a start symbol, and use the stage_entry symbol directly. Change-Id: Ia62d5c056ac8b20c8ffdb78bff3d306065b6c45f Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2560 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 13:34:42 +0000