summaryrefslogtreecommitdiff
path: root/src/include
AgeCommit message (Collapse)Author
2015-04-22armv8/secmon: Disable and Enable GIC in PSCI pathFurquan Shaikh
Disable and enable GIC before switching off a CPU and after bringing it up back respectively. BUG=None BRANCH=None TEST=Compiles successfully and psci commands work for ryu. Change-Id: Ib43af60e994e3d072e897a59595775d0b2dcef83 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d5271d731f0a569583c2b32ef6726dadbfa846d3 Original-Change-Id: I672945fcb0ff416008a1aad5ed625cfa91bb9cbd Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/265623 Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org> 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/9926 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-04-22device: Add class and subclass name supportLee Leahy
Add support to display class and subclass names for PCI devices. BRANCH=none BUG=None TEST=Build and run on strago/cyan. Change-Id: I5136fae45b8a1cd02541f233d29a246cdfcd8331 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a7c9b0d7201b09a06ea32f0db84187d15f767c80 Original-Change-Id: Ibf2ee89dd84040ca6ab0e52857a69f7ed0c28f37 Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/263342 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com> Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com> Reviewed-on: http://review.coreboot.org/9901 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-04 06:09:32 +0000