aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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-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-05-01string: Add STRINGIFY macroAaron Durbin
STRINGIFY makes a string from a token. It is generally useful. Even though STRINGIFY is not defined to be in the C library it's placed in string.h because it does make a string. Change-Id: I368e14792a90d1fdce2a3d4d7a48b5d400623160 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3144 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-30Google/Snow: Remove unnecessary serial console init code.Hung-Te Lin
The "console_init" does initialize UART driver (which will setup peripheral and pinmux) and print starting message. Duplicated initialization can be removed. Also, console_init (from console.c) is always linked to bootblock (and will do nothing if CONFIG_EARLY_CONSOLE is not defined) so it's safe to remove #ifdef. Verified by building and booting on Google/Snow, with and without CONFIG_EARLY_CONSOLE. Change-Id: I0c6b4d4eb1a4e81af0f65bcb032978dfb945c63d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3150 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-30Lenovo ThinkPad X60: Init CBMEM early for CBMEM console support.Denis 'GNUtoo' Carikli
Enable `EARLY_CBMEM_INIT` for CBMEM console support by looking how other boards do this. This commit is tested by enabling the CBMEM console (`CONSOLE_CBMEM` in Kconfig) and then in GRUB 2 (as a payload) with the cbmemc command from the cbmemc module and in userspace with ./cbmem -c. Both worked. Change-Id: I34618a55ded7292a411bc232eb76267eec17d91e Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3142 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-04-30Google/Snow: Temporary fix for resume failure.Hung-Te Lin
The DDR3 memory initialization (with "mem_reset" set on normal boot) will cause resume to be unstable, especially when X is running. System may show X screen for few seconds, then crash randomly and unable to recover - although text console may still work for a while. Probably caused by corrupted memory pages. 'mem_reset' (which refers to RESET# in DDR3 spec) should be enabled according to DDR3 spec. But it seems that on Exynos 5, memory can be initialized without setting mem_reset for both normal boot and resume - at least no known failure cases are found yet. So this can be a temporary workaround. Verified by booting a Google/Snow device with X Window and ChromeOS, entering browser session with fancy web pages, closing LID to suspend for 5 seconds, then re-opening to resume. Suspend/resume worked as expected. Also tried the "suspend_stress_test" with X running and finished 100 iterations of suspend/resume test without failure. Change-Id: I7185b362ce8b545fe77b35a552245736c89d465e Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3148 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-29Google/Snow: Enable suspend/resume.Hung-Te Lin
Add the suspend/resume feature into bootblock and romstage. Note, resuming with X and touchpad driver may be still unstable. Verified by building and booting successfully on Google/Snow, and then executing the "suspend_stress_test" in text mode ("stop ui; suspend_stress_test") in Chromium OS, passed at least 20 iterations. Change-Id: I65681c42eeef2736e55bb906595f42a5b1dfdf11 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3102 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-04-26google/snow: Revise romstage initialization code.Hung-Te Lin
Move board setup procedure to snow_setup_* functions, and Snow board-specific (wakeup) code to snow_* for better function names and comments. Verified by successfully building and booting on Google/Snow. Change-Id: I2942d75064135093eeb1c1da188a005fd255111d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3130 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-04-26Intel 82801gx: Use 2 << 24 to clarify that I/O APIC ID is 2Paul Menzel
Commit »Support for the Intel ICH7 southbridge.« (debb11fc) [1] used `1 << 25` to set the I/O APIC ID of 2. Instead using `2 << 24`, which is the same value, makes it clear, that the I/O APIC ID is 2. Commit »Intel Panther Point PCH: Use 2 << 24 to clarify that APIC ID is 2« (8c937c7e) [2] is used as a template. [1] http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=debb11fc1fe5f5560015ab9905f1ccc2e08c73e0 [2] http://review.coreboot.org/3100 Change-Id: Ib688500944cd78a1cc1c8082bb138fa9468bdbfb Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3122 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-26exynos5250: uncomment $(INTERMEDIATE)David Hendricks
This makes the intermediate rule visible so BL1 gets automatically placed in the final image. Change-Id: Iffb0268e5bbcbe135f2d39863ed64fa302409a22 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3141 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-04-26armv7: invoke intermediate build rulesDavid Hendricks
This adds $$(INTERMEDIATE) as a pre-requisite for coreboot.rom on armv7. It is modeled after the $(obj)/coreboot.rom rule for x86. Change-Id: I483a88035fa2288829b6e042e51ef932c8c4f23c Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2095 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-04-25google/snow: Add "wakeup" module for suspend/resume.Hung-Te Lin
The "wakeup" procedure will be shared by bootblock and romstage for different types of resume processes. Note, this commit does not include changes in romstage/bootblock to enable suspend/resume feature. Simply adding functions to handle suspend/resume. Verified by successfully building and booting Google/Snow firmware image. Change-Id: I17a256afb99f2f8b5e0eac3393cdf6959b239341 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3129 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-25arm/exynos: Allow DRAM controller to be initialized without clearing RAM ↵Hung-Te Lin
content. To support suspend/resume, PHY control must be reset only on normal boot path. So add a new param "mem_reset" to specify that. Verified to boot successfully on Google/Snow. Change-Id: Id49bc6c6239cf71a67ba091092dd3ebf18e83e33 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3128 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-23AMD Thatcher: ConnectorTypeDP supports both DP and HDMISiyuan Wang
It seems that ConnectorTypeDP in DdiList supports both DP and HDMI monitors. I tested by DP monitor and HDMI monitor connected by passive DP->HDMI adapter. Video and audio are OK. Hot plugging is also supported. This commit partially reverts commit >AMD Thatcher: Fix PCIE link issues< (7f23aeb0) [1]. [1] http://review.coreboot.org/3011 Change-Id: I23cf1c69a8274f47daf56f1a12aafd88bad4a128 Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/3088 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-23GOOGLE/SNOW: get graphics workingRonald G. Minnich
This adds support for display bring-up on Snow. It includes framebuffer initialization and LCD enable functions. Change-Id: I16e711c97e9d02c916824f621e2313297448732b Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3116 Tested-by: build bot (Jenkins)
2013-04-23Intel microcode: Return when `microcode_updates` is `NULL`Vladimir Serbinenko
Add a safety check in function `intel_update_microcode` to return when accidentally `NULL` is passed as `microcode_updates`, which would lead to a null pointer dereference later on. for (c = microcode_updates; m->hdrver; m = (const struct microcode *)c) { While at it, use `return NULL` for clarity in function `intel_microcode_find` and include the header file `stddef.h`. for it. The review of this patch had some more discussion on adding more comments and more detailed error messages. But this should be done in a separate patch. For clarity here some history, on how this was found and what caused the discussion and confusion. Originally when Vladimir made this improvement, selecting `CPU_MICROCODE_IN_CBFS` in Kconfig but not having the microcode blob `cpu_microcode_blob.bin` in CBFS resulted in a null pointer dereference later on causing a crash. for (c = microcode_updates; m->hdrver; m = (const struct microcode *)c) { Vladimir fixed this by returning if `microcode_updates` is `NULL`, that means no file is found and successfully tested this on his Lenovo X201. When pushing the patch to Gerrit for review, the code was rewritten though by Aaron in commit »intel microcode: split up microcode loading stages« (98ffb426) [1], which also returns when no file is found. So the other parts of the code were checked and the safety check as described above is added. [1] http://review.coreboot.org/2778 Change-Id: I6e18fd37256910bf047061e4633a66cf29ad7b69 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2990 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-04-23exynos5250: ungate the product ID registerDavid Hendricks
This makes sure that the product ID (PRO_ID) register can be read when the OS kernel is figuring out what kind of CPU it's running on. For historical reference, the original U-Boot code seems to have worked basically by accident here. The hardware has a quirk where by reading the value before gating the IP block keeps the value persistent. U-Boot reads the chip ID early on to distinguish between chip family, but we do not mix code the same way so we do not read the chip ID. Since the value has been read before the clock gating happens, the value remains available for the kernel to use during the decompression stage. We don't want to rely on that behavior when using coreboot. Instead the kernel should gate unused IPs. (credit to Gabe for finding symptom in the kernel) Change-Id: Iaa21e6e718b9000b5558f568020f393779fd208e Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3121 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-04-22GOOGLE/SNOW: fix stupid paren errorRonald G. Minnich
This simple error led to corrupted graphics. How annoying. Change-Id: I2295c0df0f1d16014a603dc5d66bd4d72f3fb7c9 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3120 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-04-22superiotool: add CR dump for W83627UHG = NCT6627UDFrank Rysanek
This commit adds "register dump capability" to superiotool for a specific chip by Winbond/Nuvoton: the W83627UHG AKA NCT6627UD (same chip, different package). In other words, it fills in the "CR map" definitions in winbond.c, which so far have been void for this chip. - superiotool r4.0-3976-g190011e Found Winbond W83627UHG = NCT6627UD (id=0xa2, rev=0x32) at 0x2e Register dump: idx 02 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f val ff a2 32 ff f0 44 00 00 ff 00 00 00 00 03 00 00 ff def 00 a2 NA ff f0 MM 00 MM RR 00 00 00 00 02 00 00 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 00 00 00 00 02 8e 00 ff 00 00 def 01 03 f0 06 02 8e 00 ff 00 00 LDN 0x01 (Parallel port) idx 30 60 61 70 74 f0 val 00 03 78 0c 04 3f def 01 03 78 07 04 3f LDN 0x02 (UART A) idx 30 60 61 70 f0 val 01 03 f8 04 00 def 01 03 f8 04 00 LDN 0x03 (UART B) idx 30 60 61 70 f0 f1 val 01 02 f8 03 00 44 def 01 02 f8 03 00 00 LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 72 f0 val 01 00 60 00 64 01 0c 82 def 01 00 60 00 64 01 0c 83 LDN 0x06 (UART C) idx 30 60 61 70 f0 val 01 03 e8 05 80 def 01 03 e0 04 00 LDN 0x07 (GPIO 3, GPIO 4) idx 30 e0 e1 e2 e3 e4 e5 e6 e7 val 04 ff ff ff ff ff ff ff ff def 00 ff 00 00 00 ff 00 00 00 LDN 0x08 (WDTO#, PLED, GPIO 5,6 & GPIO Base Address) idx 30 60 61 e0 e1 e2 e3 e4 e5 e6 e7 f5 f6 f7 val 01 00 00 ff ff ff ff ff ff ff ff 02 00 00 def 02 00 00 ff 00 00 00 ff 1f 00 00 00 00 00 LDN 0x09 (GPIO 1, GPIO 2 and SUSLED) idx 30 e0 e1 e2 e3 e4 e5 e6 e7 f3 val 02 ff ff ff ff 00 ff 00 00 00 def 00 ff 00 00 00 ff 00 00 00 00 LDN 0x0a (ACPI) idx 30 70 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 f2 f3 f4 f6 f7 fe val 01 00 01 00 0a 00 00 00 0c 00 09 00 01 00 00 00 00 00 def 00 00 01 00 ff 08 00 00 1c 00 RR RR 3e 00 00 00 00 00 LDN 0x0b (Hardware monitor) idx 30 60 61 70 f0 f1 f2 val 01 02 48 00 81 ff 81 def 00 00 00 00 RR RR 00 LDN 0x0c (PECI, SST) idx e0 e1 e2 e3 e4 e5 e6 e7 e8 f1 f2 f3 fe ff val 00 48 48 48 48 00 00 00 00 4c 50 10 23 5a def 00 48 48 48 48 00 RR RR 00 48 50 10 23 5a LDN 0x0d (UART D) idx 30 60 61 70 f0 val 00 00 00 00 00 def 00 02 e0 03 00 LDN 0x0e (UART E) idx 30 60 61 70 f0 val 00 00 00 00 80 def 00 03 e8 04 00 LDN 0x0f (UART F) idx 30 60 61 70 f0 val 01 02 38 0a 00 def 00 02 e8 03 00 Change-Id: I834f8767b29f3148f353004edb22cfd7db5ddd56 Signed-off-by: Frank Rysanek <Frantisek.Rysanek@post.cz> Reviewed-on: http://review.coreboot.org/3027 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-04-20AMD SB800 based boards: Use `#include <sb_cimx.h>` instead of `"sb_cimx.h"`Paul Menzel
Due to $ more src/southbridge/amd/cimx/sb800/Makefile.inc […] romstage-y += cfg.c romstage-y += early.c romstage-y += smbus.c ramstage-y += cfg.c ramstage-y += late.c […] `src/southbridge/amd/cimx/sb800/` is passed with the switch `-I` to the compiler, where it is also going to find the header file `sb_cimx.h`. Therefore use `#include <sb_cimx>` everywhere, which is what some AMD SB800 based boards already do. The only effect is, that the compiler will not needlessly look into directories which do not contain the header file [1]. The following command was used for the replacement. $ git grep -l sb_cimx.h src/mainboard/ | xargs sed -i 's/#include "sb_cimx.h"/#include <sb_cimx.h>/' [1] http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html Change-Id: I96ab34bac1524e6c38c85dfe9d99cb6ef55e6d7c Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3118 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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-19google/snow: disable unused USB3.0 PLL to save powerDavid Hendricks
This PLL is unused and can be disabled to save about 250mW. Change-Id: I1be37304d6ea5ff78696e05ad1023ce3c57f636c Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3109 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-19exynos5: eliminate lcd_base variableDavid Hendricks
The original imported code used "lcdbase" and "lcd_base" which quite predictably caused confusion and bugs. Let's put an end to this little bit of insanity. Change-Id: I4f995482cfbff5f23bb296a1e6d35beccf5f8a91 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3114 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-04-19google/snow: Minor clean-ups for display setup code in ramstageDavid Hendricks
This just cleans up a few areas: - Removed an unnecessary delay from exynos_dp_bridge_setup() - The delay at the end of exynos_dp_bridge_init() is necessary, so removed the comment suggesting that it might not be. - Simplified exynos_dp_hotplug Change-Id: I44150f5ef3958e333985440c1022b4f1544a93aa Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3113 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-19google/snow: enable clock gating to save powerDavid Hendricks
This enables clock gating to save power on unused IPs. Change-Id: I9ab2a2535ebb91bb4110390a6f055a67146bdbf9 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3110 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-19AMD Parmer: change DdiList to ConnectorTypeDP to support DP and HDMISiyuan Wang
This patch is based on >>AMD Thatcher: ConnectorTypeDP supports both DP and HDMI<< (I23cf1c6) [1] I tested by DP monitor and HDMI monitor connected by passive DP->HDMI adapter. Video and audio are OK. Hot plugging is also supported. [1] http://review.coreboot.org/#/c/3088/ Change-Id: I291beff43609ecb68ece24939f2dbc7c08dd0374 Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/3090 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-19exynos5250: get xres and yres out of the device tree and into the panel ↵Ronald G. Minnich
descriptor We neglected to copy xres and yres out; now we do. Change-Id: Icc4a8eb35799d156b11274f71bcfb4a1d10e01e3 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3111 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-04-19[3/3] google/snow: enable TMUDavid Hendricks
This enables the thermal management unit (TMU) on Snow. Change-Id: Idd76af40bf0a5408baf61ef2665fd52ae4e260ba Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3108 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-04-19[2/3] exynos5: modify thermal management unit code for corebootDavid Hendricks
This updates the Exynos TMU code for coreboot: - Remove dependency on device tree - Add Makefile entries Change-Id: I55e1b624d7c7b695b1253ec55f6ae3de8dc671bc Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3107 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-04-19[1/3] exynos5: import thermal management unit codeDavid Hendricks
This simply imports the Exynos TMU driver from u-boot. It is not built and thus should not break anything. Change-Id: I7861132fbf97f864e4250ffbda1ef3843f296ddc Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3106 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-04-19exynos5: move power_enable_hw_thermal_trip() prototypeDavid Hendricks
This moves the prototype for power_enable_hw_thermal_trip() to a generic location so it can be used by generalized thermal management code. The implementation will still be CPU-specific. Change-Id: Iae449cb8c72c8441dedaf65b73db9898b4730cef Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3105 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
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-18AMD/SB800: Define the GPP PCIe lane distributionDave Frodin
Commit 23023a5 correctly enabled the SB800 GPP PCIe ports but didn't distribute the 4 GPP PCIe lanes amongst the enabled PCIe ports. This fix was verified by openvoid on a AsRock E350M1 motherboard. Change-Id: I0116c5f518e0d000be609013446e53da4112f586 Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/3104 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-18libpayload: Don't sneak in compiler includesStefan Reinauer
The way we got to include the compiler includes was kind of whacky. Instead of mixing in potentially problematic headers, make libpayload self-contained by adding some missing header files. Also clean up conflicting definitions of size_t throughout the tree. Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: I0ad1194de1a00b7133c5477c00eb167d63a2ee85 Reviewed-on: https://gerrit.chromium.org/gerrit/47608 Reviewed-by: Ronald G. Minnich <rminnich@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3058 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-18AMD Fam14: Split out the AMD Fam14 DSDTMike Loptien
Same splitting as done on Persimmon and ASRock. Moving common DSDT code to common areas and adding new files as necessary. Boards updated are: Inagua Union-Station South-Station Change-Id: I8c9eea62996b41cea23a9c16858c4249197f6216 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/3051 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-18Intel i945: ACPI: Add _OSC methodDenis 'GNUtoo' Carikli
Add the ACPI Operating System Capabilities Method and let the operation system control everything. Commit »AMD Fam14 DSDT: Add OSC method« (00a0e76b) [1] is used as a template. The Lenovo X60 [2] running the Parabola GNU/Linux distribution [3] is used for testing. Before that change: $ dmesg | egrep -e OSC -e ASPM [ 0.108036] pci_root PNP0A08:00: ACPI _OSC support notification failed, disabling PCIe ASPM [ 0.108040] pci_root PNP0A08:00: Unable to request _OSC control (_OSC support mask: 0x08) [ 0.118089] ACPI _OSC control for PCIe not granted, disabling ASPM [ 16.874569] e1000e 0000:01:00.0: Disabling ASPM L0s L1 With that change: $ dmesg | egrep -e OSC -e ASPM [ 0.107962] pci_root PNP0A08:00: Requesting ACPI _OSC control (0x1d) [ 0.108003] pci_root PNP0A08:00: ACPI _OSC control (0x1d) granted [ 0.111052] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' [ 17.537970] e1000e 0000:01:00.0: Disabling ASPM L0s L1 [1] http://review.coreboot.org/2738 [2] http://www.coreboot.org/Lenovo_x60x [3] https://parabolagnulinux.org/ Change-Id: I1caffa44eea447d553c01caaf431f2db241ea5ea Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2938 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-18ChromeEC: Drop unneeded Kconfig variable EC_GOOGLE_API_ROOTStefan Reinauer
This used to contain the path for the EC include files, but those files are included in coreboot now. Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: I4fce9831c5e21b0a69a6295dbda2580e1ca83369 Reviewed-on: https://gerrit.chromium.org/gerrit/47606 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3057 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-17armv7/exynos5250: Deprecate sdelay in favor of udelayDavid Hendricks
This gets rid of the clock-tick based sdelay in favor of udelay(). udelay() is more consistent and easier to work with, and this allows us to carry one less variation of timers (and headers and sources...). Every 1 unit in the sdelay() argument was assumed to cause a delay of 2 clock ticks (@1.7GHz). So the conversion factor is roughly: sdelay(N) = udelay(((N * 2) / 1.7 * 10^9) * 10^6) = udelay((N * 2) / (1.7 * 10^3)) The sdelay() periods used were: sdelay(100) --> udelay(1) sdelay(0x10000) --> udelay(78) (rounded up to udelay(100)) There was one instance of sdelay(10000), which looked like sort of a typo since sdelay(0x10000) was used elsewhere. sdelay(10000) should approximate to about 12us, so we'll stick with that for now and leave a note. Change-Id: I5e7407865ceafa701eea1d613bbe50cf4734f33e Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3079 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-17google/snow: enable 32KHz sleep clockDavid Hendricks
Change-Id: I9db91826e4534b8a6eea2b13bcf7c6abd848b4e4 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3075 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-17Samsung/exynos5250: convert unsigned {int,char} to u32/u8Ronald G. Minnich
The types are (esp. int) are confusing at times as to size. Make them definite as to size. Change-Id: Id7808f1f61649ec0a3403c1afc3c2c3d4302b7fb Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3103 Tested-by: build bot (Jenkins) Reviewed-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-04-16AMD Parmer: remove unused macros and turn off unused pcie portSiyuan Wang
1) The macros GNB_GPP_PORTx_PORT_PRESENT, GNB_GPP_PORTx_SPEED_MODE, GNB_GPP_PORTx_LINK_ASPM and GNB_GPP_PORTx_CHANNEL_TYPE are not used. This is based on >AMD Thatcher: remove unused macros in PlatformGnbPcieComplex.h< [1]. 2) Disable unused PCIE port in devicetree.cb. PCIE port 3 is not used in Parmer. This is based on item 3 of >AMD Thatcher: Fix PCIE link issues< [2]. [1] http://review.coreboot.org/#/c/3087/ [2] http://review.coreboot.org/#/c/3011/ Change-Id: Id6f00d5e77ce5133d9ef3db07f95ad03a59e061a Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/3099 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-16cbmem: map_memory: Use length modifier `j` and cast for an `off_t` argumentPaul Menzel
cbmem currently fails to build due to `-Werror` and the following warning. $ make cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c cbmem.c: In function ‘map_memory’: cbmem.c:87:2: error: format ‘%zx’ expects argument of type ‘size_t’, but argument 2 has type ‘off_t’ [-Werror=format] […] Casting the argument of type `off_t` to `intmax_t` and using the length modifier `j` $ man 3 printf […] j A following integer conversion corresponds to an intmax_t or uintmax_t argument. […] instead of `z` as suggested in [1] and confirmed by stefanct and segher in #coreboot on <irc.freenode.net>, gets rid of this warning and should work an 32-bit and 64-bit systems, as an `off_t` fits into `intmax_t`. [1] http://www.pixelbeat.org/programming/gcc/int_types/ Change-Id: I1360abbc47aa1662e1edfbe337cf7911695c532f Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3083 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-16Intel Panther Point PCH: Use 2 << 24 to clarify that APIC ID is 2Vladimir Serbinenko
Commit »Add support for Intel Panther Point PCH« (8e073829) [1] used `1 << 25` to set the APIC ID of 2. Using `2 << 24`, which is the same value, instead makes it clear, that the APIC ID is 2. [1] http://review.coreboot.org/853 Change-Id: I5044dc470120cde2d2cdfc6e9ead17ddb47b6453 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3100 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-04-16snow: Return 0 from get_recovery_mode_from_vbnv.Gabe Black
This function isn't yet used for much, or perhaps anything, but where it appears in the code it's ored with other values. Since we're not actually retrieving anything, it might be best to return 0 so that the other values that are being ored in can be expressed and this function can stay dormant until it actually has something to do. Change-Id: I6edc222a5c2d00ece2ecfad5191a615331eeaf16 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3098 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-04-16snow: Report the state of the power button GPIO in the coreboot tables.Gabe Black
Change-Id: Ia7ce2b7342e186c565b92211e3ac15d80ce24b38 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3097 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-04-16snow: Configure the power button as an input GPIO.Gabe Black
We need to read it to report its value to the payload. The kernel will reconfigure it as an external interrupt, but we'll make it a regular input for now. Change-Id: I019bd2c2731144d3b7bb53fad0c2c903874f616c Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3096 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-04-16snow: Fix the name of some constants in romstage.c.Gabe Black
These names were inherited from chromeos.c where they've already been fixed. Change-Id: I7ad57b979b7b8f42f6bd68d1ecf887caba3fa3f1 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3095 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-04-16snow: Get rid of the oprom loaded GPIO.Gabe Black
ARM doesn't use option ROMs, so this value doesn't make sense. Change-Id: I1a0f0854e1dd4b9594ca0c147e590337520436da Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3094 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-04-16snow: Tidy up chromeos.c.Gabe Black
Got rid of a lot of #defines, some of which were converted to enums and the rest which were eliminated entirely. Got rid of cruft in get_developer_mode_switch and started using it for the dev mode GPIO. Instead of a macro defining how many GPIOs are expected, now the code actually counts the GPIOs as they're added. Change-Id: I97b6b9f52a72d1276eb3cf36d7f9dd7b335b4d19 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3093 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-04-16snow: Add support for EC based recovery.Gabe Black
Implement the get_recovery_mode_switch function using the newly added I2C based Chrome EC support. Change-Id: I9d0200629887f202edf017cba3222a7d7f5b053e Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3092 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-04-16snow: Fix some comments in chromeos.c.Gabe Black
The comment about the lid switch was left over from when this file was copied from another board and was incorrect. Also fixed a capitalization inconsistency. Change-Id: Icefd19047971e13c08f615578e4a181e82a2997f Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3091 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-04-16Lenovo ThinkPad X60: Add Native VGA init.Denis 'GNUtoo' Carikli
The code has been taken from the google link mainboard and modified to fit the ThinkPad X60. Change-Id: Ie16e45163acdc651ea46699ecc33055bfd34099c Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/2998 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-16documentation: Complete the AMD-S3.txtZheng Bao
Fix some typos and finish empty sections. Change-Id: I08cc971e763252b035ab8ed2118180140e34ac72 Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/2483 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-04-16ec/google: Move plug-n-play initialization to LPC protocol.Hung-Te Lin
"Plug-n-play" is not supported on all platforms using Google's Chrome EC. For example, EC on I2C bus will need explicit configuration and initialization. So move the plug-n-play initialization to the LPC implementation. Verified by building Google/Link (with EC/LPC) successfully. Change-Id: I49e5943503fd5301aa2b2f8c1265f3813719d7e3 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3089 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-04-16ec/google: Support Google's Chrome EC on I2C interface.Hung-Te Lin
Google's Chrome EC can be installed on LPC or I2C bus, using different command protocol. This commit adds I2C support for devices like Google/Snow. Note: I2C interface cannot be automatically probed so the bus and chip number must be explicitly set. Verified by booting Google/Snow, with following console output: Google Chrome EC: Hello got back 11223344 status (0) Google Chrome EC: version: ro: snow_v1.3.108-30f8374 rw: snow_v1.3.128-e35f60e running image: 1 Change-Id: I8023eb96cf477755d277fd7991bdb7d9392f10f7 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3074 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-16AMD AGESA: Fix argument list for `PCIE_DDI_DATA_INITIALIZER` in commentsPaul Menzel
When looking into possible reasons for a proposed revert [1], I noticed that the comments use four arguments for `PCIE_DDI_DATA_INITIALIZER`, but the actual definition only uses three. $ git grep -A1 PCIE_DDI_DATA_INITIALIZER # manually squeeze whitespace in output […] -- src/vendorcode/amd/agesa/f10/AGESA.h:#define PCIE_DDI_DATA_INITIALIZER(mConnectorType, mAuxIndex, mHpdIndex ) \ src/vendorcode/amd/agesa/f10/AGESA.h-{mConnectorType, mAuxIndex, mHpdIndex} -- src/vendorcode/amd/agesa/f10/AGESA.h: * PCIE_DDI_DATA_INITIALIZER (ConnectorType src/vendorcode/amd/agesa/f10/AGESA.h- * }, -- src/vendorcode/amd/agesa/f10/AGESA.h: * PCIE_DDI_DATA_INITIALIZER (ConnectorType src/vendorcode/amd/agesa/f10/AGESA.h- * } -- […] So remove the fourth argument in the comments. Luckily the compiler, at least gcc, warns about a wrong number of arguments, and therefore no incorrect code resulted from the wrong documentation. [1] http://review.coreboot.org/#/c/3077/ Change-Id: I3e5a02c66a23af1eb2d86be8dbc7aaa3e5cea05e Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3080 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-15Fam14 DSDT: Also return for unrecognized UUID in _OSCMike Loptien
Fixing warnings introduced by the following patches: http://review.coreboot.org/#/c/2684/ http://review.coreboot.org/#/c/2739/ http://review.coreboot.org/#/c/2714/ These patches were meant to fix the dmesg warning about the OSC method not granting control appropriately. These patches then introduced warnings during the coreboot build process which were missed during the patch submission process. These warnings are below: Intel ACPI Component Architecture ASL Optimizing Compiler version 20100528 [Oct 15 2010] Copyright (c) 2000 - 2010 Intel Corporation Supports ACPI Specification Revision 4.0a dsdt.ramstage.asl 1143: Method(_OSC,4) Warning 1088 - ^ Not all control paths return a value (_OSC) dsdt.ramstage.asl 1143: Method(_OSC,4) Warning 1081 - ^ Reserved method must return a value (Buffer required for _OSC) ASL Input: dsdt.ramstage.asl - 1724 lines, 34917 bytes, 889 keywords AML Output: dsdt.ramstage.aml - 10470 bytes, 409 named objects, 480 executable opcodes Compilation complete. 0 Errors, 2 Warnings, 0 Remarks, 494 Optimizations This patch gives the following compilation status: Intel ACPI Component Architecture ASL Optimizing Compiler version 20100528 [Oct 1 2012] Copyright (c) 2000 - 2010 Intel Corporation Supports ACPI Specification Revision 4.0a ASL Input: dsdt.ramstage.asl - 1732 lines, 33295 bytes, 941 keywords AML Output: dsdt.ramstage.aml - 10152 bytes, 406 named objects, 535 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 432 Optimizations The fix is simply adding an Else statement to the If which checks for the proper UUID. This way, all outcomes will return a full control package. This patch has no effect on the dmesg output. Change-Id: I8fa246400310b26679ffa3aa278069d2e9507160 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/3052 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-15inteltool: pcie.c: Use `0xffULL` instead of `0xff` to avoid shift overflowPaul Menzel
When building inteltool with Clang, it warns about the following. $ clang --version Debian clang version 3.2-1~exp6 (tags/RELEASE_32/final) (based on LLVM 3.2) Target: i386-pc-linux-gnu Thread model: posix $ CC=clang make […] clang -O2 -g -Wall -W -c -o pcie.o pcie.c pcie.c:297:40: warning: signed shift result (0xFF0000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] pciexbar_phys = pciexbar_reg & (0xff << 28); ~~~~ ^ ~~ pcie.c:301:41: warning: signed shift result (0xFF8000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] pciexbar_phys = pciexbar_reg & (0x1ff << 27); ~~~~~ ^ ~~ pcie.c:305:41: warning: signed shift result (0xFFC000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] pciexbar_phys = pciexbar_reg & (0x3ff << 26); ~~~~~ ^ ~~ 3 warnings generated. […] Specifying the length by using the suffix `0xffULL` fixes these issues as now enough bits are available. These issues were introduced in commit 1162f25a [1]. commit 1162f25a49e8f39822123d664cda10fef466b351 Author: Stefan Reinauer <stepan@coresystems.de> Date: Thu Dec 4 15:18:20 2008 +0000 Patch to util/inteltool: * PMBASE dumping now knows the registers. * Add support for i965, i975, ICH8M * Add support for Darwin OS using DirectIO [1] http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=1162f25a49e8f39822123d664cda10fef466b351 Change-Id: I7b9a15b04ef3bcae64e06266667597d0f9f07b79 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3015 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.huber@secunet.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-15Drop add_mainboard_resources and HAVE_MAINBOARD_RESOURCES againKyösti Mälkki
These are not defined since commit »Drop HAVE_MAINBOARD_RESOURCES« (1c5071d1) [1] but were unfortunately introduced again in new ports. [1] http://review.coreboot.org/1414 Change-Id: I5eb61628141aefd08779615702d51ca155fa632a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2707 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-04-15cbmem: Makefile: Allow to override `CC` variablePaul Menzel
Now users can use a different compiler from GCC like Clang by for example doing `CC=clang make`. Change-Id: I664a36df79f7496a56d89bdb61948b2eda33a6b4 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3082 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-14inteltool: Use portable type `uint64_t` instead of `u64`Paul Menzel
In [1] Idwer Vollering noted, that the type `u64` is not portable so on his FreeBSD system, the following warning is shown. $ clang -O2 -Wall -W -I/usr/local/include -c -o amb.o amb.c amb.c:441:22: error: use of undeclared identifier 'u64' ambconfig_phys = ((u64)pci_read_long(dev16, 0x4c) << 32) | The type `uint64_t` seems to be defined also on FreeBSD, so using this fixes the warning. Note, this warning is not reproducable with Debian Sid/unstable for example. I have no idea why though. [1] http://review.coreboot.org/#/c/3015/ Change-Id: Ic22f4371114b68ae8221d84a01fef6888d43f365 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3086 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-14AMD CIMx sb800/SATA.c, sb900/Sata.c: Fix R*AI*D typo in commentsPaul Menzel
Spell RAID correctly in comments. Found with the following command. $ git grep -i riad Change-Id: I68e8476d885a88df589d25f88cc158d71eb04e07 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3081 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-14cbmem: parse_cbtable: Use length modifier `ll` `u64` argumentPaul Menzel
Currently on a 32-bit system cbmem fails to build due to `-Werror` and the following warning. $ make cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c […] cbmem.c: In function ‘parse_cbtable’: cbmem.c:135:2: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘u64’ [-Werror=format] cc1: all warnings being treated as errors […] Using the length modifier `ll` instead of `l` gets rid of this warning. Change-Id: Ib2656e27594c7aaa687aa84bf07042933f840e46 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3084 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-14link/graphics: Remove the inclusion of an AMD header.Denis 'GNUtoo' Carikli
link(google chromebook pixel) is an intel machine. Change-Id: I9d40f1e945021d8e190879477cd12be7d0262733 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3085 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-13exynos5/snow: remove wait_ms arg from dp_controller_init()David Hendricks
This removes the wait_ms argument from the dp_controller_init(). The only delay involved is a constant 60ms delay that happens if everything else goes well. This delay is derived from the LCD spec so there's no reason it should be baked into the controller code. (This patch also has the side-effect of fixing a bug where we were delaying on an undefined value for wait_ms). Change-Id: I03aa19f2ac2f720524fcb7c795e10cc57f0a226e Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3078 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-13Exynos5250: add a microsecond timerRonald G. Minnich
Add a microsecond timer, its declaration, the function to start it, and its usage. To start it, one calls timer_start(). From that point on, one can call timer_us() to find microseconds since the timer was started. We show its use in the bootblock. You want it started very early. Finally, the delay.h change having been (ironically) delayed, we create time.h and have it hold one declaration, for the timer_us() and timer_start() prototype. We feel that these two functions should become the hardware specific functions, allowing us to finally move udelay() into src/lib where it belongs. Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3073 Tested-by: build bot (Jenkins)
2013-04-12cbfstool: cbfs-mkstage.c: Free `buffer` on error pathPaul Menzel
Cppcheck warns about a memory leak, present since adding romtool, which was renamed to cbfstool, in commit 5d01ec0f. $ cppcheck --version Cppcheck 1.59 […] [cbfs-mkstage.c:170]: (error) Memory leak: buffer […] Indeed the memory pointed to by `buffer` is not freed on the error path, so add `free(buffer)` to fix this. Change-Id: I6cbf82479027747c800c5fe847f20b779e261ef4 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3069 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-04-12acpica: update URLIdwer Vollering
The URL to acpica-unix-20121114 has changed, update the URL. Change-Id: I1c8c228094f19455af3682f36f1990586fe3934c Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: http://review.coreboot.org/3070 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-04-12Revert "siemens/sitemp_g1p1: Make ACPI report the right mmconf region"Nico Huber
This reverts commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5: commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5 Author: Patrick Georgi <patrick.georgi@secunet.com> Date: Tue Apr 9 15:41:23 2013 +0200 siemens/sitemp_g1p1: Make ACPI report the right mmconf region ACPI reported the entire space between top-of-memory and some (relatively) arbitrary limit as useful for MMIO. Unfortunately the HyperTransport configuration disagreed. Make them match up. Other boards are not affected since they don't report any region for that purpose at all (it seems). Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3047 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> It sneaked in without it's dependencies and, therefore, broke the build for all amdk8 targets. Paul Menzel already commented on the issue in [1]. It also doesn't look like the dependencies would be pulled soon [2]. [1] http://review.coreboot.org/#/c/3047/ [2] http://review.coreboot.org/#/c/2662/ Change-Id: Ica89563aae4af3f0f35cacfe37fb608782329523 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/3063 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-04-12AMD Thatcher: Fix PCIE link issuesSiyuan Wang
1). Thatcher PCIE x8 slot is reverse order. Although the PCIE slot is x16, it actually uses 8 lanes(15:8). Because the PCIE slot is configured by PortList[0], fix this item can enable the slot. A x1 PCIE network adapter works well in this slot. 2). Fix DdiList to detect DP monitor or HDMI monitor. GPIO50 can be used to detect DP0/HDMI0 monitor. If GPIO50 is 1, it is DP monitor. If GPIO50 is 0, it is HDMI monitor. GPIO51 can be used to detect DP1/HDMI1 in the same way. 3). Disable unused PCIE port and clean up code in PlatformGnbPcie.c and devicetree.cb. PCIE port 3 and 7 are not used in Thatcher. Change-Id: I8524b6fc1b6cdc03ba92e7191186bfb0986767c8 Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/3011 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-04-12ec/google: Isolate EC bus protocol implementation.Hung-Te Lin
The Chrome EC can be connected by different types of bus like LPC / I2C / SPI, and the current implementation is only for LPC. To support other types, we must first isolate the LPC protocol stuff and add configuration variable (EC_GOOGLE_CHROMEEC_LPC) to specify bus type. Verified by building google/link (with chromeec) configuration successfully. Change-Id: Ib2920d8d935bcc77a5394e818f69e9265e26e8a0 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3068 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-04-12Add new superio deviceSteven Sherk
- Added in new support for Nuvoton NCT5104D LPC device. Change-Id: I0af8c5e3e46fdd0a549475b30917897ae9e144a7 Signed-off-by: Steven Sherk <steven.sherk@se-eng.com> Reviewed-on: http://review.coreboot.org/3072 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-11AMD RS780, SR5650: PcieTrainPort: Fix typo *i*gnoring in commentPaul Menzel
Reading the paste of code in a message to the mailing list [1], a typo was spotted and found in one more place. $ git grep egnoring src/southbridge/amd/rs780/cmn.c: * egnoring the reversal case src/southbridge/amd/sr5650/sr5650.c: * egnoring the reversal case These typos are there since when the code was committed and are now corrected. [1] http://www.coreboot.org/pipermail/coreboot/2013-April/075644.html Change-Id: I55c65f71e4834f209b60d678f0d44bc2f4217099 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3062 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-04-11Persimmon/Fam14/SB800 DSDT: Split into common areasMike Loptien
Split the Persimmon DSDT into common code areas. For example, split the Southbridge specific code into the Southbridge directory and CPU specific code into the CPU directory. Also adding the superio.asl file to the Persimmon DSDT tree. This file is empty for the moment but will be necessary in the future. I have also emptied the thermal.asl file in the mainboard directory because it does not seem to perform as intended (fan control does not change when it is brought back into the code base) and it has been inside a '#if 0' statement for a long time. Removing it until it is decided that it is actually necessary. This change was verified in three different ways: 1. Visual comparison of the compiled DSDT pulled from the Persimmon after booting into Linux using the ACPI tools acpidump, acpixtract, and iasl. The comparison was done between the DSDT before and after doing the split work. This test is somewhat difficult considering the expanse of the changes. Blocks of code have been moved, and others changed. 2. Linux logs were dumped before and after the DSDT split. Logs dumped and compared include dmesg and lspci -tv. Neither log changed significantly between the two compare points. 3. The test suite FWTS was run on the Coreboot build both before and after doing the DSDT split with the command 'sudo fwts -b -P -u'. The flag -b specifies all batch jobs, -P specifies all power tests, and -u specifies utilities. Interactive jobs were not run as most of them consist of laptop checks. Again, there were no significant changes between the two endpoints. These tests lead me to believe that there was no change in the functionality of the ACPI tables apart from what is known and expected. This patch is the first of a series of patches to split the DSDT. The ASRock patch was merged before this one and breaks the ASROCK E350M1 build (patch 8d80a3fb: http://review.coreboot.org/#/c/3050/). Please be aware of this dependency when pulling these patches. Other patches that depend on this patch are 'AMD Fam14: Split out the AMD Fam14 DSDT' (http://review.coreboot.org/#/c/3051/) and 'Fam14 DSDT: Also return for unrecognized UUID in _OSC' (http://review.coreboot.org/#/c/3052/) Change-Id: I53ff59909cceb30a08e8eab3d59b30b97c802726 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/3048 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-04-11libpayload: storage.c: Fix typo in st*orage in commentPaul Menzel
Reading commit »libpayload: New AHCI, ATA and ATAPI drivers« (1f6bd94f) [1], the spelling error was found and is now fixed. [1] http://review.coreboot.org/1622 Change-Id: Id418bcb99c1a9a400a49fc04078e465bd0908074 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3071 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-11Snow: Set up the ChromeOS GPIOs as inputs during the ROM stage.Gabe Black
We need these to be inputs so they can be read when populating the coreboot tables. It seems like a good idea to do this early to ensure that the input gate capacitance has had a chance to charge, and if we decide to use actually use that information during the ROM stage to do earlier RW firmware selection. It is not guarded by a ChromeOS config variable because those lines are always intended to be input GPIOs, regardless of whether we're running ChromeOS or not. Change-Id: Id76008931b5081253737c6676980a1bdb476ac09 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3067 Tested-by: build bot (Jenkins)
2013-04-11Snow: Fix the recovery GPIO polarity, and lid GPIO polarity and number.Gabe Black
Change-Id: I34097f878291367b28962048190e11ccaacfc514 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3066 Tested-by: build bot (Jenkins)
2013-04-11ARM: Unmask aborts very early in the bootblock.Gabe Black
It's better to recognize aborts when they occur than to mask them to discover them later without knowing where they actually came from. Change-Id: Ic8f5321415f411afac94b5ef9dd440790df6d82c Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3065 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-04-11ASRock DSDT: Split the ASRock DSDTMike Loptien
This is the same split as was done on the Persimmon. Change-Id: I25bd63f23417b7926232f07eaaa7917170af9d60 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/3050 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-11Exynos5250: Use new chip settings for the cpuRonald G. Minnich
Properly use the chip settings when configuring the CPU, at this point being purely graphics. Change-Id: I9bc2d32c1037653837937b314e4041abc0024835 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3054 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-04-10siemens/sitemp_g1p1: Make ACPI report the right mmconf regionPatrick Georgi
ACPI reported the entire space between top-of-memory and some (relatively) arbitrary limit as useful for MMIO. Unfortunately the HyperTransport configuration disagreed. Make them match up. Other boards are not affected since they don't report any region for that purpose at all (it seems). Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3047 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-10GOOGLE/SNOW: add edp support to ramstageRonald G. Minnich
Add basic edp support to the ramstage. Not working. Change-Id: I15086e03417edca7426c214e67b51719d8ed9341 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3055 Tested-by: build bot (Jenkins)
2013-04-10[2/2] tps65090: re-factor for corebootDavid Hendricks
This does basic re-factoring to fit the driver into coreboot. Change-Id: Id5f8c12a73ec37ddd545d50b3e8e9b3012657db1 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3061 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-10[1/2] initial import of TI TPS65090David Hendricks
This imports TPS65090 PMIC from u-boot and adds/updates Makefiles and Kconfig files. The follow-up patch will re-factor the code. Change-Id: Ic9e43b9665ddf7f55feae8fa17fbf3d2d5f4756d Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3060 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-10GOOGLE/SNOW: clean up the device treeRonald G. Minnich
This is a simpler device tree that is also more correct, and has graphics settings as well. Change-Id: I342d8be7dddb76e6992876c73f5c625c926977d3 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3053 Tested-by: build bot (Jenkins)
2013-04-10exynos5-common: Enable fimd_bypass and minor cleanupRonald G. Minnich
Basic cleanup, this code still does not work. Change-Id: I84ed9f08fd04cd8eb74cd860e0775d8c602f42d6 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3049 Tested-by: build bot (Jenkins)
2013-04-10armv7: replace read/write macros with inlinesDavid Hendricks
This enables type checking for safety as to help prevent errors like http://review.coreboot.org/#/c/3038/ . Now compilation fails if the wrong type is passed into readb/readw/readl/writeb/writew/writel or other macros in io.h. This also deprecates readw/writew. The previous definition was 16-bits which is incorrect since wordsize on ARMv7 is 32-bits and there was only 1 instance of writew (#if 0'd anyway). Going forward we should always use read{8,16,32} and write{8,16,32} where N specifies the exact length rather than relying on ambiguous definition of wordsize. Since many macros relied on __raw_*, which were basically the same (minus data memory barrier instructions), this patch also gets rid of __raw_*. There were parts of the code which ended up using these macros consecutively, for example: setbits_le32(&regs->ch_cfg, SPI_CH_RST); clrbits_le32(&regs->ch_cfg, SPI_CH_RST); In such cases the safe versions of readl() and writel() should be used anyway. Note: This also fixes two dubious casts as to avoid breaking compilation. Change-Id: I8850933f68ea3a9b615d00ebd422f7c242268f1c Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3045 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-10exynos5: Re-factor I2C codeDavid Hendricks
This re-factors the Exynos5 I2C code to be simpler and use the new API, and updates users accordingly. - i2c_read() and i2c_write() functions updated to take bus number as an argument. - Get rid of the EEPROM_ADDR_OVERFLOW stuff in i2c_read() and i2c_write(). If a chip needs special handling we should take care of it elsewhere, not in every low-level i2c driver. - All the confusing bus config functions eliminated. No more i2c_set_early_config() or i2c_set_bus() or i2c_get_bus(). All this is handled automatically when the caller does a transaction and specifies the desired bus number. - i2c_probe() eliminated. We're not a command-line utility. - Let the compiler place static variables automatically. We don't need any of this fancy manual data placement. - Remove dead code while we're at it. This stuff was ported early on and much of it was left commented out in case we needed it. Some also includes nested macros which caused gcc to complain. - Clean up #includes (no more common.h, woohoo!), replace debug() with printk(). Change-Id: I8e1f974ea4c6c7db9f33b77bbc4fb16008ed0d2a Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3044 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-09replace device/i2c.h with simpler versionDavid Hendricks
The existing header was imported along with the Exynos code and left mostly unchanged. This is the first patch in a series intended to replace the imported u-boot I2C API with a much simpler and cleaner interface: - We only need to expose i2c_read() and i2c_write() in our public API. Everything else is board/chip-dependent and should remain hidden away. - i2c_read and i2c_write functions will take bus number as an arg and we'll eliminate i2c_get_bus and i2c_set_bus. Those are prone to error and end up cluttering the code since the user needs to save the old bus number, set the new one, do the read/write, and restore the old value (3 added steps to do a simple transaction). - Stop setting default values for board-specific things like SPD and RTC bus numbers (as if we always have an SPD or RTC on I2C). - Death to all the trivial inline wrappers. And in case there was any doubt, we really don't care about the MPC8xx. Though if we did then we would not pollute the public API with its idiosyncrasies. Change-Id: I4410a3c82ed5a6b2e80e3d8c0163464a9ca7c3b0 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3043 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-09FrontRunner/Toucan-AF: boards will be renamed to fit ADLINK schemeJens Rottmann
Originally developed by LiPPERT and after the acquisition marketed as 'LiPPERT by ADLINK', the plan is now to streamline both boards into the ADLINK naming scheme. But AFAIK a few have already been sold and as of this writing the website still advertises the old names. And in any case the veteran LX products will continue to be sold by ADLINK under their original names. So create CONFIG_VENDOR_ADLINK, currently only telling users to look under LiPPERT (however any future boards will be added here). Further add an explanation to CONFIG_VENDOR_LIPPERT, and in the Mainboard model selection show both names. Change-Id: Iaafa88533ef4cce33243293c3d55754e7e93d003 Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-on: http://review.coreboot.org/3046 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-09util/cbmem: Don't output trailing garbage for cbmemcVladimir Serbinenko
Current code outputs the whole cbmemc buffer even if only part of it is really used. Fix it to output only the used part and notify the user if the buffer was too small for the required data. Change-Id: I68c1970cf84d49b2d7d6007dae0679d7a7a0cb99 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/2991 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08cbfstool: completely initialize input and output streamsStefan Reinauer
The LZMA glue code in cbfstool was recently rewritten from C++ to plain C code in: commit aa3f7ba36ebe3a933aa664f826382f60b31e86f1 Author: Stefan Reinauer <reinauer@chromium.org> Date: Thu Mar 28 16:51:45 2013 -0700 cbfstool: Replace C++ code with C code Reviewed-on: http://review.coreboot.org/3010 In the progress of doing so, the stream position for the input stream and output stream was not reset properly. This would cause LZMA producing corrupt data when running the compression function multiple times. Change-Id: I096e08f263aaa1931517885be4610bbd1de8331e Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3040 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-08libpayload: Handle multifunction bridge devices better.Gabe Black
This change modifies the code in libpayload that scans the PCI hierarchy for USB controllers. Previously, if a devices primary function (function 0) was a bridge, then none of the other functions, if any, would be looked at. If one of the other functions was a bridge, that wouldn't be handled either. The new version looks at each function that's present no matter what, and if it discovers that it's a bridge it scans the other side. Change-Id: I37f269a4fe505fd32d9594e2daf17ddd78609c15 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2517 Reviewed-by: Marc Jones <marc.jones@se-eng.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-04-08armv7: specify condition code for msr instructionDavid Hendricks
This adds condition codes when using the msr instruction. Although described as "optional" in the Cortex-A series programmer's guide, our experience with using the msr instruction in the payload suggests that the condition code is not optional and that this only worked in coreboot (and u-boot) because the processor comes up in SVC32 mode. (credit to Gabe Black for finding this, I'm only uploading the patch) Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I0aa4715ae415e1ccc5719b7b55adcd527cc1597b Reviewed-on: http://review.coreboot.org/3037 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08exynos5250: add missing address-of operator in UART driverDavid Hendricks
This adds a missing address-of operator. This was a subtle bug that didn't seem to cause problems at first since the serial console appeared to work. However it caused an imprecise external abort which became apparent later on when aborts were unmasked in the kernel via the CPSR_A bit. (credit goes to Gabe Black for finding this) Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I80a33b147d92d559fa8fefbe7d5642235deb9aea Reviewed-on: http://review.coreboot.org/3038 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08inteltool: remove unused file descriptor variable and ifdefsStefan Tauner
Change-Id: I6a119b1f362f481914377e8d14c713159f895130 Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at> Reviewed-on: http://review.coreboot.org/3030 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-22 16:16:39 +0000