summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2015-04-21storm: print uber-sbl informationVadim Bendebury
Process information reported by uber-sbl: print out its version and RPM and KRAIT log contents. BRANCH=storm BUG=chrome-os-partner:30623 TEST=rebooted a storm device, checked out /sys/firmware/log after booting up Chrome OS: localhost ~ # head -29 /sys/firmware/log | tail -15 Uber-sbl version: @vbendeb-AAABANAZA Section 0 log: 0 :00:SBL1, Start 0 :00:SBL-RO Krait 2623 :00:SBL-RO Krait 0 :00:BB 4666 :00:BB 0 :00:sbl1_hw_init, Start 6130 :00:sbl1_hw_init, Delta 0 :00:SBL1, End 15372:00:SBL1, Delta Section 1 log: 0 :00:SBL-RO Krait, Start 0 :00:SBL-RO Krait, End 336 :00:SBL-RO Krait, Delta localhost ~ # Change-Id: I524dbb49f676046a43bfba26b31b2834c8d2769c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: dcabca6eb87dcead0c9c33749ed76ac939d843c1 Original-Change-Id: Ic037f936ff2d09b0346fb5239094e7928dfd7620 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/252830 Original-Reviewed-by: Varadarajan Narayanan <varada@qti.qualcomm.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@gmail.com> Reviewed-on: http://review.coreboot.org/9843 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21armv7: preserve bootblock invocation parameterVadim Bendebury
Some platforms may pass as a parameter the maskrom or vendor startup code information when calling the bootblock. Make sure the bootblock startup code saves this parameter for use by coreboot. As we don't want to touch memory before caches are initialized, save the passed in parameter in r10 for the duration of cache initialization. Added warning comments to help enforcing that cache initialization code does not touch r10. BRANCH=storm BUG=chrome-os-partner:30623 TEST=with the rest of the patches applied see the QCA uber-sbl report in the coreboot console output. Change-Id: Ic6a09e8c3cf13ac4f2d12ee91c7ab41bc9aa95da Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e41584f769eb042604883275b0d0bdfbf5b0d358 Original-Change-Id: I517a79dc95040326f46f0b80ee4e74bdddde8bf4 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255144 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@gmail.com> Reviewed-on: http://review.coreboot.org/9842 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21ipq808x: add uber sbl parameter definitionsVadim Bendebury
This describes the structure of the information passed through a pointer by uber-sbl to be processed by the coreboot bootblock. BRANCH=storm BUG=chrome-os-partner:30623 TEST=with the rest of the patches applied observed uber-sbl information added to the coreboot console log. Change-Id: If04c4ee0ccfda3df45bd22eb576aaa5b51f1c4b5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ed39e2bcd793fd490416b407f627b5a9a86b8f78 Original-Change-Id: I1dffbf4559853a818e81ca5fdeff013cf008dd6a Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255143 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@gmail.com> Reviewed-on: http://review.coreboot.org/9841 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21urara: I2C clock and MFIO setup function for all interfacesIonela Voinescu
The I2C MFIO setup function now supports all interfaces. Also, the API for the clock setup function changed to support all interfaces. BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; all I2C interfaces were tested with the TPM and they all work properly. BRANCH=none Change-Id: I6dfd1c4647335878402cabb2ae512d6e3737a433 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f8a7ffb54e3f5092c9844b9b502949d3cfc053d1 Original-Change-Id: Ibd67c07acf3d1d9c594faa8ced5ab56d9abb2e40 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/256362 Original-Reviewed-by: Chris Lane <chris.lane@frontier-silicon.com> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9840 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21pistachio: add clock setup for all I2C interfacesIonela Voinescu
BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; all I2C interfaces were tested with the TPM and they all work properly. BRANCH=none Change-Id: I02202585140beb818212c02800f6b7e4966a922a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 33b2adecc4939ac73fffba47adf1c8306a888b8d Original-Change-Id: Ida7eaa72d4d6e6b034319086410de5baa63788bc Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/256361 Original-Reviewed-by: Chris Lane <chris.lane@frontier-silicon.com> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9839 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-21arm(64): Manually clean up the mess left by write32() transitionJulius Werner
This patch is a manual cleanup of all the rubble left by coccinelle waltzing through our code base. It's generally not very good with line breaks and sometimes even eats comments, so this patch is my best attempt at putting it all back together. Also finally remove those hated writel()-style macros from the headers. BRANCH=none BUG=chromium:444723 TEST=None (depends on next patch) Change-Id: Id572f69c420c35577701feb154faa5aaf79cd13e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 817402a80ab77083728b55aed74b3b4202ba7f1d Original-Change-Id: I3b0dcd6fe09fc4e3b83ee491625d6dced98e3047 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254865 Reviewed-on: http://review.coreboot.org/9837 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21arm(64): Globally replace writel(v, a) with write32(a, v)Julius Werner
This patch is a raw application of the following spatch to src/: @@ expression A, V; @@ - writel(V, A) + write32(A, V) @@ expression A, V; @@ - writew(V, A) + write16(A, V) @@ expression A, V; @@ - writeb(V, A) + write8(A, V) @@ expression A; @@ - readl(A) + read32(A) @@ expression A; @@ - readb(A) + read8(A) BRANCH=none BUG=chromium:444723 TEST=None (depends on next patch) Change-Id: I5dd96490c85ee2bcbc669f08bc6fff0ecc0f9e27 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 64f643da95d85954c4d4ea91c34a5c69b9b08eb6 Original-Change-Id: I366a2eb5b3a0df2279ebcce572fe814894791c42 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254864 Reviewed-on: http://review.coreboot.org/9836 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21arm(64): Change write32() argument order to match x86Julius Werner
This patch changes the argument order for the (now temporarily unused) write32() accessor macro (and equivalents for other lengths) from (value, address) to (address, value) in order to conform with the equivalent on x86. Also removes one remaining use of write32() on ARM that slipped through since coccinelle doesn't inspect header files. BRANCH=none BUG=chromium:444723 TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky. Change-Id: Id5739b144f6a5cfd40958ea68510dcf0b89fbfa9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f02cae8b04f2042530bafc91346d11bb666aa42d Original-Change-Id: Ia91c2c19d8444e853a2fc12590a52c2b6447a1b9 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254863 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9835 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21arm(64): Replace write32() and friends with writel()Julius Werner
This patch is a raw application of the following spatch to the directories src/arch/arm(64)?, src/mainboard/<arm(64)-board>, src/soc/<arm(64)-soc> and src/drivers/gic: @@ expression A, V; @@ - write32(V, A) + writel(V, A) @@ expression A, V; @@ - write16(V, A) + writew(V, A) @@ expression A, V; @@ - write8(V, A) + writeb(V, A) This replaces all uses of write{32,16,8}() with write{l,w,b}() which is currently equivalent and much more common. This is a preparatory step that will allow us to easier flip them all at once to the new write32(a,v) model. BRANCH=none BUG=chromium:451388 TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky. Change-Id: I16016cd77780e7cadbabe7d8aa7ab465b95b8f09 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 93f0ada19b429b4e30d67335b4e61d0f43597b24 Original-Change-Id: I1ac01c67efef4656607663253ed298ff4d0ef89d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254862 Reviewed-on: http://review.coreboot.org/9834 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-21veyron_{brain,danger}: Specify vboot romstage and ramstage indicesDavid Hendricks
This applies the same hack to Danger and Brain as on Rialto which allows us to remove the EC-related sections from their respective flashmaps. BUG=none BRANCH=veyron CQ-DEPEND=CL:255669 TEST=built and booted on Brain w/ depthcharge and mosys changes, was able to read vbnv data from userspace Change-Id: I95715d59a21cd081ac4a3a2216576ede5620f1a5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 4de4273be9ac80ca77a34bc076d1f265fbb94e9f Original-Change-Id: I6c2041e8c17ab157599255a505aaef5e2447a241 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255780 Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9832 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21rk3288: disable rk808 DCDC_UV_ACT_REG restart converter functionhuang lin
if DCDC_UV_ACT_REG setted, when the buck voltage drop to 85%, rk808 will reset this buck, but now when the current consumption large, rk808 may miscarriage of justice this status, so we must disable this function BUG=chrome-os-partner:34834 TEST=Boot from jerry, and do RUNIN test sucess BRANCH=None Change-Id: I08cef73b88d6c2722b389c632c7db29605f4545d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 858c8abc11a824fc3d991a39a49710243f4b1473 Original-Change-Id: I46ebe332c576eebd3386b5042b146a8b57a5c194 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/254496 Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Original-Tested-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9831 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21veyron: The ODT function is disabled for LPDDR3jinkun.hong
We found that we should better keep ODT off for LPDDR3 on our boards. BRANCH=veyron BUG=chrome-os-partner:37346 TEST=Boot veyron_speedy normal Change-Id: Id158c88769cf7ed1a5127cd09bad679a2f5e6a01 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0d85725a6faedb5bdbe8731991c225c31f138599 Original-Change-Id: Iebb8e74706756508dd56b85ad87baad48893c619 Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com> Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255381 Reviewed-on: http://review.coreboot.org/9830 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21veyron: Sync up SDRAM configurationsJulius Werner
This patch adds all SDRAM configurations currently in use for any Veyron board to all boards. In the future we might decide that we want to reuse known good memory from one board on another, and having all of these in there already might help us avoid a firmware rev. We can still differentiate them later if the need ever arises. Not touching Rialto since it already decided to go its own way and replace an existing RAM code with it's own 1GB configuration. Also adjusting the names of the recently added DDR3 4GB configs to fit the existing scheme. Includes changes from "veyron: The ODT function is disabled LPDDR3". BRANCH=veyron BUG=None TEST=Compiled all Veyron boards, booted on Jerry. Change-Id: I817efd4b467a5a9587475a82df207048173e7bd5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 36d3fe138b154a16700e3c7adbb33834ff1c5284 Original-Change-Id: I4d037967dcb5cbd6b2b82f347f6b19541559b61a Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255665 Reviewed-on: http://review.coreboot.org/9829 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21rockchip: configure lpddr odt properlyDerek Basehore
The wrong offsets were being used for the GRF_SOC_CON2 register. This also configures odt based on the value of odt in the sdram_params for lpddr systems. BUG=chrome-os-partner:37346 TEST=boot veyron_speedy and veyron_jerry BRANCH=None Change-Id: I13ec3d0df162fe73fabf8af40dd5472e15d6f6af Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 403ab13de17290dc3766bd6f1a03b6effbe58b41 Original-Change-Id: Ic0c18cc7ccf861ef8749e6c950fab9a2802e5f26 Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255584 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9828 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21cbfs: Print absolute offsets of loaded filesVadim Bendebury
Add the absolute offset value to the CBFS log, to make it easier to understand which particular CBFS section the file is loaded from. BRANCH=storm BUG=none TEST=rebooted a Whirlwind device, observed an empty line before the ramstage section of the log and absolute offsets reported by CBFS. Change-Id: Ifcb79ab386629446b98625a5416dfa5850a105f6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ecc4d1df7c51a263230c45ecac5981d53bdd44b1 Original-Change-Id: I5cc727127374d6e55b8ff6f45b250ef97125a8ec Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/255120 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9827 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21veyron_jerry: support K4B8G1646Q-4GB and H5TC8G63XXX-4GB ddr3jinkun.hong
add the K4B8G1646Q-4GB and H5TC8G63XXX-4GB ddr3 inf file, and use ram_id 1110 correspond to K4B8G1646Q-4GB ddr3 use ram_id 1111 correspond to H5TC8G63XXX-4GB ddr3 BUG=None TEST=Boot veyron_jerry normal BRANCH=None Change-Id: I3398516a9f2c2e44c9f5d08d0a3ab6e76b5c6f5f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: b8dfc455bb93c2daf567e3b6e39c0a715e44311c Original-Change-Id: I90250cb84eb140f93c4fc655fb3b90584dd515c0 Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/255010 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9826 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21x86: Allow builds without ACPI tablesLee Leahy
Fix build bug that is referencing vboot_data from vendorcode/google/chromeos/gnvs.c when CONFIG_HAVE_ACPI_TABLES is not set. BRANCH=none BUG=None TEST=Build and run on Glados 1. Checkout updated patches for config, skylake and glados through FspNotify1 2. Verify that mainboard/intel/glados/Kconfig does not select HAVE_ACPI_TABLES 3. emerge-glados coreboot 4. Test passes if build completes successfully Change-Id: Ida5ab8b8dafe30b11dc80dab935e3223d4c760d3 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1908079360aa065a36956d487eb93142e9c012a1 Original-Change-Id: Icac3845f7e2d1ddffa5f787a640033fba286c13e Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/254360 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/9825 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21ipq806x: i2c: stop transfer as soon as an error is reportedSourabh Banerjee
I2c transfer may consist of multiple segments (for instance write segment to set the register address and then a read segment to read the register value). Transfer should be stopped as soon as a segment processing error has been reported. BRANCH=master BUG=chrome-os-partner:35328 TEST=transfer shall not process the read segment when the write segment fails Change-Id: I85b7b59b376ce33ba3f6d2526be86e9f6585d97b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 50cd4d40851b3cea99183c549c47b4486a3deb4a Original-Change-Id: Id65f995d860dd670b289fbdd9eb0ca19a50d7007 Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254494 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9824 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21ipq806x: i2c: write function fixed to avoid spurious successSourabh Banerjee
The qup_i2c_write_fifo() made to query QUP_I2C_MASTER_STATUS after QUP transitions into PAUSE state to ensure that it captures the correct status. Handled more error bits. BRANCH=chromeos-2013.04 BUG=chrome-os-partner:35328 TEST=Booted up storm P0.2, verified that the TPM on GSBI1 works. Verified that SUCCESS is not reported when the write FIFO has failed. Change-Id: Ia91638d37b3fa8449630aa2cf932114363b2db78 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 75e0d59d2e6ba03182003f22944dbf99ce3eb412 Original-Change-Id: Ic4e8e85686499ce71ad3258b52e687ceff36a1f8 Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254495 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9823 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21arch/mips: simplify cache operationsIonela Voinescu
Cache operations are simplified by removing assembly implementation and replacing it with simpler C code. BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; caches are properly invalidated; BRANCH=none Change-Id: I0f092660549c368e98c208ae0c991fe6f5a428d7 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: bf99849e75813cba865b15af9e110687816e61e4 Original-Change-Id: I965e7929718424f92f3556369d36a18ef67aa0d0 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/250792 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9820 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21rk3288: support single channel ddrjinkun.hong
When using single-channel ddr, DMC channel 1 need to reset dll, otherwise it will lead to pmdomain idle request fails. BUG=chrome-os-partner:35654 BRANCH=veyron TEST=boot rialto Change-Id: Id6b673187c688d238e9a391b3d98720c783e3af4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 927e8426104f8869e139c3f60a04cd49bf726e61 Original-Change-Id: I8be1567040ddb5f2a2b0d06568e517d794ead87a Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/250060 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9819 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21urara: Identity map DRAM/SRAMAndrew Bresticker
Using identity_map(), map the DRAM/SRAM regions to themselves (which happens to be using KUSEG on urara). The bootblock (which still runs in KSEG0) sets up the identity mapping in bootblock_mmu_init() so that ROM/RAM stages can be loaded into the KUSEG address range. The stack and pre-RAM CBMEM console also remain in KSEG0 since we don't really care about their physical addresses. Also splitting CBFS cache to pre and post RAM, to allow for larger rambase images. BUG=chrome-os-partner:36258 BRANCH=none TEST=With the rest of coreboot and depthcharge patches applied: - booted urara into the kernel login prompt - from depthcharge CLI tried accessing memory below 0x100000 - observed the exception. Change-Id: If78f1c5c54d3587fe83e25c79698b2e9e41d3309 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9668b440b35805e8ce442be62f67053cedcb205e Original-Change-Id: I187d02fa2ace08b9fb7a333c928e92c54465abc2 Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/246694 Reviewed-on: http://review.coreboot.org/9816 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21mips: Allow memory to be identity mapped in the TLBAndrew Bresticker
Introduce identity_map() function. It takes a memory range and identity maps it entirely in the TLB table, if possible. As a result the virtual and physical address ranges are the same. The function attempts to use as large of a page size as possible for each region in order to conserve TLB entries. BUG=chrome-os-partner:36258 BRANCH=none TEST=Build and boot on Pistachio with the rest of the patches applied. Change-Id: I4d781b04699e069a71c49a0c6ca15c7a6b42a468 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 234d32edfd201019b7a723316a79c932c62ce87e Original-Change-Id: If3e2392b19555cb6dbae8b5559c1b1e53a313637 Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/246693 Reviewed-on: http://review.coreboot.org/9815 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21broadwell: Clear USB3.0 PORTSC status bits in sleep_prepare.Todd Broch
Found that any non-USB3.0 devices connected to type-C ports (displayPort dongles) cause XHCI port to see connection which in turn leads us to enter USB compliance mode. That in turn causes the port to wake the system for a yet-to-be determined reason. Clearing the PORTSC status bits (actually just CSC) seems to remedy the wake. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=samus BUG=chrome-os-partner:35320 TEST=manual, 1. Plug hoho into type-C port on samus and remove 2. powerd_dbus_suspend Device stays asleep. Change-Id: Id3a291579ffca0152a7ef32e37ecae80ca08a82b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0be5cba4916681dceb0372e76d9643e6c7175db5 Original-Change-Id: I1396b9f8013dbbb31286c1d8958af592b3da7475 Original-Reviewed-on: https://chromium-review.googlesource.com/247410 Original-Commit-Queue: Todd Broch <tbroch@chromium.org> Original-Tested-by: Todd Broch <tbroch@chromium.org> Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/9814 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21broadwell: indent xhci codePatrick Georgi
Change-Id: I97920e7eb64c05034184f9a4e1c8f2dfa44d3fdd Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9813 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21broadwell: Skip pre-graphics delay in resume pathDuncan Laurie
If the board is configured with a pre-graphics delay it should be skipped in the resume path. BUG=chrome-os-partner:28234 BRANCH=broadwell TEST=measure resume time in dev mode to be same as normal mode Change-Id: I5a4ad5bba9e5316c89f7935d8811759b041429d9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: b44a7167532410fc44ca9df1c91c91aaf541ae49 Original-Change-Id: Ic9f2cda71d8a567f57e863409f0f3fb98ab68bcf Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/245116 Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/9812 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21broadwell: Implement Recovery ButtonRyan Lin
This patch fixes the use of the recovery button, and the value is stored in a SATA controller scratch register. BUG=chrome-os-partner:35241 BRANCH=none TEST=Use recovery button and run firmware_RecoveryButton Change-Id: Ia06f147c7e44d6c4eea2c2e4f502c233c956ee9b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 34c7ee922a9602b3448a72cd669fd68feeed1bba Original-Change-Id: I1667c7f188b0f87c4bc7caa82f9c977b2b4c0611 Original-Signed-off-by: Ryan Lin <ryan.lin@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/241772 Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/9811 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-21urara: add config of SPI bus and correct selection of winbond flashIonela Voinescu
Urara uses SPFI interface 1 and Winbond SPI NOR flash. BRANCH=none BUG=chrome-os-partner:31438 TEST=with the fix of the Winbond driver (next patch) the bootblock successfully probes the Windbond device on the FPGA board. Console log below: coreboot-4.0 bootblock Tue Nov 11 07:05:48 PST 2014 starting... SF: Detected W25Q16 with page size 1000, total 200000 Change-Id: Ia848eac5b4a94bf95297c928b5447463c90d89eb Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 38386715c52526edbe9ad356945849e21799fd94 Original-Change-Id: Ic27b60adc26bf244e7a15b5257e94df4b9d88249 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/229030 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9809 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21imgtec/pistachio: Add spi_crop_chunk()Patrick Georgi
This was added in upstream but not in Chromium OS where pistachio support was developed. Change-Id: I54f883776f19aa7bd357841731166e92d03145d8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9808 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-20gigabyte/ga-b75m-d3v: Add GIGABYTE GA-B75M-D3V mainboardDamien Zammit
Board boots to linux. VGA works with rom. Change-Id: I96b73a90c3d88672f0d238f4b735cd2f96ef99bd Signed-off-by: Damien Zammit <damien@zamaudio.com> Reviewed-on: http://review.coreboot.org/9803 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-20southbridge/intel/bd82x6x: Add LPC id 0x1e49 for B75 chipsetDamien Zammit
Change-Id: I3375c21d5d4aed30d5641629c44d6a5885efee11 Signed-off-by: Damien Zammit <damien@zamaudio.com> Reviewed-on: http://review.coreboot.org/9807 Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Tested-by: build bot (Jenkins)
2015-04-20mainboard/lenovo/t430s,t530,x230:enable usb3, set xhci overcurrent mappingNicolas Reinecke
Tested on T530, T430s. Verified with lspci dump. Change-Id: I45acadb0c55534a67f7ad3e7bd84f4482a4344d7 Signed-off-by: Nicolas Reinecke <nr@das-labor.org> Reviewed-on: http://review.coreboot.org/9451 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-20southbrige/intel/bd82x6x: add XHCI overcurrent map configNicolas Reinecke
Change-Id: I9a40e5a1028c7674e6dd54742e6646ba48ce7696 Signed-off-by: Nicolas Reinecke <nr@das-labor.org> Reviewed-on: http://review.coreboot.org/9449 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-20Kconfig: rename CONSOLE_SERIAL_UART to DRIVERS_UARTPatrick Georgi
Some upstreaming patches missed that, so follow up. Change-Id: I28665c97ac777d8b0b0f909e64b32681ed2b98f7 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9771 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-04-20purin: add ns16550 driverDaisuke Nojiri
BUG=chrome-os-partner:35807 BRANCH=broadcom-firmware TEST=booted b0 board. messages printed on console: coreboot-bcf5dc0-dirty bootblock Mon Feb 9 13:33:55 PST 2015 starting... Exception handlers installed. Change-Id: I271ead2f4fe48b809fd311acd5a27a675dce549e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ddff8fb170e775a121150fce065410d2925ad18c Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Ia6e82fa89547d61745c1473f723897dc3c1296ef Original-Reviewed-on: https://chromium-review.googlesource.com/251301 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9765 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-20console: copy ns16550 driver from u-bootDaisuke Nojiri
BUG=chrome-os-partner:35807 BRANCH=broadcom-firmware TEST=none Change-Id: I40623e92f290e5c584a451d99071316b6fc35431 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 505720f734da7a4cdfaff8b2531385644141ba83 Original-Change-Id: I655c7065047971ab05a13e90ab911d7464a37552 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/251300 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9764 Tested-by: build bot (Jenkins) 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-20vboot2 workbuf alignment is now 16 bytes, not 8Bill Richardson
BUG=chromium:452179 BRANCH=ToT CQ-DEPEND=CL:243362 TEST=manual emerge-veyron_pinky coreboot Original-Change-Id: Ibcbaea2990e5e06ea7cfaaa5412ef7c1477f5fcc Original-Signed-off-by: Bill Richardson <wfrichar@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/243380 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 8e5c18eeb21944bdcb064b4491c6781d16ef5608) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I26f6fb67655cb1dfbdcdc48530ef6bfeb1aa692a Reviewed-on: http://review.coreboot.org/9705 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-20rk3288: Disable ramstage compression by defaultJulius Werner
The ramstage is loaded from romstage, so the LZMA scratchpad buffer used to decompress it is part of the romstage BSS in SRAM. On RK3288, SRAM cannot be cached which makes the decompression so slow that it's faster to just load an uncompressed image from SPI. Disable ramstage compression on this SoC to account for that. [pg: implementation avoids restructuring all of Kconfig] BRANCH=None BUG=None TEST=Built for Pinky and Falco, confirmed that the former didn't have COMPRESS_RAMSTAGE in its .config and the latter still did. Measured a speed-up of about 35ms on Pinky. (For some weird reason, the decompression of the payload also takes way longer than on other platforms, although not as long as the ramstage. I have no explanation for that and can't really think of a good way to figure it out... maybe the Cortex-A12 is just terrible at some operation that LZMA uses a lot?) Change-Id: I9f67f7537696ec09496483b16b59a8b73f4cb11b Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/234192 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9792 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-19southbrige/intel/bd82x6x: XHCI replace magic valuesNicolas Reinecke
Change-Id: I62674ccfb836fb0b02ac562f678cdfa44be98ae3 Signed-off-by: Nicolas Reinecke <nr@das-labor.org> Reviewed-on: http://review.coreboot.org/9779 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-18riscv: use new-style CBFS header lookupPatrick Georgi
We recently restructured where the CBFS header is stored and how it is looked up, with less magic. The RISC-V port didn't get the memo, so have it follow the pack now. Change-Id: Ic27e3e7f9acd55027e357f2c4beddf960ea02c4d Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/9795 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-04-18vboot2: provide path for booting using alternative CBFS instancesVadim Bendebury
When CONFIG_MULTIPLE_CBFS_INSTANCES is enabled, the image is expected to have CBFS instances in rw-a and rw-b sections of the bootrom. This patch adds code which makes sure that CBFS header points at the proper bootrpom section as determined by vboot, and the RW stages load from that section. BRANCH=storm BUG=chrome-os-partner:34161, chromium:445938 TEST=with the rest of the patches in, STORM boots all the way into Linux login prompt. Original-Change-Id: I187e3d3e65d548c672fdf3b42419544d3bd11ea1 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237662 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 71ad0bb41b183374a84a5b9fb92c3afd813ceace) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Ia05cb713981c44da8cb379b72dfbe17fe1f6c5ff Reviewed-on: http://review.coreboot.org/9704 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18vboot2: Implement new vb2ex_hwcrypto APIJulius Werner
This patch aligns our verstage code to the new API addition in vboot2. The hardware crypto functions are stubbed out by default and just pretend that all algorithms are unsupported, causing vboot to fall back to the normal software hashing code. These weak symbols can be overridden by individual platform code to provide actual hardware crypto engine support. CQ-DEPEND=CL:236453 BRANCH=None BUG=chrome-os-partner:32987 TEST=Booted Pinky, confirmed vboot falls back to software crypto. Original-Change-Id: Idf6a38febd163aa2bff6e9a0e207213f01ca8324 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236435 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 9b5ee7f575f1aa3b0eb6ef78947ca93a4818f57b) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I6f0e19255a9bc5c5cd1767db76f1e47897ef0798 Reviewed-on: http://review.coreboot.org/9703 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18vboot: make vboot2_verify_firmware returnDaisuke Nojiri
this allows each board to decide what to do after firmware verification is done. some board needs to return back to the previous stage and let the previous stage kick off the verified stage. this also makes it more visible what is going to happen in the verstage since stage_exit now resides in main(). BUG=none BRANCH=tot TEST=booted cosmos dev board. booted blaze in normal and recovery mode. built for all current boards. Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I3cb466cedf2a9c2b0d48fc4b0f73f76d0714c0c7 Original-Reviewed-on: https://chromium-review.googlesource.com/232517 (cherry picked from commit 495704f36aa54ba12231d396376f01289d083f58) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: Ic20dfd3fa93849befc2b37012a5e0907fe83e8e2 Reviewed-on: http://review.coreboot.org/9702 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18ipq806x: initialize UART even when console is not enabledVadim Bendebury
The ipq806x UART is based on the same universal serial port which can be also configured as i2c or SPI. Configuring it is not a trivial task, so in case the kernel wants to use earlyprintk() the port needs to be configured by the firmware. Invoking uart_init() when the console is not enabled causes include file collisions, which would require changes to more than 100 files. Leaving this to another day, rearranging the ipq806x driver to be able to invoke UART initialization function even when serial console is not configured. Also add a check to avoid initialization if UART has been already set up. BRANCH=storm BUG=chrome-os-partner:35364 TEST=verified that storm console is still fully operational when enabled, and that the kernel boots fine to the serial console login prompt even if the firmware console is disabled. Change-Id: Ibbbab875449f2ac2f0d6c504c18faf0da8251ffa Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c512d6c1d0c0868137d1213ea84cd4bca58872db Original-Change-Id: I421acba3edf398d960b5058f15d1abb80ebc7660 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240516 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9794 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18ipq806x: uart: replace hardware accessorsVadim Bendebury
Originally ported QCA UART driver used hardware accessor macros where both address and data were represented by 32 bit integers. Coreboot uses macros where addresses are represented by pointers, this make the code more robust, as accidental swap between address and data does not go unnoticed. This patch converts ipq806x UART driver to use coreboot accessors. It relies on gcc void pointer arithmetic considering objects pointed at by void pointers to be one byte in size. Also replacing spaces with hard tabs where appropriate. BRANCH=storm BUG=chrome-os-partner:34790 TEST=new code still boots fine on Storm with console output present. Change-Id: I3ded9c338ff241bb1d839994f7296756aad8772d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 10616351704ebbcfcf25793ae974b256bc5bd6b0 Original-Change-Id: Ie15e09f9f3ea10a8566b6845219c2e09fed39218 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240514 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org> Reviewed-on: http://review.coreboot.org/9793 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18broadwell: Set C9/C10 vccminDuncan Laurie
This is done via a PCODE mailbox write. BUG=chrome-os-partner:37043 BRANCH=broadwell TEST=build and boot on samus Change-Id: I95e8fe3e28eec76d6b5b488a0c770c04f408700e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: b90bef7f708b1ce83f6e124f4b38ae51ec6b0597 Original-Change-Id: I95cd4c17db672a53ba05f85ba5fa7bc866af1543 Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/252862 Original-Reviewed-by: Alec Berg <alecaberg@chromium.org> Original-Reviewed-by: Shawn N <shawnn@chromium.org> (cherry picked from commit ab6b4bddf3365713aa40d194c2dbd3e59985f00d) Original-Reviewed-on: https://chromium-review.googlesource.com/252883 Reviewed-on: http://review.coreboot.org/9783 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18broadwell: Disable XHCI compliance mode entryDuncan Laurie
To avoid entries with Type-C alternate mode devices disable compliance mode entry. This needs to be set on both boot and resume. BUG=chrome-os-partner:35320 BRANCH=samus TEST=manual: 1) boot on samus with USB keyboard plugged in -> controller in D0 at boot 2) iotools mmio_read32 0xe12080ec == 0x18010c01 3) suspend and resume 4) iotools mmio_read32 0xe12080ec == 0x18010c01 5) remove USB keyboard -> controller in D3 6) iotools mmio_read32 0xe12080ec == 0xffffffff 7) plug in USB keyboard -> controller in D0 8) iotools mmio_read32 0xe12080ec == 0x18010c01 9) boot with no external USB devices -> controller in D3 at boot 10) iotools mmio_read32 0xe12080ec == 0xffffffff 11) plug in USB keyboard -> controller in D0 12) iotools mmio_read32 0xe12080ec == 0x18010c01 Change-Id: I4d566112b3c188bafdf9a4bbd92944c89500e3e8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: db8c8ab8ff25f6a39cd50dcc91b5ba9fd7d05059 Original-Change-Id: I8b68ba75e254a7e236c869f4470207eb5290053d Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/251361 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9782 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18panther: Fix pointer related errors in LAN codeFurquan Shaikh
BUG=None BRANCH=None TEST=Compiles and boots to "starting kernel" on panther Change-Id: Ic71aea6d8939a4fa3cd890e2048fff22ea25d186 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 4b5515bd00b76332748e4181cdf984c98a83993a Original-Change-Id: I2f890871ad7cddaf132a0fa59a93f05c51d0c00e Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/234982 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/9781 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18soc/intel/common: Add common reset codeLee Leahy
Move reset support into the Intel common branch. Prevent breaking of existing platforms by using a Kconfig value to select use of the common reset code. BRANCH=none BUG=None TEST=Build and run on Glados Change-Id: I5ba86ef585dde3ef4ecdcc198ab615b5c056d985 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 85d8a6d9628a66cc8d73176d460cd6c5bf6bd6b2 Original-Change-Id: I5048ccf3eb593d59301ad8e808c4e281b9a0aa98 Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/248301 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/9505 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-18soc/intel/common: Add function to protect MRC cacheDuncan Laurie
Add support for applying write protection to the MRC cache region in SPI flash. This is only enabled if there is write protect GPIO that is set, and the flash status register reports that the flash chip is currently write protected. Then it will call out to a SOC specific function that will enable write protection on the RW_MRC_CACHE region of flash. The implementation is not quite as clean as I would like because there is not a common flash protect interface across SOCs so instead it relies on a new Kconfig variable to be set that will indicate a SOC implements the function to protect a region of SPI flash. BUG=chrome-os-partner:28234 BRANCH=broadwell TEST=build and boot on samus 1) with either WPSW=0 or SRP0=0 the PRR is not applied 2) with both WPSW=1 and SRP0=1 the PRR is applied Change-Id: If5907b7ddf3f966c546ae32dc99aa815beb27587 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: a3e0e71dfd7339aab171a26b67aec465a3f332d6 Original-Change-Id: I94e54e4723b1dcdacbb6a05f047d0c0ebc7d8711 Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/241170 Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/9494 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-18broadwell: add ROM stage pre console init call backWenkai Du
Serial port on ITE 8772 SuperIO must be initialized before console_init is called. So the pre console init callback is added to let mainboard code do proper initialization. Change-Id: Iaa3e4b9c6e7ce77a7b9a6b9ecedd8ea54f3141dc Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 71ee2fd470e19fa4854f895678445b05c17761c1 Original-Change-Id: I594e6e4a72f65744deca5cad666eb3b227adeb24 Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com> Original-Reviewed-on: https://chromium-review.googlesource.com/227933 Original-Reviewed-by: Kenji Chen <kenji.chen@intel.com> Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Original-Reviewed-by: Rajmohan Mani <rajmohan.mani@intel.com> Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/9472 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-18kconfig: automatically include mainboardsStefan Reinauer
This change switches all mainboard vendors and mainboards to be autoincluded by Kconfig, rather than having to be mentioned explicitly. This means, vendor and mainboard directories are becoming more "drop in", e.g. be placed in the coreboot directory hierarchy without having to modify any higher level coreboot files. The long term plan is to enable out of tree mainboards / components to be built with a given coreboot version (given that the API did not change) Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Change-Id: Ib68ce1478a2e12562aeac6297128a21eb174d58a Reviewed-on: http://review.coreboot.org/9295 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-04-17cygnus: enable mmuDaisuke Nojiri
this is not only for speed but also preventing the cpu from crashing. the cpu is not happy when cache is cleaned without mmu turned on. BUG=chrome-os-partner:36691 BRANCH=broadcom-firmware TEST=boot purin to romstage. Change-Id: I2445dcc2729798c4fc56fa191cbc8471ef708d08 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9e35c925b75213e1d35bf191f22c39aaf1726eeb Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Icaf8c506df258edb99413949e6e3089a2b1a91af Original-Reviewed-on: https://chrome-internal-review.googlesource.com/199388 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/251306 Reviewed-on: http://review.coreboot.org/9768 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-17cygnus: configure memlayoutDaisuke Nojiri
we also pick no RETURN_FROM_VERSTAGE. BUG=none BRANCH=broadcom-firmware TEST=booted b0 board Change-Id: Iddd95f233a614187ae6b26f351a289c23f25742f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 243598925333982b40297adad878c461990d7d70 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I6ab96628cecb84e061777cc85d6d572823f6d63c Original-Reviewed-on: https://chromium-review.googlesource.com/251303 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9767 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-17cygnus: add timer functionsDaisuke Nojiri
this implements udelay. BUG=chrome-os-partner:36011 BRANCH=broadcom-firmware TEST=measured 10 sec of delay by stopwatch Change-Id: I833b71fac98a871bff71478221a55e1ca15c13df Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 137456e63931052f80247b72f98f958afdba8a27 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Ib5e33a19421eae900800fce94e9fd51bc2c665c4 Original-Reviewed-on: https://chromium-review.googlesource.com/251302 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9766 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-17urara: Define UART used for serial consoleDavid Hendricks
BUG=chrome-os-partner:31438 BRANCH=none TEST=built and booted on urara with follow-up patches Change-Id: I0ed55f372e095f6b63a47734c4d223a575f63904 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a013de7daa7bf9d8a5f59e292c2a01401568d738 Original-Change-Id: I8ddf9e65a8ac3d4b09032a741b725c78251f14c9 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/243212 Original-Reviewed-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Reviewed-on: http://review.coreboot.org/9778 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-17pistachio: Move console UART to a Kconfig variableDavid Hendricks
This allows us to define the serial console UART on a per-board basis. BUG=chrome-os-partner:31438 BRANCH=none TEST=built and booted on urara w/ follow-up patches Change-Id: Idbb0d39bf8855df4312f7499c60b8b92826fdd07 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ed4cfdd5ed6ccbf87a50f56d3e07f2f1a9d49464 Original-Change-Id: I3faeb92f026062cded390603a610e5b8f7c9bc12 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/243211 Original-Reviewed-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Reviewed-on: http://review.coreboot.org/9777 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
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-17flash: use two bytes of device ID to identify stmicro chipsDaisuke Nojiri
stmicro flash chips use 2 bytes as a device id: upper byte for memory type and lower byte for capacity. with this change, we will use all 2 bytes to identify a chip. BUG=none BRANCH=broadcom-firmware TEST=booted purin and verified n25q256a was identified. Change-Id: I8f382eddc4fa70d3deceb4f9d2e82026a7025629 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 12f70a1d4b7e1142afec9ce097c4a21b6225f66e Original-Change-Id: Id3378a77318fabb74ddb30f1a9549010636872ba Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chrome-internal-review.googlesource.com/199387 Original-Reviewed-by: Corneliu Doban <cdoban@broadcom.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Daisuke Nojiri <dnojiri@google.com> Original-Tested-by: Daisuke Nojiri <dnojiri@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/251305 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9774 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-17storm: Add STM flash supportVadim Bendebury
Compile in support for the STM flash devices. BRANCH=storm BUG=chrome-os-partner:33489 TEST=verified that both spansion and stm flash devices boot as expected. Change-Id: Ib616b2b52d29b20b4447c92115181a92c524ac39 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 34c0147b45551e9161e3f0e342a753907f27f9ae Original-Change-Id: I922afb91cc3ac5bf459d9746817d7677986b93cd Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/248993 Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9773 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-17qualcomm/ipq806x: add spi_crop_chunk()Patrick Georgi
That function requirement was added upstream but not in Chromium, so add an implementation. Change-Id: Ie384b315adb205586defa730b843c7c8e96f77fb Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9776 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17spi: allow inclusion of Micronix and STM drivers in bootblockVadim Bendebury
Bootblock does not allow using malloc, use statically allocated chip structures instead. BRANCH=storm BUG=chrome-os-partner:33489 TEST=both drivers compile when configured in, also booted whirlwind with an STM compatible SPI NOR flash. Change-Id: I154c33ce5fc278d594205d8b8e62a56edb4e177e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: eedbb959a595e0898e7a1dd551fc7c517a02f370 Original-Change-Id: I29b37107ac1d58a293f531f59ee76b3d8c4b3e7c Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/248992 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9772 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17armv7: set CBFS header to zeroVadim Bendebury
This is necessary to make sure that bootblock uses the default CBFS header (as it ought to) when multiple CBFS images support is enabled. BRANCH=storm BUG=chrome-os-partner:34161, chromium:445938 TEST=with the rest of the patches applied storm boots all the way inot the Linux prompt Change-Id: I5e029d95c5cb085794c7bf5f44513b2144661e38 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 75b2c2ef6c8287db7c3e5879cacfd5dcba4391ac Original-Change-Id: I5c352921b4c9b6a3294f4658d174e0842d2ee365 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237661 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9770 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17pistachio: add DDR2 initialization codeIonela Voinescu
This is the intialization code specific to the Winbond W972GG6JB-25 part using Synopsys DDR uMCTL and DDR Phy. This is DDR2 initialization code only (currently present on the bring up board). DDR3 initialization code will follow for boards having DDR3 memory. The programming procedure that is executed at power up to bring up the uMCTL, PHY and memories into a state where reads and writes to the memory can be performed is the following: 1. uPCTL (Universal DDR protocol controller) initialization The timining registers TOGCNT1U, TINIT, TOGCNT100N and TRSTH needed for driving the memory power-up sequence are programmed as a function of the internal timers clock frequency. Organization (memory chip specific) values are set (column/bank/row address width and number of ranks), together with other static values (latency, timing, power up configuration). All these values are static, provided by the datasheet, being determined by the memory type, size and frequency. 2. PHY initialization The PHY is programmed with datasheet provided values, specifying the initialization values for it to send to the external memory (timing parameters). Also, delay lines (DLL) and strength of drive pads are calibrated (based on external conditions: temperature, voltage, noise) and locked. After that, the PHY goes through a trainig process (also dependent on the current conditions at boot time) to establish precise timing configuration between the DDR clock and DQS (data strobe) and between DQS and DQ (data). 3. Memory power up 4. Switch from configuration state to access state. BUG=chrome-os-partner:31438, chrome-os-partner:37087 TEST=tested on Pistachio bring up board -> DDR initialized properly and ramstage executed correctly DDR2 is also tested during chip sort. Corner cases (performace of DDR in different conditions) will be tested after the chip reaches a stable state. BRANCH=none Change-Id: I0093dc175d064aad03052d5281679b008c1bf012 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3d0bacea0fd5bd3b12008b47e80de8398f447785 Original-Change-Id: I8437db6c84d77c4c51a3ee2b09cd3d14913c0d16 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/241424 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9769 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-17ryu: Add support for EVT board with ID BASE3(1,1)Furquan Shaikh
BUG=None BRANCH=None TEST=Compiles successfully Change-Id: Ic5c2dafd87641879074f98d023de0379c6e2bfba Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3ba476b8a436303603d7205d19f66f06c63118cd Original-Change-Id: I6a1404ff23d62100739919e8f569da2041038f01 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/252352 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/9763 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2015-04-17armv7: work around hang in bootblock startup codeDaisuke Nojiri
broadcom cygnus hangs if we clean caches by dcache_clean_invalidate_all at bootblock entry point. this change makes startup code call dcache_invalidate_all instead. other boards theoretically should not be affected as long as maskrom does not hand off execution to bootblock with dirty cache. BUG=chrome-os-partner:36648,chrome-os-partner:36691 BRANCH=broadcom-firmware TEST=boot cygnus b0 board, messages were printed on console: coreboot-688aae9-dirty bootblock Mon Feb 9 13:21:02 PST 2015 starting... Exception handlers installed. Change-Id: I05777ca525c97bb3d7cbb5ea7e872a602dcd5a19 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 59de5328df9d0502a3b3f7c624d3e86e038de50e Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I9b8850846b941e7e62712e90cc28ad14a68da393 Original-Reviewed-on: https://chromium-review.googlesource.com/251304 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9762 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17storm: handle dual purpose recovery buttonVadim Bendebury
Storm devices' recovery button is overloaded. Pressing it when the system is running is supposed to reset the device. To trigger recovery mode the button must be held pressed for at least 5 seconds after reset. Currently interpreting the recovery button state is the responsibility of the board (vboot gets a consolidated state, which is a combination of several conditions), so the simplest way to implement this feature is to make the board follow the recovery button state. In case the button is not pressed when it is first sampled, its state is saved immediately and no recovery request is reported. In case the button is pressed when it is first sampled, the board code keeps polling it up to 5 seconds and acts accordingly. BRANCH=storm BUG=chrome-os-partner:36059 TEST=tried starting a whirlwind with recovery button pressed for various durations, it entered recovery mode when the button was pressed longer than 5 seconds. Change-Id: Icb3250be7c2a76089c070acd68cb521d1399e245 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 45e7265bc760944f93dd98903d39d2b30aa96365 Original-Change-Id: Iab3609ebce3a74e3d0270775b83f3cf03a8837ca Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/251711 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/9761 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17ryu: add support for p4 boardsDavid Riley
BUG=none BRANCH=none TEST=P4 board boots and selects correct dts file Change-Id: Icdfdef9b82bd53413e45713f9ceef2e0c2be16a8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0674037b1f00845ffcd129cb54571f185b42af40 Original-Change-Id: If14e2586c4ef5b44af1754b3f06126b79473798b Original-Signed-off-by: David Riley <davidriley@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/250634 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9760 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17ipq806x: extend GSBI driver to support i2c on any GSBI blockSourabh Banerjee
The GSBI driver is extended to be able to program the CTRL reg for any given GSBI block. The NS and MD registers programming is made more readable by programming the M, N, D and other bits of the registers individually. Defined configure structs for each QUP block to be able to track the init status for each qup. Configured GPIO8 and GPIO9 for I2C fuction. BRANCH=chromeos-2013.04 BUG=chrome-os-partner:36722 TEST=Booted up storm P0.2, verified that the TPM on GSBI1 still works. Change-Id: I17906beedef5c80267cf114892080b121902210a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 07bc79211770decc1070c3a88874a4e452b8f5bc Original-Change-Id: I841d0d419f7339f5e5cb3385da98786eb18252ad Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org> Original-Reviewed-on: https://chromium-review.googlesource.com/250763 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9759 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17ipq806x: add LPASS clock control driverVadim Bendebury
Add a clock control driver to initialize the clock tree inside the low-power audio subsystem. Depthcharge builds up on this to enable audio function on storm. The clock is hardcoded for 48KHz frame rate, two 16 bit channels. BRANCH=storm BUG=chrome-os-partner:35247 TEST=with depthcharge patches applied and Using depthcharge CLI audio test program verified that the target generates sensible sounds audio 100 100 audio 1000 5000 Change-Id: I56513fc782657ade99b6e43b2d5d3141d27ecc4e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0d4f408408aa38b2f0ee19b83ed490de39074760 Original-Change-Id: If8ffc326698fcea17e05d536930d927ca553481f Original-Signed-off-by: Kenneth Westfield <kwestfie@codeaurora.org> Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/248830 Original-Reviewed-by: Dylan Reid <dgreid@chromium.org> Reviewed-on: http://review.coreboot.org/9758 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17rk3288: Add software I2C supportJulius Werner
This patch adds the necessary platform glue to allow the use of software-driven I2C bit banging on the RK3288. This is just a debugging feature that can be used to reproduce certain I2C failure cases. Also fix Makefile verstage linking for the feature and add some new rk3288 IOMUX macros as needed. BRANCH=None BUG=None TEST=Added "CONFIG_SOFTWARE_I2C=y" to configs/config.veyron_jerry, wrapped Jerry's bootblock and verstage in software_i2c_attach/detach() calls, confirmed that both PMIC and TPM could be driven correctly with software I2C driver. Tried out different combinations of software_i2c_wedge_ack() and software_i2c_wedge_read() on the PMIC and observed transfer results with the hardware controller after reboot... the worst that would happen is that the first register read-modify-write (DCDC_ILMAX) would fail to read, but all later transfers would be fine. Since that register is written twice (due to current BUCK1 ramp implementation) and is not terribily important anyway, I think we don't need to worry about wedging problems. Change-Id: Iba801ee61d30fb1fd3aef8300612c67fa50c441b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 24dfca9bab38a20c40ef0c2dd4c775b8d8f47487 Original-Change-Id: I96777300a57c85471bad20e23a455551e9970222 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/247890 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9757 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17ipq806x: Add support for mmu in bootblock.Deepa Dinamani
move mmu setup from RAM stage to boot block Enabling mmu earlier, helps speed up the boot time. BRANCH=storm BUG=chrome-os-partner:35024 TEST=Verified the mmu table dump matches the programmed values. Change-Id: I8f581538d5dfd0d78538c9fe50f689d54b740685 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: fb799a6d61f9c2f478434a71584d0edb94af4b59 Original-Change-Id: I110497875002a88add7eb4312a70c0de8c28bc4f Original-Signed-off-by: Deepa Dinamani <deepad@codeaurora.org> Original-Reviewed-on: https://chromium-review.googlesource.com/247120 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Trevor Bourget <tbourget@codeaurora.org> Reviewed-on: http://review.coreboot.org/9756 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17veyron_{brain,danger,rialto}: Enable eventloggingDavid Hendricks
This brings brain, danger, and rialto up to parity with other veyron platforms as far as eventlog functionality is concerned. BUG=chrome-os-partner:34436 BRANCH=none TEST="mosys eventlog list" shows events (tested on Brain) Change-Id: I186c5d18e5351c0eaf08ffecfd87506283c44b19 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1764bc53147718031231a6d125a4a1a96c4c6a8f Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: Ief09299965f6f21bc5a40cef31cde61344025c2a Original-Reviewed-on: https://chromium-review.googlesource.com/239979 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9755 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17veyron_{brain,danger,rialto}: Use common watchdog rebootDavid Hendricks
This applies a previous patch ("chromeos: Provide common watchdog reboot support") to some veyron platforms that were missing it. BUG=none BRANCH=none TEST=built and booted on Brain Change-Id: I3eb431a57367b8f885844e4353a78f77515f5195 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: b0c87dd4217917a35817c719efe43dd4ec442df0 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I2861939655a995d309847f64cecd974a740fae37 Original-Reviewed-on: https://chromium-review.googlesource.com/245633 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9754 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17rk3288: move reboot_from_watchdog() before rk808 settinghuang lin
we will use dvs to adjust the voltage in kernel, if device reset by watchdog in kernel, the dvs gpio may not reset, and we use the i2c to adjust rk808 voltage in coreboot, so it may failure. so we move the reboot_from_watchdog() before the rk808 setting. BUG=None TEST=Boot from speedy BRANCH=None Change-Id: I809c63153d49680d9c84462aafd7bae09106fa6e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 76efb4b0196eecc84664a4c5dce2221152a39c0a Original-Change-Id: I92b5c6413bbffe30566178de89df1f9683790982 Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/244289 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Original-Tested-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9752 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17purin: add purin under mainboardDaisuke Nojiri
this change covers bootblock and romstage. BUG=none BRANCH=tot TEST=ran emerge-purin coreboot Change-Id: Ifffb2e93189e8e85338de469432f3296e3e71791 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: cd479583404958f72461e9c1639f0288a00f228e Original-Change-Id: Iaee4a8c457e42386a4100a8121144b8cf5f21e8c Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/242853 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9751 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17broadcom/cygnus: add new SoC driverDaisuke Nojiri
This commit covers bootblock and romstage. BUG=none BRANCH=tot TEST=ran emerge-purin coreboot Change-Id: I88e2dffb9e46ba5b066190e844a6a7302adcfdc7 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: b3af6343a74263f086fe82c600559e8204e7dec0 Original-Change-Id: I447ed5f6ed181cfc9d5521b8c57e5fe0036a3f71 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/242854 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9750 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17chromeos: Provide common watchdog reboot supportJulius Werner
Many ChromeOS devices use a GPIO to reset the system, in order to guarantee that the TPM cannot be reset without also resetting the CPU. Often chipset/SoC hardware watchdogs trigger some kind of built-in CPU reset, bypassing this GPIO and thus leaving the TPM locked. These ChromeOS devices need to detect that condition in their bootblock and trigger a second (proper) reboot. This patch adds some code to generalize this previously mainboard-specific functionality and uses it on Veyron boards. It also provides some code to add the proper eventlog entry for a watchdog reset. Since the second reboot has to happen before firmware verification and the eventlog is usually only initialized afterwards, we provide the functionality to place a tombstone in a memlayout-defined location (which could be SRAM or some MMIO register that is preserved across reboots). [pg: Integrates 'mips: Temporarily work around build error caused by <arch/io.h> mismatch] BRANCH=veyron BUG=chrome-os-partner:35705 TEST=Run 'mem w 0xff800000 0x9' on a Jerry, watch how a "Hardware watchdog reset" event appears in the eventlog after the reboot. Change-Id: I0a33820b236c9328b2f9b20905b69cb934326f2a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: fffc484bb89f5129d62739dcb44d08d7f5b30b33 Original-Change-Id: I7ee1d02676e9159794d29e033d71c09fdf4620fd Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/242404 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Id: c919c72ddc9d2e1e18858c0bf49c0ce79f2bc506 Original-Change-Id: I509c842d3393bd810e89ebdf0dc745275c120c1d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/242504 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9749 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17veyron_*: Enable eventloggingDavid Hendricks
BUG=chrome-os-partner:34436 BRANCH=none TEST=Built and booted on pinky w/ depthcharge fmap patch, used mosys to verify that eventlog entries get populated: entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096" entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0" entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode" Change-Id: I74ba8b271328453c8b91f11e7858754a80806c31 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 197010f057f4835a30ed2e71f47ca51fc181afe4 Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I19cb884be5c3e00975599e96e0223e33d32e7c0d Original-Reviewed-on: https://chromium-review.googlesource.com/238830 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Julius Werner <jwerner@chromium.org> Original-Tested-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9644 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17chromeos: Move memlayout.h/symbols.h into common directoryJulius Werner
Turns out there are uses for memlayout regions not specific to vboot2. Rather than add yet another set of headers for a single region, let's make the vboot2 one common for chromeos. BRANCH=veyron BUG=chrome-os-partner:35705 TEST=Booted Jerry, compiled Blaze, Cosmos, Ryu and Storm. Change-Id: I228e0ffce1ccc792e7f5f5be6facaaca2650d818 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b Original-Change-Id: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/242630 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9748 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17storm: define location for storing CBFS header valueVadim Bendebury
The 4 byte offset value will be stored in SRAM and shared between different coreboot stages. BRANCH=storm BUG=chrome-os-partner:3416, chromium:445938 TEST=with the rest of the patches in, storm successfully boots into Linux login prompt Change-Id: Id8df75b0c679e274532660d55410291e59f3b520 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8f2f7cf6263f4c2db70b1c87ec67f6b0308059b3 Original-Change-Id: I1ebfada93e222992300cd695d04669988206d4b1 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/237660 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9744 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> 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-17pistachio: report UART register widthVadim Bendebury
Pistachio UART closely matches 8250, the only difference is that its register file is mapped to a 32 bit bus. Provide a function to report register with so that the Coreboot table entry gets correct value. 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: Icd72b115b4f339800d6c8b210a6617398232f806 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e1dc4156949b20efafbca2c19ff424436a400087 Original-Change-Id: Icafb014af338e05bbf1044b791683733685ffab3 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240028 Original-Reviewed-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9740 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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-17blaze: add new Hynix 2GB BCTNeil Chen
- Hynix H5TC4G63CFR-PBA, ramcode = 5 BUG=chrome-os-partner:34695 TEST=emerged coreboot, booted successfully into kernel. Change-Id: I53f9ebd9c38c645d1eb8b685d39e8beb55bd3c6a Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ee6fdcc28402fe324d08b713498488d863d1d30f Original-Change-Id: I829d4e1f992eadd445c313729eb4bca5ce602f53 Original-Reviewed-on: https://chromium-review.googlesource.com/245947 Original-Reviewed-by: Neil Chen <neilc%nvidia.com@gtempaccount.com> Original-Tested-by: Neil Chen <neilc%nvidia.com@gtempaccount.com> Original-Reviewed-by: Tom Warren <twarren@nvidia.com> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Commit-Queue: Neil Chen <neilc%nvidia.com@gtempaccount.com> Reviewed-on: http://review.coreboot.org/9736 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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: detect sdram size at runtimehuang lin
we use Kconfig define sdram size before, but there may use different sdram size in the same overlay, so we must detect sdram size at runtime now. If we use 4G byte sdram, we can use[0x00000000:0xff000000], since the [0xff000000:0xffffffff] is the register space. BUG=chrome-os-partner:35521 TEST=Boot from mighty BRANCH=None Change-Id: I7a167c268483743c3eaed8b71c7ec545a688270c Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ad4f27dd08c467888eee87e3d9c4ab3077751898 Original-Change-Id: Ib32aed50c9cae6db495ff3bab28266de91f3e73b Original-Signed-off-by: huang lin <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/243139 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9734 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17veyron: move setup_chromeos_gpios() prototype to board.hJulius Werner
I always had that TODO comment in there but I had already forgotten what I even meant by it. It's really just a simple cleanup... this function is (currently) veyron-specific and doesn't belong in common code. BRANCH=veyron BUG=None TEST=Booted Jerry. Change-Id: Iccd6130c90e67b8ee905e188857c99deda966f14 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d188398704575ad2fedc2a715e609521da2332b0 Original-Change-Id: I6ce701a15a6542a615d3d81f70aa71662567d4fa Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/241190 Reviewed-on: http://review.coreboot.org/9733 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-17arch/mips: Fix bug when performing cache operationsIonela Voinescu
Each type of cache might have different cache line size. Call the proper get_<*>cache_line function for each cache type. Fixes problem with get_L2cache_line which previously targeted L3 cache line in the config register, instead of L2 cache. TODO: add support for tertiary caches and have cache operations be called per CPU, not per architecture. BUG=chrome-os-partner:31438 TEST=tested on Pistachio bring up board; worked as expected; BRANCH=none Change-Id: I7de946cbd6bac716e99fe07cb0deb5aa76c84171 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 62e2803c6f2a3ad02dc88f50a4ae2ea00487e3f4 Original-Change-Id: I03071f24aacac1805cfd89e4f44b14ed1c1e984e Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/241853 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9731 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-17Add delay before reading GPIOs in gpio_base2_value()David Hendricks
This adds a 10us delay in between (re-)configuring and reading GPIOs in gpio_base2_value() to give the values stored some time to update. As far as I know this hasn't bitten us since the function was added, but adding a short delay here seems like the right thing to do. BUG=none BRANCH=none TEST=built and booted on Brain Change-Id: I869cf375680435ad87729f93d29a623bdf09dfbc Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2484900fc9ceba87220a293de8ef20c3b9b20cfd Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I79616a09d8d2ce4e416ffc94e35798dd25a6250d Original-Reviewed-on: https://chromium-review.googlesource.com/240854 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9725 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17urara: add board id information for urara boardIonela Voinescu
BUG=chrome-os-partner:31438 TEST=tested on Pistachio FPGA; works as expected. BRANCH=none Change-Id: If4493fcb37cf649fb0a56d594ac58556da3aa571 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0f6764396be1ab17875d9c73624cce48dc6790e6 Original-Change-Id: I925ebd6ea4fc30c1c1d91559f96eaad62d06aba8 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/239490 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9724 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17as3277: Fix month-off-by-one error for RTC driverJulius Werner
The AS3277 RTC code seems to closely follow the corresponding Linux driver. Unfortunately, while coreboot (and even other parts of Linux, like mktime()) directly follows the standard IBM PC RTC time representation (except for the BCD part), Linux' struct rtc_time decided to use 0-based (instead of 1-based) months instead. This patch removes the faulty month offset that was copied into our driver so that we will generate correct timestamps again. BRANCH=nyan BUG=chrome-os-partner:34108 TEST=firmware_EventLog (pre-release version) gets further than before (and then craps up on unrelated problems with suspend/resume events). Change-Id: Ica221a8bcfd7c1c6cd7ba382d760b586d511e3a3 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5b55c3f5bbecc776a71338256b910aecccac1e04 Original-Change-Id: I163fa4778ec534cd9e6f92a6b6dc55e9871a6a82 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/238122 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9723 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17bg4cd: define custom romstage entryDaisuke Nojiri
this change defines a custom romstage entry for bg4cd. the entry code stalls subcores, sets up the stack, and clears the bss before jumping to main. BUG=none BRANCH=tot TEST=built all current boards. booted cosmos p1 Change-Id: Idde43f94555bec7804a16928c58ce673956a39e5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7a35e12eb29b351cc0baaea24344f00d2ba905f6 Original-Change-Id: I9172e873a43847f3ea82cd1d9fd0841f0db83994 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/238022 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9722 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-07 19:15:18 +0000