| Age | Commit message (Collapse) | Author |
|---|
|
BUG=chrome-os-partner:36011
BRANCH=broadcom-firmware
TEST=measured 10 seconds in depthcharge:
Starting depthcharge on purin...
dpch: time 10
9 8 7 6 5 4 3 2 1 0
Change-Id: I0bcb01c255b19518bb8440111ac81f056c07ed69
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f5993bd400dd5d38e62d07bc8ce3513175e0d518
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chrome-internal-review.googlesource.com/200569
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-Change-Id: Id83aae29cec6320d897e0b231d023a9ee885903e
Original-Reviewed-on: https://chromium-review.googlesource.com/256415
Reviewed-on: http://review.coreboot.org/9850
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The driver uses the MSPI controller to read/write to/from SPI flash
BUG=chrome-os-partner:35811
BRANCH=boradcom-firmware
TEST=bootblock loads and executes verstage
Change-Id: I34c7882170e4f89bee1b6001563c09b16dfea8ca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8c3b156019df429e9d12728224ed4eec8436f415
Original-Signed-off-by: Corneliu Doban <cdoban@broadcom.com>
Original-Reviewed-on: https://chrome-internal-review.googlesource.com/199776
Original-Reviewed-by: Scott Branden <sbranden@broadcom.com>
Original-Tested-by: Corneliu Doban <cdoban@broadcom.com>
Original-Commit-Queue: Corneliu Doban <cdoban@broadcom.com>
Original-Change-Id: Ice798ec76011ee47e13174b4c5534b0d0bc8b4ad
Original-Reviewed-on: https://chromium-review.googlesource.com/256414
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: http://review.coreboot.org/9849
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This add hynix-2GB SDRAM(H5TC4G63AFR-PBA), whose timing is the same as
H5TC4G63CFR-PBA, to veyron boards.
BUG=None
BRANCH=veyron
TEST=build on mighty and boot on mighty board with ram-id reworked
Change-Id: I3ae5e65e60e18414cf4de6fbcc5bed736b1492de
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b22029f9b05ebb9a775266a7e3aae38b50c1883a
Original-Change-Id: If17fb002f2816990e1706833b37ac6be345e540b
Original-Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/256307
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: http://review.coreboot.org/9848
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The existing DDR setup configures the burst length to be 8. However
the DDR controller can only be given sufficient data per clock to
satisfy a burst length of 4, hence the bursts are only half
populated. This results in a 50% drop of efficiency.
Fix this by configuring the burst size to 4.
BUG=chrome-os-partner:31438, chrome-os-partner:37087
TEST=tested on Pistachio bring up board -> DDR initialized
properly and ramstage executed correctly
BRANCH=none
Change-Id: I761ba73a04688841ca39a370b7cb99b6e0b22964
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0e590ab8387dbbccef45dc84d1eeafee2abc9e2e
Original-Change-Id: I585385b65e330624ad70292349e50c6695eeeb6c
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/256305
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9847
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The DDR On Die Termination was incorrectly configured at 75R,
where as the data sheet suggests for DDR2-800 it should be
set to 50R.
Correct this by adjusting the ODT setting in the EMR register.
BUG=chrome-os-partner:31438, chrome-os-partner:37087
TEST=tested on Pistachio bring up board -> DDR initialized
properly and ramstage executed correctly
BRANCH=none
Change-Id: I2f0242c422b1cb3d1f64ce3dd17b62fef5e7e155
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ac081ac59c0dc3d16a7b540cd379fb870b6cfe40
Original-Change-Id: If7951812033c4e88f4be3c143fb49526eddba142
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/256304
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9846
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The proper way to initialize DDR2 is for the PHY to
automatically establish precise timing configuration
through the training process. The alternative (used
initially for testing) is no longer needed.
This change determined the removal of some local
variables as they ended up being used in one location only.
BUG=chrome-os-partner:31438, chrome-os-partner:37087
TEST=tested on Pistachio bring up board -> DDR initialized
properly and ramstage executed correctly.
BRANCH=none
Change-Id: I31e9a8975d176a04061f9c84fe06cce850bb53b9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e28f3ef9a22436bb0fa949df6f5a5c6a67002dfd
Original-Change-Id: Ifb9c1bb6e0b71af72340381bd2349850d1b4af2d
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/256303
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9845
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BUG=chrome-os-partner:35807
BRANCH=broadcom-firmware
TEST=tested input and output by the cli in depthcharge
Change-Id: Icd517a366a3fe5bdcf9e9aeb4284d7e4378ee3f2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 02c3b6c82d9d71beb19a0879591c754fa7685362
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chrome-internal-review.googlesource.com/200568
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Scott Branden <sbranden@broadcom.com>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
Original-Tested-by: Daisuke Nojiri <dnojiri@google.com>
Original-Change-Id: I97144fc6f19969b8cf3872939c9c74efaef3604b
Original-Reviewed-on: https://chromium-review.googlesource.com/256413
Reviewed-on: http://review.coreboot.org/9844
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The WG (write gate) bit in C0_EBase allows the upper two bits of
the exception base address to be set to something other than 2'b10,
thus allowing it to be relocated out of the traditional KSEG{0,1}
range. Since we're not using the segmentation features introduced
by EVA to relocate the unmapped segments, the exception vectors
should remain in KSEG0. Don't set the WG bit so that the upper
two bits of the exception base (2'b00, because of the identity
mapping) are ignored and we execute the exception vectors out of
KSEG0.
BUG=chrome-os-partner:36258
BRANCH=none
TEST=Build and boot on Pistachio.
Change-Id: Ie8b4eb6e41a328e7055736c9e3f6ff5ec83b9e13
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d5b002f5ae71c7729e467d4fe3fd8db187e15dea
Original-Change-Id: Id8b930db1e7a68f52dd61be4dfa9edaee2bebf7d
Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/246697
Original-Reviewed-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9822
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add helper macros to convert between physical addresses and KSEG{0,1}
addresses. Also get rid of the virt_to_{bus,phys}_offset variables
as these are fixed values.
As nobody seems to be using getpagesize() on MIPS, no need to keep
virtual.c.
BUG=chrome-os-partner:36258
BRANCH=none
TEST=Build and boot on Pistachio.
Change-Id: Ia26c8eae53eb8f860747a6b321363776841d1a94
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c422b02e9a2a20d130913b1cfb835ad74c39ddca
Original-Change-Id: I9476cd225a08534830c700cba7bf9d3ef871757e
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/247190
Reviewed-on: http://review.coreboot.org/9821
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
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>
|
|
Use bus_to_virt() to convert the physical address of the DMA
coherent region to an address in KSEG1 which is suitable for
device memory accesses.
BUG=chrome-os-partner:36258
BRANCH=none
TEST=Build and boot on Pistachio.
Change-Id: If382feda66f6d829f8b3548ab263cf603cab2e9b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a88a175f6d6db81d3154fb5dd31a44363ab94653
Original-Change-Id: I9ad6435495df2c71d8f81a782f1c3dfcfd4aeb28
Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/246696
Original-Reviewed-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
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/9818
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Now that coreboot has identity-mapped DRAM, use base address 0 (KUSEG)
instead of 0x80000000 (KSEG0).
BUG=chrome-os-partner:36258
BRANCH=none
TEST=Build and boot on Pistachio.
Change-Id: I39845250a1b8cea6e5360efce16770751ffce13d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c1cbc1d7f6873c0be30d4206a2030f3b468acf24
Original-Change-Id: I76d98664f1bca73ae8acc9f545e68de9173c3cab
Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/246695
Original-Reviewed-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
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/9817
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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)
|
|
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>
|
|
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>
|
|
Change-Id: Ibc7fe38ae11e9d477f85fdcf760b27abc6013f94
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/9791
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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)
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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)
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The following changes were made:
- order commands and options definitions alphabetically
- do not report errors at cbfs_image_from_file() call sites - the
error is reported by the function itself
- remove the unused parameter in cbfs_create_empty_entry() prototype
BRANCH=storm
BUG=none
TEST=compiled cbfstool, built a storm image, observed that the image
still boots
Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8
Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237560
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9746
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The previous patch introduced a bug where the new added case statement
was missing the break. There was no problem testing, because an
unrelated parameter structure field was being modified as a result.
BRANCH=storm
BUG=none
TEST=compiles and runs
Change-Id: Iaeb328048f61ffd57057ebce47f2ac8e00fc5aac
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 27ecc130569e4252e4627052f617130a2017c645
Original-Change-Id: Ib3e6c4c2b5c37588c612b8ab2672f6845c1b4ecb
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/239598
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
The new command allows to create a file where the original CBFS image
is duplicated at a different offset.
The required options of the new command are -D, the offset where the
copy CBFS header is placed, and -s, the size of the new CBFS copy.
When a CBFS is copied, the bootblock area of the source CBFS is
ignored, as well as empty and deleted files in the source CBFS. The
size of the destination CBFS is calculated as the rombase size of the
source CBFS less the bootblock size.
The copy instance can be created in the image only above the original,
which rules out the use of this new command for x86 images. If
necessary, this limitation could be addressed later.
As with other cbfstool commands, unless explicitly specified the
lowest CBFS instance in the image is considered the source. If
necessary, the user can specify the source CBFS using the -H option.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=run multiple cbfstool commands on a storm image:
$ cd /tmp
$ cp /build/storm/firmware/image.serial.bin storm.bin
$ cbfstool storm.bin print
storm.bin: 8192 kB, bootblocksize 34472, romsize 458752, offset 0x8700
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x8700 raw 416
ddr.mbn 0x8900 raw 25836
rpm.mbn 0xee40 raw 78576
tz.mbn 0x22180 raw 85360
fallback/verstage 0x36f40 stage 41620
fallback/romstage 0x41240 stage 19556
fallback/ramstage 0x45f00 stage 25579
config 0x4c340 raw 2878
fallback/payload 0x4cec0 payload 64811
u-boot.dtb 0x5cc40 (unknown) 2993
(empty) 0x5d840 null 75608
$ cbfstool storm.bin copy -D 0x420000
E: You need to specify -s/--size.
$ cbfstool storm.bin copy -D 0x420000 -s 0x70000
$ cbfstool storm.bin print
W: Multiple (2) CBFS headers found, using the first one.
storm.bin: 8192 kB, bootblocksize 34472, romsize 458752, offset 0x8700
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x8700 raw 416
ddr.mbn 0x8900 raw 25836
rpm.mbn 0xee40 raw 78576
tz.mbn 0x22180 raw 85360
fallback/verstage 0x36f40 stage 41620
fallback/romstage 0x41240 stage 19556
fallback/ramstage 0x45f00 stage 25579
config 0x4c340 raw 2878
fallback/payload 0x4cec0 payload 64811
u-boot.dtb 0x5cc40 (unknown) 2993
(empty) 0x5d840 null 75608
cbfstool storm.bin print -H 0x420000
storm.bin: 8192 kB, bootblocksize 0, romsize 4784128, offset 0x420040
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x420040 raw 416
ddr.mbn 0x420240 raw 25836
rpm.mbn 0x426780 raw 78576
tz.mbn 0x439ac0 raw 85360
fallback/verstage 0x44e880 stage 41620
fallback/romstage 0x458b80 stage 19556
fallback/ramstage 0x45d840 stage 25579
config 0x463c80 raw 2878
fallback/payload 0x464800 payload 64811
u-boot.dtb 0x474580 (unknown) 2993
(empty) 0x475180 null 110168
$ cbfstool storm.bin remove -n config -H 0x420000
$ cbfstool storm.bin copy -H 0x420000 -D 0x620000 -s 0x70000
$ cbfstool storm.bin print -H 0x620000
storm.bin: 8192 kB, bootblocksize 0, romsize 6881280, offset 0x620040
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x620040 raw 416
ddr.mbn 0x620240 raw 25836
rpm.mbn 0x626780 raw 78576
tz.mbn 0x639ac0 raw 85360
fallback/verstage 0x64e880 stage 41620
fallback/romstage 0x658b80 stage 19556
fallback/ramstage 0x65d840 stage 25579
fallback/payload 0x663c80 payload 64811
u-boot.dtb 0x673a00 (unknown) 2993
(empty) 0x674600 null 113112
$ cbfstool /build/storm/firmware/image.serial.bin extract -n fallback/payload -f payload1
[..]
$ cbfstool storm.bin extract -H 0x620000 -n fallback/payload -f payload2
[..]
$ diff payload1 payload2
Change-Id: Ieb9205848aec361bb870de0d284dff06c597564f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b8d3c1b09a47ca24d2d2effc6de0e89d1b0a8903
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Change-Id: I227e607ccf7a9a8e2a1f3c6bbc506b8d29a35b1b
Original-Reviewed-on: https://chromium-review.googlesource.com/237561
Reviewed-on: http://review.coreboot.org/9742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There potentially could be multiple CBFS instances present in the
firmware image. cbfstool should be able to operate on any of them, not
just the first one present.
To accomplish that, allow all CBFS commands to accept the -H parameter
(which specifies the exact CBFS header location in the image).
If this parameter is specified, the image is not searched for the CBFS
header, only the specified location is checked for validity, If the
location is valid, it is considered to be the CBFS header, if not -
the tool exits with an error status.
Note, that default behavior of the tool does not change.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=run the following experiments:
- examined an image with three CBFS instances, was able to print all
of them.
- built a rambi coreboot image and tried the following (cbfstool output abbreviated):
$ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print
coreboot.rom: 8192 kB, bootblocksize 2448, romsize 8388608, offset 0x700000
alignment: 64 bytes, architecture: x86
Name Offset Type Size
cmos_layout.bin 0x700000 cmos_layout 1164
...
(empty) 0x7ec600 null 77848
$ \od -tx4 -Ax /build/rambi/firmware/coreboot.rom | tail -2
7ffff0 fff67de9 000000ff fff6dfe9 fffff650
800000
$ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print -H 0x7ff650
coreboot.rom: 8192 kB, bootblocksize 2448, romsize 8388608, offset 0x700000
alignment: 64 bytes, architecture: x86
Name Offset Type Size
cmos_layout.bin 0x700000 cmos_layout 1164
...
(empty) 0x7ec600 null 77848
$ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print -H 0x7ff654
E: /build/rambi/firmware/coreboot.rom does not have CBFS master header.
E: Could not load ROM image '/build/rambi/firmware/coreboot.rom'.
$
Change-Id: I64cbdc79096f3c7a113762b641305542af7bbd60
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 86b88222df6eed25bb176d653305e2e57e18b73a
Original-Change-Id: I486092e222c96c65868ae7d41a9e8976ffcc93c4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237485
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/9741
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
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>
|
|
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>
|
|
I doubt anybody will ask for the configuration and request that
0 bytes be returned, but AFAICS that's legal, so let's support it.
Should have no effect on ChipIdea since it knows not to send more
data than requested by the host.
BRANCH=none
BUG=none
TEST=none
Change-Id: Ibfe57b593015fa5e0381c45ff9e39c3f912b4d4d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 45555e929d9d07dbb58ecfd18333f26375a0e3d7
Original-Change-Id: I7432772a1812c6f52c2b1688ee4c6f67d02ccf28
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/258064
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9790
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Only set internal variables when there's no risk of breaking things.
BRANCH=none
BUG=none
TEST=none
Change-Id: I8a8b63f60bdb70fad38130ce38eef81fe3725aa2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7119829096b444b790937b116fb782bcb5da70cd
Original-Change-Id: If698b11a7ff7688def310d8574fcfa7a40f703c1
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/258063
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9789
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
First handle IN packets, then OUT packets and finally SETUP packets.
This makes OS X happy. It isn't implemented as the data sheet recommends
but it avoids implementing a state machine and should always produce
observable effects identical to that of the stateful solution.
BRANCH=none
BUG=none
TEST=`fastboot getvar version` on OSX works
Change-Id: Ic7b27387771d6a7794fba12fc822fccc48770ea8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f0e59547519d50b1d34f6abdc6132330125f94f3
Original-Change-Id: Iada1cff011f11e7d5cb1a1b34896ab590f488ec7
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/258062
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9788
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Mark EP0 non-stall explicitly. Shouldn't be necessary, but
won't hurt either.
BRANCH=none
BUG=none
TEST=none
Change-Id: I7ecd16a2affe064918d93436aedfa07bd9a1cf56
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a0fc237b33444fc30dc5b62e4f1afc3188f2cf43
Original-Change-Id: I1aa8742eebc4de733317600e35627631ebaf4724
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/258061
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9787
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Trivial copy & paste error, likely with no visible effect so far.
BRANCH=none
BUG=none
TEST=none
Change-Id: Ieaf5e770ab7a8474e407012d2c11a15c46ab357d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 90f8971500c95456ae70c6f4219b1ff9aff1c0b0
Original-Change-Id: I973573efd0effc9e0173d2b259ce577b6de38de4
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/258060
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9786
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
SET_CONFIGURATION(0) stops operation and is moves the
device to addressed mode.
BRANCH=none
BUG=none
TEST=USB device mode still works
Change-Id: I964d90ba8440b6f428896acc9fe63e1114390da6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 402bc907222d07765b3438967edf26cc1a79d775
Original-Change-Id: Iebad024e1ed2e344dba73b73a9b385a4ac4cb450
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/250791
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9785
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some IN transfers must be terminated by an empty packet
because otherwise the host wouldn't know.
The zlp() function determines this requirement in
accordance to USB rules: If the transfer's size is aligned
to the maximum packet size, and the host expects a larger
transfer, add the empty packet as a hint.
BRANCH=none
BUG=none
TEST=USB device mode still works
Change-Id: Ia69f3d017f72a3a0e0b21bac72fe97be184c7daa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd0e946e4948a74a9ed15a5eed6ce827b7672a56
Original-Change-Id: I8153cc5bd2ff1c88e383c1dbcddaf1bf72f9194c
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/250790
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9784
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add a framework for USB device mode controllers
and a driver for the ChipIdea controller which
is part of the tegra platform.
TODO:
- fix USB detach/attach
- implement zero length packet handling properly
BUG=chrome-os-partner:35861
TEST=none
BRANCH=none
Change-Id: I8defeea78b5a3bdbf9c1b1222c2702eaf3256b81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 542332291880c4026a05a960ceb91d37891ee018
Original-Change-Id: Ib4068d201dd63ebeda80157bd3130f3059919cdd
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/243272
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8756
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This check verifies that all mainboard vendors
and boards have a Kconfig.name entry.
Change-Id: I3ed3bfa0d3f78e55a8d54918f5f3f29f51068e48
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9707
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
