summaryrefslogtreecommitdiff
path: root/src/include
AgeCommit message (Collapse)Author
2015-04-22lib: add base64 decoderVadim Bendebury
It became necessary to decode base64 data retrieved from VPD and convert it into binary for inclusion in the device tree. The patch introduces the decoder function based on the description found in http://en.wikipedia.org/wiki/Base64. An open source implementation from http://base64.sourceforge.net was considered, in the end the only thing borrowed from it is the table to translate base64 ascii characters into numbers in 0..63 range. BRANCH=none BUG=chromium:450169 TEST=created a test harness generating random contents of random size (in 8 to 32766 bytes range), then converting the contents into base64 using the Linux utility, and then converting it back to binary using this function and comparing the results. It succeeded 1700 iterations before it was stopped. Change-Id: I502f2c9494c99ba95ece37a7220c0c70c4755be2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6609f76e1559d3cdd402276055c99e0de7da27c8 Original-Change-Id: I5ed68af3a4daead50c44ae0f0c63d836f4b66851 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/262945 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9892 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22google/urara: use board ID information to set up hardwareIonela Voinescu
The hardware initialization is now split in basic initialization (MIPS and system PLL, system clock, SPIM, UART), and initialization of other hardware blocks (USB, I2C, ETH). The second part uses board ID information to select setup that is board specific (currently only I2C interface is selected through board ID). BRANCH=none BUG=chrome-os-partner:37593 TEST=tested on bring up board for both Urara and Concerto; to simulate the use of Concerto (I2C3) DIP SW17 was set to 0. it works with default settings on Urara Change-Id: Ic5bbf28ab42545a4fb2aa6fd30592a02ecc15cb5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f2b3db2e7f9fa898214f974ca34ea427196d2e4e Original-Change-Id: Iac9a082ad84444af1d9d9785a2d0cc3205140d15 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/257401 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9888 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22vpd: populate coreboot table with serialnoStephen Barber
BRANCH=none BUG=chrome-os-partner:37813 TEST=devicetree is populated with with "compatible", "hardware", and "serialno" properties Change-Id: Ibe84aa05702d2a33456c6c33d15a4c7d4a6d45d7 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 61408d969f5d6e1e40f919b3defd5f1622391c9e Original-Change-Id: I02f360f4e5385042f56eb2b2f29072e393a24fc9 Original-Signed-off-by: Stephen Barber <smbarber@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/259141 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9882 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22vboot: when configured, pass the wipeout request to vbootVadim Bendebury
It has become necessary to be able to "factory reset" certain devices on firmware request. The vboot package has been modified to provide the necessary API, this patch introduces a configuration option and uses the API when enabled. CQ-DEPEND=CL:259857 BRANCH=storm BUG=chrome-os-partner:37219 TEST=with all the patches applied, on storm, holding the recovery button at startup for 10 seconds, causes 'crossystem wipeout_request' to report '1'. Change-Id: I5e57bc05af3753f451626021ba30c7726badb7b4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f70e03e9a8c55bf3c45b075ae4fecfd25da4f446 Original-Change-Id: I4c2192da4fabfdef34d527e5b80d137634eb6987 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/259843 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9862 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21Unify byte order macros and clrsetbitsJulius Werner
This patch removes quite a bit of code duplication between cpu_to_le32() and clrsetbits_le32() style macros on the different architectures. This also syncs those macros back up to the new write32(a, v) style IO accessor macros that are now used on ARM and ARM64. CQ-DEPEND=CL:254862 BRANCH=none BUG=chromium:444723 TEST=Compiled Cosmos, Daisy, Blaze, Falco, Pinky, Pit, Rambi, Ryu, Storm and Urara. Booted on Jerry. Tried to compare binary images... unfortunately something about the new macro notation makes the compiler evaluate it more efficiently (not recalculating the address between the read and the write), so this was of limited value. Change-Id: If8ab62912c952d68a67a0f71e82b038732cd1317 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: fd43bf446581bfb84bec4f2ebb56b5de95971c3b Original-Change-Id: I7d301b5bb5ac0db7f5ff39e3adc2b28a1f402a72 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254866 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9838 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21romstage_handoff: Fix for changing CBMEM structureDuncan Laurie
Adding a new field to a CBMEM structure does not work if there are systems with older RO that do not have this new field as it means romstage did not prepare the field and ramstage is using it uninitialized. To deal with this instead of adding a new field split the existing s3_resume variable into bytes, using the first byte for the existing s3_resume variable (which is always just 0 or 1) and the second byte for the new varible, which will always be 0 for the old RO and can be set by new RO. BUG=chrome-os-partner:37108 BRANCH=samus TEST=manual testing on samus: 1) ensure that if vboot requests reboot after TPM setup that it still works and the reboot happens after reference code execution. 2) ensure that if RO is older without this change that it does not cause a continuous reboot if newer ramstage is added 3) test that suspend resume still works as expected Reviewed-on: https://chromium-review.googlesource.com/253550 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org> (cherry picked from commit 1ccb7ee5fc6980ca0f26fa52b385d2cc52f396c9) Change-Id: I6e206b4a3b33b8a31d102d64bd37d34657cf49ac Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: fe85678ee788ff939bc8c084829a1b04232c4c6c Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Change-Id: If69d0ff9cc3bf596eee8c3a8d6e04951820a26fe Original-Reviewed-on: https://chromium-review.googlesource.com/256114 Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/9833 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21Arrange CBMEM table entries' IDs alphanumericallyVadim Bendebury
This is a no-op change just sorting the CBMEM entries' definitions for easy look up and comparison. BRANCH=storm BUG=none TEST=Booted a storm device, observed the expected CBMEM entries present in the console output. Change-Id: I26365285f20ecb256918277b60e178cd61dc8213 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f140fd8d85ded30d1b89f5d4c64f8b9f31d6b27b Original-Change-Id: Ibcd4f184ef1bade10ad677384f61243da7e3c713 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/225259 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9810 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-20chromeos: vboot2: Add TPM PCR extension supportJulius Werner
ChromeOS/vboot devices expect the TPM PCRs 0 and 1 to be extended with digests that attest the chosen boot mode (developer/recovery) and the HWID in a secure way. This patch uses the newly added vboot2 support functions to fetch these digests and store them in the TPM. CQ-DEPEND=CL:244542 BRANCH=veyron BUG=chromium:451609 TEST=Booted Jerry. Confirmed that PCR0 contains the same value as on my vboot1 Blaze and Falco (and PCR1 contains some non-zero hash). Original-Change-Id: I7037b8198c09fccee5440c4c85f0821166784cec Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/245119 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit 8b44e13098cb7493091f2ce6c4ab423f2cbf0177) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I549de8c07353683633fbf73e4ee62ba0ed72ff89 Reviewed-on: http://review.coreboot.org/9706 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-17Fix non-x86 __PRE_RAM__ assertions and add FATAL_ASSERTS Kconfig optionJulius Werner
This patch fixes a bug that caused non-x86 boards to use the poor man's assert() version with a lot more instructions per invocation and hexadecimal line numbers in __PRE_RAM__ environments. This was really just an oversight in the ARM port... even x86 uses a proper printk() in most cases (those with CAR) and there's no reason not to do so on the generally even more flexible SRAM-based architectures. Additionally, it adds a new Kconfig option to make failed assertions and BUG() calls halt again. This seems to have been the original intention, but was commented out once out of fear that this might prevent production systems from booting. It is still a useful debugging feature though (since otherwise assertions can easily just scroll past and get overlooked), so the user should be able to decide the this based on his needs. (Also changed error messages for both to include the word "ERROR", since grepping for that is the most sophisticated way we currently have to detect firmware problems. Some automated Chromium OS suspend tests check for that.) BRANCH=veyron BUG=None TEST=Booted Jerry. Compared binary sizes before and after, new version's bootblock is some ~600 bytes smaller. Change-Id: I894da18d77e12bf104e443322e2d58e60564e4b7 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6a5343124719c18a1c969477e3d18bda13c0bf26 Original-Change-Id: I0268cfd67d8c894406b18bb3759a577944bcffb1 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/250661 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9775 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-17cbfs: look for CBFS header in a predefined placeVadim Bendebury
This patch introduces a new option (CONFIG_MULTIPLE_CBFS_INSTANCES) to allow multiple CBFS instances in the bootrom. When the new option is enabled, the code running on the target controls which CBFS instance is used. Since all other then header CBFS structures use relative addressing, the only value which needs explicit setting is the offset of the CBFS header in the bootrom. This patch adds a facility to set the CBFS header offset. The offset value of zero means default. i.e. the CBFS initialization code still discovers the offset through the value saved at the top of the ROM. BRANCH=storm BUG=chrome-os-partner:34161, chromium:445938 TEST=with the rest patches in, storm target successfully boots from RW section A. Change-Id: Id8333c9373e61597f0c653c727dcee4ef6a58cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e57a3a15bba7cdcca4a5d684ed78f8ac6dbbc95e Original-Change-Id: I4c026389ec4fbaa19bd11b2160202282d2f9283c Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237569 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9747 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-17uart: pass register width in the coreboot tableVadim Bendebury
Some SOCs (like pistachio, for instance) provide an 8250 compatible UART, which has the same register layout, but mapped to a bus of a different width. Instead of adding a new driver for these controllers, it is better to have coreboot report UART register width to libpayload, and have it adjust the offsets accordingly when accessing the UART. BRANCH=none BUG=chrome-os-partner:31438 TEST=with the rest of the patches integrated depthcharge console messages show up when running on the FPGA board Change-Id: I30b742146069450941164afb04641b967a214d6d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2c30845f269ec6ae1d53ddc5cda0b4320008fa42 Original-Change-Id: Ia0a37cd5f24a1ee4d0334f8a7e3da5df0069cec4 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240027 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9738 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-17exynos: return correct value when init_default_cbfs_media failsDaisuke Nojiri
BUG=none BRANCH=ToT TEST=Built daisy. Change-Id: I64033f8e7beb247b2b8bd66e58de6c5e263ee634 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1ff51e887a07a0f2426e5111df683ce2a9d4097d Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Id6e006be1db08933dc97b5e797a85f3cbf9f6486 Original-Reviewed-on: https://chromium-review.googlesource.com/232513 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9735 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17rk3288: Handle framebuffer through memlayout, not the resource systemJulius Werner
We've traditionally tucked the framebuffer at the end of memory (above CBMEM) on ARM and declared it reserved through coreboot's resource allocator. This causes depthcharge to mark this area as reserved in the kernel's device tree, which may be necessary to avoid display corruption on handoff but also wastes space that the OS could use instead. Since rk3288 boards now have proper display shutdown code in depthcharge, keeping the framebuffer memory reserved across the handoff (and thus throughout the lifetime of the system) should no longer be necessary. For now let's just switch the rk3288 implementation to define it through memlayout instead, which is not communicated through the coreboot tables and will get treated as normal memory by depthcharge. Note that this causes it to get wiped in developer/recovery mode, which should not be a problem because that is done in response to VbInit() (long before any images are drawn) and 0 is the default value for a corebootfb anyway (a black pixel). Eventually, we might want to think about adding more memory types to coreboot's resource system (e.g. "reserved until kernel handoff", or something specifically for the frame buffer) to model this situation better, and maybe merge it with memlayout somehow. CQ-DEPEND=CL:239470 BRANCH=veyron BUG=chrome-os-partner:34713 TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes than before (curiously not 0x80000 bytes, I guess there's some alignment waste in the kernel somewhere). Made sure the memory map output from coreboot looks as expected, there's no visible display corruption in developer/recovery mode and the 'cbmem' utility still works. Change-Id: I12b7bfc1b7525f5a08cb7c64f0ff1b174df252d4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2 Original-Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240819 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9732 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17spi: Add function to read flash status registerDuncan Laurie
Add a function that allows reading of the status register from the SPI chip. This can be used to determine whether write protection is enabled on the chip. BUG=chrome-os-partner:35209 BRANCH=haswell TEST=build and boot on peppy Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/240702 Reviewed-by: Shawn N <shawnn@chromium.org> (cherry picked from commit c58f17689162b291a7cdb57649a237de21b73545) Change-Id: Ib7fead2cc4ea4339ece322dd18403362c9c79c7d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9fbdf0d72892eef4a742a418a347ecf650c01ea5 Original-Change-Id: I2541b22c51e43f7b7542ee0f48618cf411976a98 Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/241128 Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/9730 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17drivers/spi: Pass flash parameters from coreboot to payloadDan Ehrenberg
A payload may want to run erase operations on SPI NOR flash without re-probing the device to get its properties. This patch passes up three properties of flash to achieve that: - The size of the flash device - The sector size, i.e., the granularity of erase - The command used for erase The patch sends the parameters through coreboot and then libpayload. The patch also includes a minor refactoring of the flash erase code. Parameters are sent up for just one flash device. If multiple SPI flash devices are probed, the second one will "win" and its parameters will be sent up to the payload. TEST=Observed parameters to be passed up to depthcharge through libpayload and be used to correctly initialize flash and do an erase. TEST=Winbond and Gigadevices spi flash drivers compile with the changes; others don't, for seemingly unrelated reasons. BRANCH=none BUG=chromium:446377 Change-Id: Ib8be86494b5a3d1cfe1d23d3492e3b5cba5f99c6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 988c8c68bbfcdfa69d497ea5f806567bc80f8126 Original-Change-Id: Ie2b3a7f5b6e016d212f4f9bac3fabd80daf2ce72 Original-Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/239570 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9726 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14Add console wrapper for UART driverVadim Bendebury
Coreboot is designed to have a single serial console at most, on top of that it may have a CBMEM (virtual) console. Matters are complicated by the fact that console interface is different between bootblock and later stages. A linker list of console driver descriptors is used to allow to determine the set and type of console drivers at compile time. Even though the upstream seems to have done away with this approach, which does not seem the best idea. As an alternative this patch introduces a common wrapper which different UART drivers can plug in into. The driver exports a single API which can be used both directly (in bootblock) and through the wrapper (in later stages). The existing drivers can be adjusted to fit this scheme one by one. The common UART driver API also aligns fine with the upstream approach. BUG=chrome-os-partner:27784 TEST=none yet Original-Change-Id: Id1fe73d29f2a3c722bd77180beebaedb9bf7d6a1 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/196660 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 94a36ad79a96f83d283c0fd073b05f98ae48820c) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Id1fe73d29f2a3c722bd77180beebaedb9bf7d6a1 Reviewed-on: http://review.coreboot.org/7872 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14timestamps: You can never have enough of them!Julius Werner
Now that we have timestamps in pre-RAM stages, let's actually make use of them. This patch adds several timestamps to both the bootblock and especially the verstage to allow more fine-grained boot time tracking. Some of the introduced timestamps can appear more than once per boot. This doesn't seem to be a problem for both coreboot and the cbmem utility, and the context makes it clear which operation was timestamped at what point. Also simplifies cbmem's timestamp printing routine a bit, fixing a display bug when a timestamp had a section of exactly ",000," in it (e.g. 1,000,185). BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show up and contained sane values. Booted Storm (no timestamps here since it doesn't support pre-RAM timestamps yet). Change-Id: I7f4d6aba3ebe3db0d003c7bcb2954431b74961b3 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7a2ce81722aba85beefcc6c81f9908422b8da8fa Original-Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234063 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9608 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14timer: Reestablish init_timer(), consolidate timer initialization callsJulius Werner
We have known for a while that the old x86 model of calling init_timer() in ramstage doesn't make sense on other archs (and is questionable in general), and finally removed it with CL:219719. However, now timer initialization is completely buried in the platform code, and it's hard to ensure it is done in time to set up timestamps. For three out of four non-x86 SoC vendors we have brought up for now, the timers need some kind of SoC-specific initialization. This patch reintroduces init_timer() as a weak function that can be overridden by platform code. The call in ramstage is restricted to x86 (and should probably eventually be removed from there as well), and other archs should call them at the earliest reasonable point in their bootblock. (Only changing arm for now since arm64 and mips bootblocks are still in very early state and should sync up to features in arm once their requirements are better understood.) This allows us to move timestamp_init() into arch code, so that we can rely on timestamps being available at a well-defined point and initialize our base value as early as possible. (Platforms who know that their timers start at zero can still safely call timestamp_init(0) again from platform code.) BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit. Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234062 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9606 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14CBFS: Automate ROM image layout and remove hardcoded offsetsJulius Werner
Non-x86 boards currently need to hardcode the position of their CBFS master header in a Kconfig. This is very brittle because it is usually put in between the bootblock and the first CBFS entry, without any checks to guarantee that it won't overlap either of those. It is not fun to debug random failures that move and disappear with tiny alignment changes because someone decided to write "ORBC1112" over some part of your data section (in a way that is not visible in the symbolized .elf binaries, only in the final image). This patch seeks to prevent those issues and reduce the need for manual configuration by making the image layout a completely automated part of cbfstool. Since automated placement of the CBFS header means we can no longer hardcode its position into coreboot, this patch takes the existing x86 solution of placing a pointer to the header at the very end of the CBFS-managed section of the ROM and generalizes it to all architectures. This is now even possible with the read-only/read-write split in ChromeOS, since coreboot knows how large that section is from the CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be changed on systems that place other data next to coreboot/CBFS in ROM). Also adds a feature to cbfstool that makes the -B (bootblock file name) argument on image creation optional, since we have recently found valid use cases for CBFS images that are not the first boot medium of the device (instead opened by an earlier bootloader that can already interpret CBFS) and therefore don't really need a bootblock. BRANCH=None BUG=None TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco. Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229975 Reviewed-on: http://review.coreboot.org/9620 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-13spi: support controllers with limited transfer size capabilitiesVadim Bendebury
Some SPI controllers (like Imgtec Pistachio), have a hard limit on SPI read and write transactions. Limiting transfer size in the wrapper allows to provide the API user with unlimited transfer size transactions. The tranfer size limitation is added to the spi_slave structure, which is set up by the controller driver. The value of zero in this field means 'unlimited transfer size'. It will work with existion drivers, as they all either keep structures in the bss segment, or initialize them to all zeros. This patch addresses the problem for reads only, as coreboot is not expected to require to write long chunks into SPI devices. BRANCH=none BUG=chrome-os-partner:32441, chrome-os-partner:31438 TEST=set transfer size limit to artificially low value (4K) and observed proper operation on both Pistachio and ipq8086: both Storm and Urara booted through romstage and ramstage. Change-Id: Ibb96aa499c3eec458c94bf1193fbbbf5f54e1477 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 4f064fdca5b6c214e7a7f2751dc24e33cac2ea45 Original-Change-Id: I9df24f302edc872bed991ea450c0af33a1c0ff7b Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/232239 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9571 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10PCI - Add interrupt disable bit definitionLee Leahy
BRANCH=none BUG=None TEST=Build Braswell/Strago Change-Id: I11a4c02af3b40edf2252b9e20298941b99f31d21 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 1629d7454a3d4adb8930d14849c41c9a711f4c9a Original-Change-Id: Ie907637f7c823de681ef2e315e803dffc6ad33d3 Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/241081 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/9487 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10baytrail: Switch from ACPI mode to PCI mode for legacy supportMarc Jones
Most Baytrail based devices MMIO registers are reported in ACPI space and the device's PCI config space is disabled. The PCI config space is required for many "legacy" OSs that don't have the ACPI driver loading mechanism. Depthcharge signals the legacy boot path via the SMI 0xCC and the coreboot SMI handler can switch the device specific registers to re-enable PCI config space. BUG=chrome-os-partner:30836 BRANCH=None TEST=Build and boot Rambi SeaBIOS. Change-Id: I87248936e2a7e026f38c147bdf0df378e605e370 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: dbb9205ee22ffce44e965be51ae0bc62d4ca5dd4 Original-Change-Id: Ia5e54f4330eda10a01ce3de5aa4d86779d6e1bf9 Original-Signed-off-by: Marc Jones <marc.jones@se-eng.com> Original-Reviewed-on: https://chromium-review.googlesource.com/219801 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Mike Loptien <mike.loptien@se-eng.com> Original-Tested-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/9459 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10vboot: Include vb2_api.h, instead of lower-level vboot2 header filesRandall Spangler
This will allow vboot2 to continue refactoring without breaking coreboot, since there's now only a single file which needs to stay in sync. BUG=chromium:423882 BRANCH=none TEST=emerge-veyron_pinky coreboot CQ-DEPEND=CL:233050 Original-Change-Id: I74cae5f0badfb2d795eb5420354b9e6d0b4710f7 Original-Signed-off-by: Randall Spangler <rspangler@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/233051 Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit df55e0365de8da85844f7e7b057ca5d2a9694a8b) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I999af95ccf8c326f2fd2de0f7da50515e02ad904 Reviewed-on: http://review.coreboot.org/9446 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-04-10ramoops: Add support for passing ramoops region through cb tables.Furquan Shaikh
CQ-DEPEND=CL:228856 BUG=chrome-os-partner:33676 BRANCH=None TEST=ramoops buffer verified on ryu. Original-Change-Id: I29584f89ded0c22c4f255a40951a179b54761053 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/228744 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit e8b2c8b75c51160df177edc14c90e5bd3836e931) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I5fdeb59056945a602584584edce9c782151ca8ea Reviewed-on: http://review.coreboot.org/9442 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10cbtables: Add RAM config informationDavid Hendricks
This adds the RAM config code to the coreboot tables. The purpose is to expose this information to software running at higher levels, e.g. to print the RAM config coreboot is using as part of factory tests. The prototype for ram_code() is in boardid.h since they are closely related and will likely have common code. BUG=chrome-os-partner:31728 BRANCH=none TEST=tested w/ follow-up CLs on pinky Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Idd38ec5b6af16e87dfff2e3750c18fdaea604400 Original-Reviewed-on: https://chromium-review.googlesource.com/227248 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> (cherry picked from commit 77dd5fb9347b53bb8a64ad22341257fb3be0c106) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Ibe7044cafe0a61214ac2d7fea5f7255b2c11829b Reviewed-on: http://review.coreboot.org/9438 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2015-04-10gpio: add a function to read GPIO array as base-2 valueDavid Hendricks
This adds gpio_base2_value() which reads an array of 2-state GPIOs and returns a base-2 value, where gpio[0] represents the least significant bit. BUG=none BRANCH=none TEST=tested with follow-up patches for pinky Change-Id: I0d6bfac369da0d68079a38de0988c7b59d269a97 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 27873b7a9ea237d13f0cbafd10033a8d0f821cbe Original-Change-Id: Ia7ffc16eb60e93413c0812573b9cf0999b92828e Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/228323 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9412 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2015-04-10gpio: cosmetic changes to tristate_gpios.cDavid Hendricks
This patch makes a few cosmetic changes: - Rename tristate_gpios.c to gpio.c since it will soon be used for binary GPIOs as well. - Rename gpio_get_tristates() to gpio_base3_value() - The binary version will be called gpio_base2_value(). - Updates call sites. - Change the variable name "id" to something more generic. BUG=none BRANCH=none TEST=compiled for veyron_pinky and storm Change-Id: Iab7e32f4e9d70853f782695cfe6842accff1df64 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c47d0f33ea1a6e9515211b834009cf47a171953f Original-Change-Id: I36d88c67cb118efd1730278691dc3e4ecb6055ee Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/228324 Reviewed-on: http://review.coreboot.org/9411 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10gpio: Remove non-ternary tristate mode, make ternaries easierJulius Werner
The function to read board IDs from tristate GPIOs currently supports two output modes: a normal base-3 integer, or a custom format where every two bits represent one tristate pin. Each board decides which representation to use on its own, which is inconsistent and provides another possible gotcha to trip over when reading unfamiliar code. The two-bits-per-pin format creates the additional problem that a complete list of IDs (such as some boards use to build board-ID tables) necessarily has "holes" in them (since 0b11 does not correspond to a possible pin state), which makes them extremely tricky to write, read and expand. It's also very unintuitive in my opinion, although it was intended to make it easier to read individual pin states from a hex representation. This patch switches all boards over to base-3 and removes the other format to improve consistency. The tristate reading function will just print the pin states as they are read to make it easier to debug them, and we add a new BASE3() macro that can generate ternary numbers from pin states. Also change the order of all static initializers of board ID pin lists to write the most significant bit first, hoping that this can help clear up confusion about the endianness of the pins. CQ-DEPEND=CL:219902 BUG=None TEST=Booted on a Nyan_Blaze (with board ID 1, unfortunately the only one I have). Compiled on Daisy, Peach_Pit, Nyan, Nyan_Big, Nyan_Blaze, Rush, Rush_Ryu, Storm, Veryon_Pinky and Falco for good measure. Change-Id: I3ce5a0829f260db7d7df77e6788c2c6d13901b8f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2fa9545ac431c9af111ee4444d593ee4cf49554d Original-Change-Id: I6133cdaf01ed6590ae07e88d9e85a33dc013211a Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219901 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9401 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10gpio: Extend common GPIO header, simplify function namesJulius Werner
We've had gpiolib.h which defines a few common GPIO access functions for a while, but it wasn't really complete. This patch adds the missing gpio_output() function, and also renames the unwieldy gpio_get_in_value() and gpio_set_out_value() to the much easier to handle gpio_get() and gpio_set(). The header is renamed to the simpler gpio.h while we're at it (there was never really anything "lib" about it, and it was presumably just chosen due to the IPQ806x include/ conflict problem that is now resolved). It also moves the definition of gpio_t into SoC-specific code, so that different implementations are free to encode their platform-specific GPIO parameters in those 4 bytes in the most convenient way (such as the rk3288 with a bitfield struct). Every SoC intending to use this common API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most 4 bytes in length. Files accessing the API only need to include <gpio.h> which may pull in additional things (like a gpio_t creation macro) from <soc/gpio.h> on its own. For now the API is still only used on non-x86 SoCs. Whether it makes sense to expand it to x86 as well should be separately evaluated at a later point (by someone who understands those systems better). Also, Exynos retains its old, incompatible GPIO API even though it would be a prime candidate, because it's currently just not worth the effort. BUG=None TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and Veyron_Pinky. Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/220975 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9400 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10chromeos: move VPD MAC address retrieval functionVadim Bendebury
Retrieval of the MAC address from the VPD is a Chrome OS specific feature, required just on one platform so far. There is no need to look for the MAC address in the VPD on all other Chrome OS boards. BRANCH=storm BUG=chromium:417117 TEST=with the upcoming patch applied verified that MAC addresses still show up in the device tree on storm Change-Id: If5fd4895bffc758563df7d21f38995f0c8594330 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: fb4906ac559634321a01b4814f338611b9e98b2b Original-Change-Id: I8e6f8dc38294d3ab11965931be575360fd12b2fc Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/223796 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9398 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-08timer: Add generic udelay() implementationAaron Durbin
Add GENERIC_UDELAY Kconfig option so that a generic udelay() implementation is provided utilizing the monotonic timer. That way each board/chipset doesn't need to duplicate the same udelay(). Additionally, assume that GENERIC_UDELAY implies init_timer() is not required. BUG=None BRANCH=None TEST=Built nyan, ryu, and rambi. May need help testing. Change-Id: I7f511a2324b5aa5d1b2959f4519be85a6a7360e8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1a85fbcad778933d13eaef545135abe7e4de46ed Original-Change-Id: Idd26de19eefc91ee3b0ceddfb1bc2152e19fd8ab Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219719 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9334 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-08armv7: Add fine-grained page table supportJulius Werner
This patch adds an mmu_config_range_kb() function, which can set memory types at the 4KB level by chaining a fine-grained page table to an existing superpage entry. It is only intended for special cases where this level of precision is really necessary and therefore comes with a few practical limitations (the area for each invocation must be confined within a single superpage, and you are not allowed to remap the same region with mmu_config_range() again later). Since the fine-grained page tables need some space, boards intending to use this feature must define a TTB_SUBTABLES() region in their memlayout.ld. BUG=chrome-os-partner:32848 TEST=Booted both Veyron_Pinky (normal) and Nyan_Blaze (LPAE), ensured that they still work. Checksummed the page tables with and without this patch, confirmed that they end up equal. Hacked in some subtable test entries, hexdumped all tables and manually confirmed that they look as expected. Change-Id: I8c3eb7c2eb9c82e2abc5f2c0dda91f5b2eee7023 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2f13e60cf5509b9a63fb7b8d84846daf889dc1b7 Original-Change-Id: Iedf7ca435ae337ead85115200d6987fb0d4828d7 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/223781 Reviewed-on: http://review.coreboot.org/9341 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-08timestamp: Add bootblock start and end to timestamp constantsFurquan Shaikh
BUG=chrome-os-partner:32973 BRANCH=None TEST=cbmem -t to check proper timestamps on ryu Change-Id: Ic31c5d9f3e397d90b08fe1c5e152148f4a278b95 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 92469e04c1c52bd60a8a37f017d865d0a838bff5 Original-Change-Id: I95419a6d240c168c8b6a489cac969390ecf6dea0 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/223345 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9340 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-06New mechanism to define SRAM/memory map with automatic bounds checkingJulius Werner
This patch creates a new mechanism to define the static memory layout (primarily in SRAM) for a given board, superseding the brittle mass of Kconfigs that we were using before. The core part is a memlayout.ld file in the mainboard directory (although boards are expected to just include the SoC default in most cases), which is the primary linker script for all stages (though not rmodules for now). It uses preprocessor macros from <memlayout.h> to form a different valid linker script for all stages while looking like a declarative, boilerplate-free map of memory addresses to the programmer. Linker asserts will automatically guarantee that the defined regions cannot overlap. Stages are defined with a maximum size that will be enforced by the linker. The file serves to both define and document the memory layout, so that the documentation cannot go missing or out of date. The mechanism is implemented for all boards in the ARM, ARM64 and MIPS architectures, and should be extended onto all systems using SRAM in the future. The CAR/XIP environment on x86 has very different requirements and the layout is generally not as static, so it will stay like it is and be unaffected by this patch (save for aligning some symbol names for consistency and sharing the new common ramstage linker script include). BUG=None TEST=Booted normally and in recovery mode, checked suspend/resume and the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies with ToT and looked for red flags. Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614 Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/213370 Reviewed-on: http://review.coreboot.org/9283 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at> Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-04-06Add predefined __ROMSTAGE__ and __RAMSTAGE__ macrosJulius Werner
This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get predefined in their respective stages by make, so that we have one specific macro for every stage. It also renames __BOOT_BLOCK__ and __VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency. This change is intended to provide finer control and clearer communication of intent after we added a new (optional) stage that falls under __PRE_RAM__, and will hopefully provide some robustness for the future (we don't want to end up always checking for romstage with #if defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) && !defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The __PRE_RAM__ macro stays as it is since many features do in fact need to differentiate on whether RAM is available. (Some also depend on whether RAM is available at the end of a stage, in which case #if !defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be authoritative.) It's unfeasable to change all existing occurences of __PRE_RAM__ that would be better described with __ROMSTAGE__, so this patch only demonstratively changes a few obvious ones in core code. BUG=None TEST=None (tested together with dependent patch). Change-Id: I6a06d0f42c27a2feeb778a4acd35dd14bb53f744 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a4ad042746c1d3a7a3bfda422d26e0d3b9f9ae42 Original-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219172 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9304 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-04-04build system: rename __BOOT_BLOCK__ and __VER_STAGE__Patrick Georgi
Drop the inner underscore for consistency. Follows the commit stated below. Change-Id: I75cde6e2cd55d2c0fbb5a2d125c359d91e14cf6d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Based-on-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06 Based-on-Signed-off-by: Julius Werner <jwerner@chromium.org> Based-on-Reviewed-on: https://chromium-review.googlesource.com/219172 Reviewed-on: http://review.coreboot.org/9290 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2015-04-04stddef: Add KHz, MHz and GHz constantsAaron Durbin
This patch adds some simple constants to more easily write and do math with frequencies, analogous to the existing KiB, MiB and GiB constants for sizes. BUG=None TEST=Compiled Veyron_Pinky. Original-Change-Id: I4a1927fd423eb96d3f76f7e44b451192038b02e0 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/221800 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 41bb8026818b4381d4a6d43d2d433c207c3971bc) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I1e708b0aa53533c9ab999793ca2273c6dc68b5f6 Reviewed-on: http://review.coreboot.org/9253 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-04Add table driven way to add platform specific reg_script routinesLee Leahy
Extend lib/reg_script.c to use a platform table to declare additional platform specific register access routine functions. REG_SCRIPT_TYPE_PLATFORM_BASE is the starting value for platform specific register types. Additional register access types may be defined above this value. The type and access routines are placed into reg_script_type_table. The Baytrail type value for IOSF was left the enumeration since it was already defined and is being used for Braswell. BRANCH=none BUG=None TEST=Use the following steps to test: 1. Build for a Baytrail platform 2. Build for the Samus platform 3. Add a platform_bus_table routine to a platform which returns the address of an array of reg_script_bus_entry structures and the number of entries in the array. Change-Id: Ic99d345c4b067c52b4e9c47e59ed4472a05bc1a5 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 2d9fecf4287dff6311a81d818603212248f1a248 Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/215645 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Change-Id: I7cd37abc5a08cadb3166d4048f65b919b86ab5db Original-Reviewed-on: https://chromium-review.googlesource.com/229612 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/9279 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-03rmodule: use struct prog while loading rmodulesAaron Durbin
The rmod_stage_load structure contained the same fields as struct prog. In order to more closely integrate with the rest of program loading use struct prog. Change-Id: Ib7f45d0b3573e6d518864deacc4002802b11aa9c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9143 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-03program loading: unify on struct progAaron Durbin
Instead of having different structures for loading ramstage and payload align to using struct prog. This also removes arch_payload_run() in favor of the prog_run() interface. Change-Id: I31483096094eacc713a7433811cd69cc5621c43e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8849 Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-03program loading: add prog_run() functionAaron Durbin
The prog_run() function abstracts away what is required for running a given program. Within it, there are 2 calls: 1. platform_prog_run() and 2. arch_prog_run(). The platform_prog_run() allows for a chipset to intercept a program that will be run. This allows for CPU switching as currently needed in t124 and t132. Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8846 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-03program loading: introduce struct progAaron Durbin
The struct prog serves as way to consolidate program loading. This abstraction can be used to perform more complicated execution paths such as running a program on a separate CPU after it has been loaded. Currently t124 and t132 need to do that in the boot path. Follow on patches will allow the platform to decide how to execute a particular program. Note: the vboot path is largely untouched because it's already broken in the coreboot.org tree. After getting all the necessary patches pushed then vboot will be fixed. Change-Id: Ic6e6fe28c5660fb41edee5fd8661eaf58222f883 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8839 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-02vpd: retrieve mac addresses and pass them to bootloaderVadim Bendebury
Chrome OS devices firmware usually includes an area called VPD (Vital Product Data). VPD is a blob of a certain structure, in particular containing freely defined variable size fields. A field is a tuple of the field name and field contents. MAC addresses of the interfaces are stored in VPD as well. Field names are in the form of 'ethernet_macN', where N is the zero based interface number. This patch retrieves the MAC address(es) from the VPD and populates them in the coreboot table so that they become available to the bootloader. BUG=chrome-os-partner:32152, chromium:417117 TEST=with this and other patches in place the storm device tree shows up with MAC addresses properly initialized. Change-Id: I955207b3a644cde100cc4b48e51a2ab9a3cb1ba0 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 1972b9e97b57cc8503c5e4dc496706970ed2ffbe Original-Change-Id: I12c0d15ca84f60e4824e1056c9be2e81a7ad8e73 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219443 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9207 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-02chromeos: Add WiFi calibration CBMEM entry pointer to coreboot tableVadim Bendebury
This patch adds plumbing necessary to ensure that the CBMEM WiFi calibration blobs entry, if present, is referenced if the coreboot table. BRANCH=storm BUG=chrome-os-partner:32611 TEST=none - the entry is not yet in the CBMEM Change-Id: I072f2368b628440b6fe84f310eebc1ab945f809e Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: d0330280369753a6520196425e6dfc7d7bd226a3 Original-Change-Id: I04d52934ad1c5466d0d124b32df5ab17c0f59686 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/225270 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9232 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-02smbios: add a family id in smbios type1 familyKane Chen
mosys will use this field to identify system BRANCH=none BUG=chromium:359155 TEST=build ok, use dmidecode to check whether data is written correctly Change-Id: I461215c012b6ad712b3f813a3928e90a23bf54f1 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 7adbdab761cd7b4bda0a43e7b1c4070de26f150a Original-Change-Id: Icfbd4c61fc49a9cb3d3ecd2b622339957963150c Original-Signed-off-by: Kane Chen <kane.chen@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/217400 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/9230 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-01cbfs: correct types used for accessing filesAaron Durbin
In commit 72a8e5e751a7fa97c9d198f68cad49f9d9851669 the Makefile's were updated to use named types for cbfs file addition. However, the call sites were not checked to ensure the types matched. Correct all call sites to use the named types. Change-Id: Ib9fa693ef517e3196a3f04e9c06db52a9116fee7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9195 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-01northbridge/amd/amdfam10: Collect DIMM information for ramstage useTimothy Pearson
1.) Allow MCT information structures to be copied to cbmem. 2.) Retrieve DIMM vendor, model, and serial information. 3.) Allow maximum installable memory to be set via devicetree. Change-Id: I0aecd2fb69ebad0a784c01d40ce211f6975a3ece Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/9137 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-03-31cbfs: add cbfs_serialized.h header fileAaron Durbin
The serialized format of CBFS is separate from the APIs used to traverse and read from CBFS. Separate those out so they can be consumed as a standalone header. Change-Id: I09f71d9c474ee9f23a62b0062ffa777963d1a4dd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9125 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-03-31program loading: provide one cache maintenance callbackAaron Durbin
Instead of having 2 different functions to call when a program is loaded provide a single callback with flags parameter. The previous callbacks for cache management routines did this: for_each_program_segment: arch_program_segment_loaded(start, size); arch_program_loaded(); Now, use one callback instead: for_each_program_segment: arch_segment_loaded(start, size, SEG_FINAL?); Change-Id: I3811cba92e3355d172f605e4444f053321b07a2a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8838 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-31payload loading: remove passing of struct payloadAaron Durbin
There's no need to keep track of struct payload within the boot state machine. It is completely contained within the payload loader module. Change-Id: I16fcecf43d7fb41fc311955fdb82eabbd5c96b11 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8836 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-31loading: move ramstage cache function declarationsAaron Durbin
The functions related to caching ramstage were in cbfs.h. Now that the loading code is separate move those declarations to the common program_loading.h. Change-Id: Ib22ef8a9c66e1d2b53388bceb8386baa6302d28b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8835 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-31cbfs: remove run_address()Aaron Durbin
The run_address() function is not used. Remove it. Change-Id: I96de4cf0a529b08943ff8281cedead642eb415de Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9124 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-03-29arch/x86/boot/smbios: Rename fill_dimm_manufacturer and make publicTimothy Pearson
Change-Id: Ib85701965337bb6231d8df59d43789dfe8a036d3 Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/9136 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-03-29arch/x86/boot/smbios: Add additional SMBIOS defines and enumsTimothy Pearson
Change-Id: I337584d1f4ce32094c24478a99418e0775cf9ab5 Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/9135 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-03-28arm64: add spin table supportAaron Durbin
There was a hacky and one-off spin table support in tegra132. Make this support generic for all arm64 chips. BUG=chrome-os-partner:32082 BRANCH=None TEST=Ran with and without secure monitor booting smp into the kernel. Change-Id: I3425ab0c30983d4c74d0aa465dda38bb2c91c83b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 024dc3f3e5262433a56ed14934db837b5feb1748 Original-Change-Id: If12083a9afc3b2be663d36cfeed10f9b74bae3c8 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/218654 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9084 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-28arm64: Add support for secure monitorFurquan Shaikh
Secure monitor runs at EL3 and is responsible for jumping to the payload at specified EL and also to manage features like PSCI. Adding basic implementation of secure monitor as a rmodule. Currently, it just jumps to the the payload at current EL. Support for switching el and PSCI will be added as separate patches. CQ-DEPEND=CL:218300 BUG=chrome-os-partner:30785 BRANCH=None TEST=Compiles succesfully and secure monitor loads and runs payload on ryu Change-Id: If0f22299a9bad4e93311154e5546f5bae3f3395c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5e40a21115aeac1cc3c73922bdc3e42d4cdb7d34 Original-Change-Id: I86d5e93583afac141ff61475bd05c8c82d17d926 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/214371 Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9080 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-28drivers: add GIC supportAaron Durbin
The GIC is ARM's "Generic Interrupt Controller". This change essentially implements the rudimentary support for a GICv2 implementation that routes all interrupts to Group1. This should also work for GICv1 with security extensions. BUG=chrome-os-partner:31945 BRANCH=None TEST=Built and booted kernel using the code. Change-Id: I9c9202c1309ca9e711e00d742085a6728552c54b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d1cd9b6b76035af107b7dc876f90777698162d34 Original-Change-Id: I4c5b84bfe888ac33fa01c8d64a3dffe1b5ddc823 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/217512 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9075 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-03-27cbfs/rmodule: add architecture specific operations at stage loadIonela Voinescu
Two weak functions were added so that architecture specific operations on each segment of payload or stage can be performed. Each architecture must define its own operations, otherwise the behavior will default to do-nothing functions. This patch has been updated by to fit more in line with how program loading is currently being done. The API is the same as the original, but all call sites to stages/payloads have been updated. This is known to break any archs that use rmodule loading that needs cache maintenance. That will be fixed in a forthcoming patch. Also, the vboot paths are left as is for easier upstreaming of the rest of the vboot patches. Original-Change-Id: Ie29e7f9027dd430c8b4dde9848fa3413c5dbfbfa Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/239881 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> (cherry picked from commit c82c21ce87a4c02bd9219548a4226a58e77beef0) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Ifcee5cd9ac5dbca991556296eb5e170b47b77af7 Reviewed-on: http://review.coreboot.org/8837 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-27smbios: add funtion for smbios type17Kane Chen
Add smbios type 17 which can optionally be implemented at the platform or mainboard level In order to create SMBIOS type17, you will need to fill memory_info data BUG=None BRANCH=None TEST=Compile successfully on rambi and samus Boot to chromeOS on samus and rambi Original-Change-Id: Ie4da89135c879d7a687305d423103fcfcbb96e3f Original-Signed-off-by: Kane Chen <kane.chen@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/210005 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> (cherry picked from commit 634b899ba41242caa800d7b570f3a339c738db77) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I61d1e8b1d32d43f0011b0f93966d57646ea0eb63 Reviewed-on: http://review.coreboot.org/8955 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-26timer: remove rela_time typeAaron Durbin
Current usage doesn't require rela_time. Remove it. BUG=None BRANCH=None TEST=Built and booted. Change-Id: I25dcc1912f5db903a0523428ed1c0307db088eaa Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 26a13d4c615473407f401af4330199bbfe0dd2b1 Original-Change-Id: I487ea81ffb586110e9a1c3c2629d4af749482177 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219714 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/8896 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-26fix how to interpret board id read from gpiosDaisuke Nojiri
nyan blaze fails to boot because tristates of the board id are interpreted in the reverse order. this change fixes it. BUG=none TEST=Booted Blaze to Linux. Built firmware for Storm. Branch=none Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Change-Id: I4ff8a15cf62869cea22931b5255c3a408a778ed2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3f59b13d615a8985edf2029d89af05e95aefad33 Original-Change-Id: I6d81092becb60d12e1cd2a92fc2c261da42c60f5 Original-Reviewed-on: https://chromium-review.googlesource.com/211700 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: http://review.coreboot.org/8980 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-26Restore name of the function reading tertiary GPIO statesVadim Bendebury
The name was changed due to review comments misunderstanding, it should be restored to properly convey what the function does. BUG=chrome-os-partner:30489 TEST=verified that Storm still properly reports board ID Change-Id: Iba33cf837e137424bfac970b0c9764d26786be9c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c0fff28c6ebf255cb9cf9dfe4c961d7a25bb13ff Original-Change-Id: I4bd63f29afbfaf9f3e3e78602564eb52f63cc487 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/211413 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8979 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-24cbfs: expose init_backing_media()Aaron Durbin
I broke cbfs loading with commit 358901. As multiple functions are being reused one needs to ensure there is always a cbfs media object allocated on the stack and initialized. Ya for no common writable globals. TEST=Ran qemu-armv7. CBFS loading works again. Change-Id: Ibd047af7dcd8575e6203651471079fc2042da282 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8973 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Duncan Laurie <dlaurie@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2015-03-24vboot2: factory-initialize kernel space in tpmDaisuke Nojiri
this change makes coreboot initialize kernel space and backup space in the tpm when no firmware space is found in the tpm. BUG=chrome-os-partner:32410 TEST=Forced factory initialization and verified it went through without errors. BRANCH=None Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I777e3cb7004870c769163827543c83665d3732b9 Original-Reviewed-on: https://chromium-review.googlesource.com/220412 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit d8c0c407bf0fed60d76441ada7bedd36f6fc3a38) Change-Id: Icc3779125262b4499e47781991ebbf584abf074a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8885 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-24vboot2: load decompressed stage directly to load addressDaisuke Nojiri
this change allows vboot_load_stage to load a decompressed stage directly to the load address without using the cbfs cache. BUG=None TEST=Booted Nyan Blaze. BRANCH=None Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I76530276ff9a87b44f98a33f2c34bd5b2de6888f Original-Reviewed-on: https://chromium-review.googlesource.com/219028 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit 0ad6f7fee9df31e1b35d4df9a8c373516416a235) Change-Id: I7abdbdda0cc549894dfb9d599a576bba0a4fadfc Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8883 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-23vboot2: read secdata and nvdataDaisuke Nojiri
This code ports antirollback module and tpm library from platform/vboot_reference. names are modified to conform to coreboot's style. The rollback_index module is split in a bottom half and top half. The top half contains generic code which hides the underlying storage implementation. The bottom half implements the storage abstraction. With this change, the bottom half is moved to coreboot, while the top half stays in vboot_reference. TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link. BUG=none Branch=none Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e Original-Reviewed-on: https://chromium-review.googlesource.com/206065 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Original-Reviewed-by: Luigi Semenzato <semenzato@chromium.org> (cherry picked from commit 6b66140ac979a991237bf1fe25e0a55244a406d0) Change-Id: Ia3b8f27d6b1c2055e898ce716c4a93782792599c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8615 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-03-23Publish the board ID value in coreboot table, when configuredVadim Bendebury
Board ID value is usually of interest to bootloaders. Instead of duplicating the board ID discovery code in different bootloaders let's determine it in coreboot and publish it through coreboot table, when configured. BUG=chrome-os-partner:30489 TEST=none yet Change-Id: Ia1e36b907ac15b0aafce0711f827cb83622e27bb Original-Change-Id: Iee247c44a1c91dbcedcc9058e8742c75ff951f43 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/210116 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit b2057a02db9391e2085b138eea843e6bb09d3ea2) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8719 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-23Generalize revision number calculation functionVadim Bendebury
Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-23PCIe: Add L1 Sub-State support.Kenji Chen
Enable L1 Sub-State when both root port and endpoint support it. [pg: keyed the feature to MMCONF_SUPPORT, otherwise boards without that capability fail to build.] Change-Id: Id11fc7c73eb865411747eef63f5f901e00a17f84 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6ac04ad7e2261846e40da297f7fa317ccebda092 Original-BUG=chrome-os-partner:31424 Original-TEST=Build a image and run on Samus proto boards to check if the settings are applied correctly. I just only have proto boards and need someone having EVT boards to confirm the settings. Original-Signed-off-by: Kenji Chen <kenji.chen@intel.com> Original-Change-Id: Id1b5a52ff0b896f4531c4a6e68e70a2cea8c736a Original-Reviewed-on: https://chromium-review.googlesource.com/221436 Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/8832 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-21timer: add stopwatch constructAaron Durbin
There's a lot of places where expiration and running time are open coded. Allow for those places to be simplified by adding a stopwatch construct. The stopwatch can have an expiration or just be used to accumulate time. BUG=None TEST=Built and verified API works as expected by using implementation. Change-Id: Ibd636542b16d8554f1ff4512319a53dce81c97e5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: bc623a1b36eb08c5877591c4509cd61131c62617 Original-Change-Id: I53604900fea7d46beeccc17f1dc7900d5f28518b Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219492 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/8815 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-20loaders: add run_romstage() function to bootblockAaron Durbin
Provide a common run_romstage() function to be used by bootblocks to load and run romstage. This is similar to run_ramstage() in that it provides a single entry point for doing the necessary work of loading and running romstage. Change-Id: Ia9643cc091f97a836cf5caefdff8df4a3443df4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8709 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-20loaders: add program_loading.h header fileAaron Durbin
Instead of two headers for payload and ramstage loading combine the 2 files into one. This also allows for easier refactoring by keeping header files consistent. Change-Id: I4a6dffb78ad84c78e6e96c886d361413f9b4a17d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8708 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-20stdlib: Add IS_ALIGNED macroAndrew Bresticker
Add a macro to check if a value is aligned. BUG=chrome-os-partner:36258 BRANCH=none TEST=Build and boot on Pistachio. Change-Id: I0680954eb1b1964a631527f96aa0570a32944fa1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 4f1717648e0a4b54217d71f8d0a15d496737d156 Original-Change-Id: Ie0bc1374918a7ffaaec5fea62c1193a42edd416c Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/246692 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/8757 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-03-18bootstate: use structure pointers for scheduling callbacksAaron Durbin
The GCC 4.9.2 update showed that the boot_state_init_entry structures were being padded and assumed to be aligned in to an increased size. The bootstate scheduler for static entries, boot_state_schedule_static_entries(), was then calculating the wrong values within the array. To fix this just use a pointer to the boot_state_init_entry structure that needs to be scheduled. In addition to the previous issue noted above, the .bs_init section was sitting in the read only portion of the image while the fields within it need to be writable. Also, the boot_state_schedule_static_entries() was using symbol comparison to terminate a loop which in C can lead the compiler to always evaluate the loop at least once since the language spec indicates no 2 symbols can be the same value. Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8699 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-13Use a common boardid.h instead of per board copiesVadim Bendebury
There is no point in duplicating boardid.h per board - they are all the same. Let's keep a single instance in the common include directory and let the linker report a problem if one tries using this function on a board where it is not supported. BUG=chrome-os-partner:30489 TEST=verified that coreboot builds fine for nyan_big and nyan_blaze. Original-Change-Id: Ifbe9c2287a1d828d4db74c637d1d02047ac4da25 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209699 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 589e6415faf18ca6aaf44da343dd33eadc8a53d3) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I8eef89cb822611a0050e5a50fc4b970eebd8d962 Reviewed-on: http://review.coreboot.org/8666 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-11x86 SMM: Replace weak prototypes with weak function stubKyösti Mälkki
Change-Id: I682617cd2f4310d3e2e2ab6ffec51def28a4779c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7961 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-10AMD Bald Eagle: Add northbridge files for new AMD processorBruce Griffith
Also fix a typo in a config option for SteppeEagle. Change-Id: Iad51cc917217aa0eac751dc805c304652d20e066 Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/7247 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-03-09Add and consistently use wrapper macro for romstage static variablesJulius Werner
x86 systems run their romstage as execute-in-place from flash, which prevents them from having writable data segments. In several code pieces that get linked into both romstage and ramstage, this has been worked around by using a local variable and having the 'static' storage class guarded by #ifndef __PRE_RAM__. However, x86 is the only architecture using execute-in-place (for now), so it does not make sense to impose the restriction globally. Rather than fixing the #ifdef at every occurrence, this should really be wrapped in a way that makes it easier to modify in a single place. The chromeos/cros_vpd.c file already had a nice approach for a wrapper macro, but unfortunately restricted it to one file... this patch moves it to stddef.h and employs it consistently throughout coreboot. BRANCH=nyan BUG=None TEST=Measured boot time on Nyan_Big before and after, confirmed that it gained 6ms from caching the FMAP in vboot_loader.c. Original-Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/203033 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit c8127e4ac9811517f6147cf019ba6a948cdaa4a5) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I44dacc10214351992b775aca52d6b776a74ee922 Reviewed-on: http://review.coreboot.org/8055 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-03-09console: Fix broken early_print.h include guardsStefan Reinauer
Make compilation fail if this is included in non-romcc compiles. I am a bit surprised that this ever compiled. Change-Id: I8dfc1229681819d2381821a0195a89b44dd76b6a Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/8420 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-03-09build.h: remove variable for the builduser, -hostname and -domainAlexander Couzens
They don't contain any useful information and also block us from having reproducible builds. Change-Id: Ib03887f6a548230de9f75fb308c73a800e180c48 Signed-off-by: Alexander Couzens <lynxis@fe80.eu> Reviewed-on: http://review.coreboot.org/8616 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <gaumless@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-09device/pciexp: Add support for PCIe CLK power managementKane Chen
Set PCIe "Enable Clock Power Management", if endpoint supports it. BUG=chrome-os-partner:31424 BRANCH=none TEST=build and boot on rambi, check Enable Clock Power Management in link control register is set properly Change-Id: Ie54110d1ef42184cfcf47c9fe4d735960aebe47f Signed-off-by: Kane Chen <kane.chen@intel.com> Reviewed-on: https://chromium-review.googlesource.com/220742 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> [Edit commit message.] Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/8447 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-08device: drop i915 specific headers from resource allocator includesStefan Reinauer
src/include/device/ is the place for include files of the resource allocator. Hence, drop the i915 include file copies and use the ones supplied with the i915 driver instead. The only remaining user of this was the Intel Whitetip Mountain 2 reference board, all other occurences have been previously fixed already. Change-Id: Ib9f72df4e8f847597508971e9dbf671f49019767 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/8140 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-07AMD: Uniformly define MSRs for TOP_MEM and TOP_MEM2Kyösti Mälkki
Make the build tolerate re-definitions. Change-Id: Ia7505837c70b1f749262508b26576e95c7865576 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8609 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-04coreboot memrange: Two changes for zero size or empty memrangeFurquan Shaikh
1) Add check for zero size in memrange. 2) Add public memrange_init_empty function to allow initializing only the memrange structure without filling in device resources BUG=None BRANCH=None TEST=Compiles and runs succesfully for rush MMU memranges. Original-Change-Id: I8e4d864cbc9a770cd208f8a9f83f509dc7ace894 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/208957 Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 5c42301c2a51a1a2a29ef58012f210d03bd37f94) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I8d63abb15efda74270ef6fa3c0df55c05659595d Reviewed-on: http://review.coreboot.org/8597 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2015-03-01devicetree: Drop dummy root_dev opsKyösti Mälkki
This is just dead code. Should we decide that we want some of these calls made, they would be implemented in the mainboard context. Change-Id: I1f097c8da722f3afab9aa1c80b96590c7ca457d5 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8532 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-02-20AMD K8 fam10: Refactor offset_unitid configurationKyösti Mälkki
Change-Id: I198f2ad321e1a8b6d932f5624b129e312e36a309 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8349 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-02-16acpi: Generate valid ACPI processor objectsTimothy Pearson
The existing code generated invalid ACPI processor objects if the core number was greater than 9. The first invalid object instance was autocorrected by Linux, but subsequent instances conflicted with each other, leading to a failure to boot if more than 10 CPU cores were installed. The modified code will function with up to 99 cores. Change-Id: I62dc0eb61ae2e2b7f7dcf30e9c7de09cd901a81c Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/8422 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-02-15x86: Change MMIO addr in readN(addr)/writeN(addr, val) to pointerKevin Paul Herbert
On x86, change the type of the address parameter in read8()/read16/read32()/write8()/write16()/write32() to be a pointer, instead of unsigned long. Change-Id: Ic26dd8a72d82828b69be3c04944710681b7bd330 Signed-off-by: Kevin Paul Herbert <kph@meraki.net> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/7784 Tested-by: build bot (Jenkins)
2015-02-10PCI subsystem: Remove AGP bridge typeKyösti Mälkki
There is no auto-detection for AGP type and we have no hardware that selects this. Furthermore, we treat AGP bridges just like PCI bridges, there is no optimisation for higher bandwidth. Change-Id: I4fe87c83411643cb9b8d3216f2af07bf098174d3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8367 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-02-06drivers/pc80/mc146818rtc: Reduce superfluous preprocessor useAlexandru Gagniuc
cmos_init() had layers of preprocessor directives, which resulted in a complete mess. Refactor it to make use of the IS_ENABLED() macro. This improves readability significantly. One of the changes is to remove in inline stub declaration of (get|set)_option. Although that provided the ability for the compiler to optimize out code when USE_OPTION_TABLE is not selected, there is no evidence that such savings are measureable. Change-Id: I07f00084d809adbb55031b2079f71136ade3028e Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/8306 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2015-02-06include/types.h: Provide BIT() macroAlexandru Gagniuc
This macro is controversial for arches where the bits are numbered MSb first, though we don't support such an arch. We've seen this macro creep into our tree in different places, so provide it in one place. Change-Id: I86cd8a16420f34ef31b615aec4e0f7bd3191ca35 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/8280 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@gmail.com> Reviewed-by: David Hendricks <dhendrix@chromium.org>
2015-02-06FSP & CBMEM: Fix broken cbmem CAR transition.Martin Roth
1) Save the pointer to the FSP HOB list to low memory at address 0x614. This is the same location as CBMEM_RESUME_BACKUP - the two aren't used in the same platform, so overlapping should be OK. I didn't see any documentation that actually said that this location was free to use, and didn't need to be restored after use in S3 resume, but it looks like the DOS boot vector gets loaded juat above this location, so it SHOULD be ok. The alternative is to copy the memory out and store it in cbmem until we're ready to restore it. 2) When a request for the pointer to a CAR variable comes in, pass back the location inside the FSP hob structure. 3) Skip the memcopy of the CAR Data. The CAR variables do not get transitioned back into cbmem, but used out of the HOB structure. 4) Remove the BROKEN_CAR_MIGRATE Kconfig option from the FSP platform. Change-Id: Iaf566dce1b41a3bcb17e4134877f68262b5e113f Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/8196 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2015-02-05drivers/xgi/z9s: Port Linux framebuffer initialization to corebootTimothy Pearson
Add native XGI Z9s framebuffer support to coreboot XGI initialization code largely taken from Linux 3.18.5 TEST: Booted KFSN4-DRE with XGI Volari Z9s into SeaBIOS with SeaVGABIOS enabled. Text appeared correctly on screen and interaction with graphical comboot menu was successful. However, Linux cleared the framebuffer on boot, rendering the screen useless until Linux loaded its native xgifb driver. Change-Id: I606a3892849fc578b0c4d74536aec0a0adef3be3 Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Reviewed-on: http://review.coreboot.org/8331 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-02-05AMD K8: Remove some excessive preprocessor useKyösti Mälkki
Tests on CPUID are valid regardless of revision. Change-Id: I5a3a01baca2c0ecfb018ca7965994ba74889a2e2 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8337 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-02-03cpu/amd (non-AGESA): Load microcode updates from CBFSKyösti Mälkki
Change-Id: Ic67856414ea2fea9a9eb95d72136cb05da9483fa Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/4502 Tested-by: build bot (Jenkins) Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2015-02-03cpu/amd/model_10xxx: Remove UPDATE_CPU_MICROCODE optionAlexandru Gagniuc
This option is now deperecated by loading microcode updates from cbfs. Remove this option in anticipation of implementing CBFS loading for AMD cpus. Removing it beforehand results in less patch overhead. Change-Id: Ibdef7843db686734e2b6b1568692720fb543b240 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/8322 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2015-01-30devicetree: Search PnP device node from the tree by pathKyösti Mälkki
Copied from device_util.c with added ROMSTAGE_CONST. Change-Id: If872631ed96a79b9a0b15e09382d6f81098c8db3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8297 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-01-27CBMEM: Always use DYNAMIC_CBMEMKyösti Mälkki
Drop the implementation of statically allocated high memory region for CBMEM. There is no longer the need to explicitly select DYNAMIC_CBMEM, it is the only remaining choice. Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7851 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-01-27CBMEM: Support DYNAMIC_CBMEM with LATE_CBMEM_INITKyösti Mälkki
We can now create CBMEM with dynamic allocation even if CBMEM location is resolved late in ramstage. Change-Id: I8529ccbcd4a0e567ebe0a46232ac5d16476e81a8 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7861 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2015-01-27CBMEM: Do not use get_top_of_ram() with DYNAMIC_CBMEMKyösti Mälkki
The name was always obscure and confusing. Instead define cbmem_top() directly in the chipset code for x86 like on ARMs. TODO: Check TSEG alignment, it used for MTRR programming. Change-Id: Ibbe5f05ab9c7d87d09caa673766cd17d192cd045 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7888 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>