The old parameters are wrong. K4B8G1646Q: rank = 2, row = 15 is right.
BUG=None
TEST=Boot from veyron
BRANCH=None
Change-Id: I41848c158f3ea028035cc8c0d969a4a449390a54
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 601ba06c636ff0f0779e6ef9357b53060a1ec19b
Original-Change-Id: I5bc6798890b3ba0f5134d048ae6bbf2bfd696676
Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/260483
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Paul Ma <magf@bitland.com.cn>
Reviewed-on: http://review.coreboot.org/9866
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch disables implicit make rules (like %.o: %.c) from our build
system, since we don't use them and they can cause unexpected results
when there's a mistake in the Makefiles.
BRANCH=None
BUG=chromium:466469
TEST=emerge-falco coreboot fails with only this patch and succeeds with
this and the $(src-to-obj) fix.
Change-Id: I7478adaddbbeaa2226fd941ffacfce2577ba59ba
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c2543f25f7db61f93be96784eca3f4f65e3ffaa0
Original-Change-Id: Ia6a91f040ad4ef556cf7912cd82a73173dfec8cb
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/259947
Original-Reviewed-by: Mike Frysinger <vapier@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9865
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
in depthcharge we will use "backlight" gpio which in lb_gpio table
to control backlight, we use lcd_bl before, but it will not meet
the backlight power sequence, so we change it to bl_en.
BUG=chrome-os-partner:37348
TEST=Boot from speedy, and backlight work well
BRANCH=None
Change-Id: I19e488c7d3f1fe5cb91f8a93fae6b848f58b36b7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cb594ce612e1cedeabced4531fbd954f3698da98
Original-Change-Id: Ib0dac7c48bce7d0b28ec287b32d8c5bad575893f
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/259900
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9864
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It has become necessary to be able to "factory reset" certain devices
on firmware request.
The vboot package has been modified to provide the necessary API, this
patch introduces a configuration option and uses the API when
enabled.
CQ-DEPEND=CL:259857
BRANCH=storm
BUG=chrome-os-partner:37219
TEST=with all the patches applied, on storm, holding the recovery
button at startup for 10 seconds, causes 'crossystem
wipeout_request' to report '1'.
Change-Id: I5e57bc05af3753f451626021ba30c7726badb7b4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f70e03e9a8c55bf3c45b075ae4fecfd25da4f446
Original-Change-Id: I4c2192da4fabfdef34d527e5b80d137634eb6987
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/259843
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9862
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The build system uses the $(src-to-obj) function in multiple places to
figure out the corresponding output object file for a certan source
file, most importantly when generating the rule to build it. Usually
this is pretty simple, but some odd cases are a little tricky... such as
the auto-generated intermediary C files containing an array definition
generated from an ASL file. These files have already been compiled per
stage, so they contain the stage as a suffix and reside in the build
directory (e.g. build/.../dsdt.ramstage.c).
The previous $(src-to-obj) implementation just blindly appends the stage
again and turns this into build/.../dsdt.ramstage.ramstage.o. This isn't
very useful, so to avoid confusion this patch makes it strip additional
stage suffixes for those intermediary files.
This also fixes a bug with the ASL postprocessor, which didn't take this
double suffix into account: it added build/.../dsdt.ramstage.o to
ramstage-objs which should've been build/.../dsdt.ramstage.ramstage.o.
This only worked by accident because make compiled the file with its
implicit %.o: %.c rule instead.
BRANCH=none
BUG=chromium:466469
TEST=emerge-falco coreboot with the new make 4.1. Also build Falco and
Veyron_Jerry with make -r -R to make sure there are no other accidental
uses of implicit rules in our build system.
Change-Id: I4aeaa60add1ef4215cb6c0b222c3886395c7a045
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d9ea2e082eca1045409ea1f403082c97dedc70d8
Original-Change-Id: I951edbc9f653321a9084543a65009c6e9154d819
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/259950
Original-Reviewed-by: Mike Frysinger <vapier@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9861
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
DDR init blob version string can be found at a fixed location in
memory once the blob is loaded. Maximum size of the string is 48
bytes.
The RPM RW version is defined in a 32 bit version stored at yet
another fixed address once RPM RW has started.
BRANCH=storm
BUG=chrome-os-partner:30623
TEST=ran this command on the booted system:
localhost ~ # egrep '(DDR|RPM)' /sys/firmware/log
Loaded DDR init blob version 99ce41d@-AAABANAZA
DDR initialized
Starting RPM
Started RPM version 1.0.128
localhost ~ #
Change-Id: If3c3c8368845b978605ccfda7e09c21ae2e5ab9a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 328c9c57cf93110bc0fdd267134d72e386d70834
Original-Change-Id: If411f6f7bca53ea20390b7e851cb3d120681eade
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/256738
Original-Reviewed-by: Varadarajan Narayanan <varada@qti.qualcomm.com>
Reviewed-on: http://review.coreboot.org/9860
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
SP5 whirlwind is the earliest hardware version equipped with the LED
ring.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=none
Change-Id: I4c90a75911350bafd8ccb8755b2491e9447f285b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3dfee90457295668a2b60d5a1e913caf52557877
Original-Change-Id: I6bffdcc47fe9c72796e3bac44d211f907538ef0b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/258270
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9857
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Concerto board does not have the means of detecting the identity of
the device it is controlling. But it is very beneficial to be able to
use the same firmware image on Concerto boards running different
devices.
The suggested solution is to keep the device identity as a string in a
raw CBFS file called 'board_id'.
With this patch coreboot maintains a table of possible board name
strings and their matching board IDs.
BRANCH=none
BUG=chrome-os-partner:37593
TEST=verified that without the board id file addition the default
Board ID of zero is used. Adding the file as follows:
echo -n 'concerto' > /tmp/bid
cbfstool /build/urara/firmware/image.serial.bin add -f /tmp/bid \
-t raw -n 'board_id'
results in firmware reporting board ID setting of 1.
board_id: failed to locate CBFS file board_id
board_id: name urara, ID 0
Change-Id: I5a02192740dc94b1ea8090092cc325fe0ac42aa6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f41f9b07f155f0c719c36e0cd93081205624557e
Original-Change-Id: I8341782005b101be78f5c9a6b375c8f73179c1ad
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/257170
Reviewed-on: http://review.coreboot.org/9856
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cygnus' serial driver wasn't part of the tree when the
big transformation was done, so follow up.
Change-Id: Ic1a53bea9bcaf1e568b50b9c2ad7782e65e36328
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9852
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>
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>
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>
jinkun.hong