Timestamps should not be forced on by a subset of chipsets.
However, they are a requirement on Chrome OS platforms, so
have CONFIG_CHROMEOS select it.
Change-Id: I408c6b17aa8721a3abec69020084174e414a8940
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/10357
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
SMM_TSEG now implies SMM_MODULES and SMM_MODULES can't be used without SMM_TSEG
Remove some newly dead code while on it.
Change-Id: I2e1818245170b1e0abbd853bedf856cec83b92f2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10355
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Follow up for commit b890a12, some contributions brought
back a number of FSF addresses, so get rid of them again.
Change-Id: I0ac0c957738ce512deb0ed82b2219ef90d96d46b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10322
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This code is not specific to ChromeOS and is useful outside of it.
Like with small modifications it can be used to disable TPM altogether.
Change-Id: I8c6baf0a1f7c67141f30101a132ea039b0d09819
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10269
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of being pointer based use the region infrastrucutre.
Additionally, this removes the need for arch-specific compilation
paths. The users of the new API can use the region APIs to memory
map or read the region provided by the new fmap API.
Change-Id: Ie36e9ff9cb554234ec394b921f029eeed6845aee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9170
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The boot_device is a region_device that represents the
device from which coreboot retrieves and boots its stages.
The existing cbfs implementations use the boot_device as
the intermediary for accessing the CBFS region. Also,
there's currently only support for a read-only view of
the boot_device. i.e. one cannot write to the boot_device
using this view. However, a writable boot_device could
be added in the future.
Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10216
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Making large changes in pieces is leading to a little bloat.
Bump up the romstage size temporarily so that jenkins will be
happy.
Change-Id: I6f9facb4ca488cf41741a3ed6d0ed7f66d4778b3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10220
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
All boards now use per-device ACPI. This patch finishes migration
by removing transitional kludges.
Change-Id: Ie4577f89bf3bb17b310b7b0a84b2c54e404b1606
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7372
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
SLIT and SRAT are created this way only on amdk8 and amdfam10.
This saves the need of having a lot of dummies.
Change-Id: I76d042702209cd6d11ee78ac22cf9fe9d30d0ca5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7052
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
DYNAMIC_CBMEM is only selected a couple of times but never declared
or read. Remove it.
Change-Id: I5016dac2c935d3f261001e9f388a8989540e93ae
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10255
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
CPU_HAS_BOOTBLOCK_INIT is only declared once and selected elsewhere
(with no overlap), and never read. Remove it.
Change-Id: I3f294b0724a87876a7e2f274e6933fe10321a69d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10253
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Rename Kconfig options for secmon and spintable to be prefixed with
ARM64_ instead of ARCH_, which seems to be the standard throughout the
rest of coreboot (e.g. ARM_LPAE or X86_BOOTBLOCK_SIMPLE). I think this
provides a clearer separation between generic options that are selected
by the architecture (e.g. a hypothetical ARCH_HAS_FEATURE_X similar to
some of the MAINBOARD_HAS_... we have) and options that only make sense
in the context of a single architecture.
Change-Id: I38c2efab833f252adbb7b61ef0af60ab25b768b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5067e47bc03f04ad2dba044f022716e0fc62bb9e
Original-Change-Id: I1b2038acc0d054716a3c580ce97ea8e9a45abfa2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/270783
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10242
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Remove the secmon Kconfig guard from Makefiles that add to the secmon
class since they are redundant (the class is simply not used when
compiling without secmon) to improve readability/ease-of-use.
[pg: taken out of the patch linked below]
Change-Id: I2f0ad8a923ca32fcade748ac8ee50c23cf9bafb9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5067e47bc03f04ad2dba044f022716e0fc62bb9e
Original-Change-Id: I1b2038acc0d054716a3c580ce97ea8e9a45abfa2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/270783
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10241
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The struct rockchip_spi_media type is no longer used;
nor is initialize_rockchip_spi_cbfs_media(). Remove them.
Change-Id: I2c24be249e0cd89e2dd328e05cdd24a178fe37e8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10214
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
I messed up the conditionals on loading the reference code.
The bug used || instead of && causing 2 reference codes to
be loaded.
Change-Id: I29a046bf0e8dc29a9efdb636ebfd04e11eb73f82
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10185
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
So that's more precise than "anything non-pre-ram".
Change-Id: I21db536a5ea704c4b087f57d0b761dd3fdf43e3e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10128
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
To avoid having to dig up the constraints again, document
the memory layout right in memlayout.ld.
Change-Id: I298cc880ae462f5b197ab2f64beb2f0e0d9f5a7d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10039
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There's now room for other repositories under 3rdparty.
Change-Id: I51b02d8bf46b5b9f3f8a59341090346dca7fa355
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10109
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To move 3rdparty to 3rdparty/blobs (ie. below itself
from git's broken perspective), we need to work around
it - since some git implementations don't like the direct
approach.
Change-Id: I1fc84bbb37e7c8c91ab14703d609a739b5ca073c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10108
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
bootblock et al were listed twice, which shouldn't happen.
Change-Id: I3e6077d70e064ebe74bd4e5e3156f87d548c2fcb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10097
Tested-by: build bot (Jenkins)
The vboot mechanism will be implemented within the program loader
subsystem to make it transparent to mainboards and chipsets.
Change-Id: Icd0bdcba06cdc30591f9b25068b3fa3a112e58fb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10094
Tested-by: build bot (Jenkins)
Fix compiler error's due to type mismatch. This is broken since commit
bde6d309 (x86: Change MMIO addr in readN(addr)/writeN(addr, val) to
pointer).
TEST=Build with CONFIG_DEBUG_SPI_FLASH=y and booted on Minnowboard Max
Change-Id: Id3d448e219716135897f381a73d416ff34036118
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10075
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Several of the intel platforms define the region reserved
for PCI memory resources in a location where it overlaps
with the MMIO (MCFG) region.
Using the memory map from mohon_peak as an example:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000a0000-00000000000fffff: RESERVED
3. 0000000000100000-000000007fbcffff: RAM
4. 000000007fbd0000-000000007fbfffff: CONFIGURATION TABLES
5. 000000007fc00000-000000007fdfffff: RESERVED
6. 00000000e0000000-00000000efffffff: RESERVED
7. 00000000fee00000-00000000fee00fff: RESERVED
8. 0000000100000000-000000017fffffff: RAM
The ACPI table describing the space set aside for PCI memory
(not to be confused with the MMIO config space) is defined
as the region from BMBOUND (the top of DRAM below 4GB) to
a hardcoded value of 0xfebfffff. That region would overlap
the MMIO region at 0xe0000000-0xefffffff. For rangeley
the upper bound of the PCI memory space should be set
to 0xe0000000 - 1.
The MCFG regions for several of the affected chipsets are:
rangeley 0xe0000000-0xefffffff
baytrail 0xe0000000-0xefffffff
haswell 0xf0000000-0xf3ffffff
sandybridge 0xf8000000-0xfbffffff
TEST = intel/mohonpeak and intel/bayleybay.
Change-Id: Ic188a4f575494f04930dea4d0aaaeaad95df9f90
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/9972
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
So don't try to use it elsewhere.
Change-Id: Ia600ba654bde36d3ea8a0f3185afae00fe50bfe9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10030
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
That's a Haswell exclusive, used nowhere else, but confusing
when hunting for the monotonic timer used on that SoC.
Change-Id: I60ec523e54e5af0d2a418bcb9145de452a3a4ea9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10034
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
SPI flash drivers need it.
Change-Id: I63d79472d70d75f7907e7620755c228d5a4918e1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10033
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Builds with CHROMEOS fail due to missing includes.
Change-Id: I8c88bca8f8cc3247d3f3311777f794c4fdfee3c1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10029
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ChromeOS machines employing vboot verfication require
different combinations of support:
1. When vboot verification starts.
2. Is the vboot code a separate stage or program?
3. If a separate stage, does the that vboot program (verstage) return
to the stage that loaded the verstage?
For the above, #1 is dependent on when to load/run vboot logic which
is orthogonal to #2. However, #3 is dependent on #2. The logic
to act on the combinations follows in subsequent patches.
Change-Id: I39ef7a7c2858e7de43aa99c38121e85a57f1f2f6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10024
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In the true spirit of separating components more strictly
and allowing to add new components to coreboot without touching
existing code, move Intel common code selection to the soc
Kconfig and out of src/soc/intel/common/Makefile.inc
Change-Id: I0a70656bb9f4550b6088e9f45e68b5106c0eb9af
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10031
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The memory layout isn't very clear here, since there are two
regions (bootblock and "SRAM") that are actually the same.
So when increasing the bootblock's size, we also need to move
the romstage around.
Change-Id: Ib158a4ef96b7c1dd1132b6e8bd47a0eb9c3951d9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10035
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This change switches all SOC vendors and southbridges
to be autoincluded by Makefile.inc, rather than having to be
mentioned explicitly in soc/Makefile.inc or in
soc/<vendor>/Makefile.inc.
This means, vendor and SOC directories are now "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 components to be
built with a given coreboot version (given that the API did not
change).
Change-Id: Iede26fe184b09c53cec23a545d04953701cbc41d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9799
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Consolidate the FspNotify calls into the FSP driver directory,
using BOOT_STATE_INIT_ENTRY to set up the call times.
Change-Id: I184ab234ebb9dcdeb8eece1537c12d03f227c25e
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/9780
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Remove Kconfig files that are no longer used:
src/vencorcode/Kconfig
src/soc/marvell/Kconfig
- Fix the drivers/sil/Kconfig to point to drivers/sil/3114 which had
the same code.
- Make sure all Kconfig files have linefeeds at the end. This can cause
problems, although it wasn't in this case.
- Include cpu/intel/model_65x/Kconfig which was not being included.
Change-Id: Ia57a1e0433e302fa9be557525dc966cae57059c9
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/9998
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There's no need to have the VBOOT2_VERIFY_FIRMWARE
distinction because it's the only game in town.
Change-Id: I82aab665934c27829e1a04115bf499ae527a91aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9958
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If verified boot is enabled, merge verstage into bootblock. This also
requires custom bootblock code to actually call into verstage.
[pg: modified to match upstream]
BUG=chrome-os-partner:32631
BRANCH=ToT
TEST=booted on cosmos development board.
Change-Id: I53251aac966ee15da24232c23fefa636de8b253b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2b8ada263017b46afa755b5acb759574184dba06
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Ia0e1236357aa32bf553fb8cc98f3a8d29de17f45
Original-Reviewed-on: https://chromium-review.googlesource.com/229795
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10008
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The value of SMM_TSEG_SIZE was equal to SMM_RESERVED_SIZE. This caused
the install_permanent_handler() function to fail. Changed the value to
0x800000, which is already used as default in smm_region_size() in case
SMM_TSEG_SIZE is 0.
Change-Id: I4ff3568aefd4729a98c1777a2cae2a4715afbc2f
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/9961
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Prepare for FSP 1.1 integration by moving the FSP to a FSP 1.0 specific
directory. See follow-on patches for sharing of common code.
Change-Id: Ic58cb4074c65b91d119909132a012876d7ee7b74
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/9970
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since CHROMEOS_VBNV_* are selected by mainboards, they
may be active without CHROMEOS being selected. In this
case, they should be a no-op.
Change-Id: I3b84e2a919ffaa809d713e72e5e4df7a7575e6b9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9954
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Many chipsets were using a stage cache for reference code
or when using a relocatable ramstage. Provide a common
API for the chipsets to use while reducing code duplication.
Change-Id: Ia36efa169fe6bd8a3dbe07bf57a9729c7edbdd46
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8625
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
RTC drivers now select RTC, so that code which depends on them
can implement fallback behavior for systems that lack the
hardware or driver.
Change-Id: I0f5a15d643b0c45c511f1151a98e071b4155fb5a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9953
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable auto entry and auto exit self-refresh.
Configure entry idle time to 16x long count sequences.
Where a long count sequence is 1024 cycles.
The idle entry configuration is based on 32x of the DLL lock time (512 cycles).
A conservative setting to help minimize self-refresh enter/exit thrashing.
BUG=chrome-os-partner:36456
BRANCH=broadcom-firmware
TEST=When enable configuration CYGNUS_SDRAM_TEST_DDR,
print on console:
sdram initialization is completed.
test ddr start from 0x60000000 to 0x80000000
...
test ddr end: fail=0
Translation table is @ 02004000
Mapping address range [0x00000000:0x00000000) as uncached
Change-Id: Ibad220429fd52ead2933db03bec1a555f9385e53
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3768f82ca268fb854f8c4753916518a1efdf887d
Original-Reviewed-on: https://chrome-internal-review.googlesource.com/212125
Original-Reviewed-by: Scott Branden <sbranden@broadcom.com>
Original-Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
Original-Tested-by: Daisuke Nojiri <dnojiri@google.com>
Original-Signed-off-by: Icarus Chau <ichau@broadcom.com>
Original-Change-Id: Icac1e12745d048b32e1804a546f6b49c8b5953c0
Original-Reviewed-on: https://chromium-review.googlesource.com/265862
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Trybot-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: http://review.coreboot.org/9930
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When the PHY is compiled to run in HDR(half data rate),
then either NOBUB or FXDAT must be set to 1 in the DDR
system general configuration register. NOBUB specifies
that reads should be returned to the controller with
no bubbles and this is felt preferable to the fixed
latency option (FXDAT). Both of them inrease read
latency.
BRANCH=none
BUG=chrome-os-partner:37087
TEST=tested on Pistachio bring up board -> DDR initialized
properly and ramstage executed correctly
Change-Id: Iee530ba5bb0acc889fba447dc2ee5cb965ba6926
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e7944b4af45d9504098f8b4af44d0f5abafea42c
Original-Change-Id: I9ced76bd670fc4efa7441d57e15f97871b046ae9
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/264341
Original-Reviewed-by: James Hartley <james.hartley@imgtec.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9917
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The DRAM configuration register, apart from holding the
device density and width also has a rudimentary address
mapping scheme. Currently this is set to the default
Bank/Row/Column. This means that the memory is segmented
into 8 chunks, each with a page detector. If all the
activity is in one section of memory then the other 7
page detectors could be idle.
Changing this to Row/Bank/Column would concatenate the
page detectors meaning that all 8 could be used by a
single initiator. This may not gain anything in a
synthetic bandwidth test but could yield extra performance
in a real world application or benchmark.
BRANCH=none
BUG=chrome-os-partner:37087
TEST=tested on Pistachio bring up board -> DDR initialized
properly; all access to DDR works properly in
Coreboot ramstage, Depthcharge and Linux;
no performance tests were ran so far.
Change-Id: I22d86bf3b679ed63884d7436d9d7bbaf1726f640
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e852ed42afcdc2062a0037144bab723227cb1f1f
Original-Change-Id: If90b0cf5ce86db5e3d6d362873d22d4269e3a49f
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/264340
Original-Reviewed-by: James Hartley <james.hartley@imgtec.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9916
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
secimage is a tool which adds a header and signature to the binary
first loaded by the soc. ARM core frequency is set to 1 Ghz.
BUG=chrome-os-partner:36421
BRANCH=broadcom-firmware
TEST=booted b0 board
Change-Id: Ia08600d45c47ee4f08d253980036916e44b0044a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36284d1b242c26b0b5aac2894f7ed1790da1ef15
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chrome-internal-review.googlesource.com/197155
Original-Reviewed-by: Scott Branden <sbranden@broadcom.com>
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: Iaddd24006b368c8f37e075cb51e151e985029f3b
Original-Reviewed-on: https://chromium-review.googlesource.com/264417
Reviewed-on: http://review.coreboot.org/9914
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Upstream coreboot regularly runs Coverity over the code base. Turns out
that's a good idea since it's really easy to screw yourself over with a
missing parenthesis and some unfortunately deceptive line breaking.
This patch fixes a bug in LPDDR3 initialization due to an incorrect
operator precedence assumption ( ?: does not bind stronger than | ). In
effect, instead of setting MR11[1:0] to 0b11 or 0b00 based on ODT, we're
unconditionally setting MR0[1:0] to 0b11. Thankfully, MR0[1:0] seems to
contain read-only bits so this might have not been a problem when ODT is
off (which is currently true for all LPDDR boards).
Also adding a redundant LPDDR_OP() around the 0 to make the intent
clearer and changing 3 and 0 to 0x3 and 0x0 to make it more obvious that
these are bit masks (right?).
BRANCH=veyron
BUG=None
TEST=Running reboot loop on a Minnie, looks good so far...
Change-Id: I06464aaa57e693b1973846a5771162244f7a1c57
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan
Original-Commit-Id: 5bd9eba39fb7b0f940fead963bbc1878b031b2cb
Original-Change-Id: I701ce059472078b5de09a45dd31f54b65a51e641
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/264135
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Jinkun Hong <jinkun.hong@rock-chips.com>
Original-Tested-by: Jinkun Hong <jinkun.hong@rock-chips.com>
Reviewed-on: http://review.coreboot.org/9911
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BOARD_ID functionality is not what requires the GPIO lib,
but it is the mainboard specific implementations that do.
The option essentially says whether the SoC provides
<soc/gpio.h> (with the interface required by the common
GPIO code). Right now, x86 and Samsung's Exynos SOCs
don't have support for this interface.
So this should be selected by the SOC, not by
BOARD_ID_SUPPORT.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
BUG=none
BRANCH=none
TEST=emerge-storm coreboot still successfully compiled an image
Change-Id: I0ce2bd7ce023f22791d31a6245833b61135504b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0dd4dea521372194eedf11b077d95fd3b15ad9f7
Original-Change-Id: I3dea6c2fb42a23fcb9d384c3bbfa7fc8e217be2d
Original-Reviewed-on: https://chromium-review.googlesource.com/262743
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9899
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
CBFS cache use is very close to the limit, does not allow to read much
more from CBFS.
BRANCH=none
BUG=chrome-os-partner:36586
TEST=the upcoming patches do not fail due to the lack of room in CBFS
cache any more
Change-Id: I8e784891e59ca284b3bd82557c2114a2f450d8a3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c94d55c8042db81c1eb0c10d5f24883e00cdc19a
Original-Change-Id: Ic09dbd5b4a0e165ccef396ff8a9e21b12c49b705
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/263268
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9894
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code to calculate the RK3288 SPI controller's internal clock divisor
is wrong: it assumes that the divisor register was an "n-1" divisor when
it actually isn't (due to some misleading kernel code that was copied in
here). This means that all SPI clocks are currently running lower than
expected.
This patch fixes the calculation and changes all callers such that the
effective speeds stay the same.
BRANCH=veyron
BUG=chrome-os-partner:38352
TEST=Booted Jerry with and without the patch, dumping the divisor for
flash and EC clocks. Made sure it stays the same.
Change-Id: I2336e2b81c2384b5076175fcf32717a3ab2ba0c5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1fd5b990f937019a9bee7bd693c91d6e2fca1adb
Original-Change-Id: I094d57a5933c8b849f5c66194e6cc2952ab68b90
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262269
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9887
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>
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>
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>
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 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>
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>
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>
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>
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>
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>
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 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>
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>
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>
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>
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>
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 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>
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>
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>
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>
Many ChromeOS devices use a GPIO to reset the system, in order to
guarantee that the TPM cannot be reset without also resetting the CPU.
Often chipset/SoC hardware watchdogs trigger some kind of built-in
CPU reset, bypassing this GPIO and thus leaving the TPM locked. These
ChromeOS devices need to detect that condition in their bootblock and
trigger a second (proper) reboot.
This patch adds some code to generalize this previously
mainboard-specific functionality and uses it on Veyron boards. It also
provides some code to add the proper eventlog entry for a watchdog
reset. Since the second reboot has to happen before firmware
verification and the eventlog is usually only initialized afterwards, we
provide the functionality to place a tombstone in a memlayout-defined
location (which could be SRAM or some MMIO register that is preserved
across reboots).
[pg: Integrates
'mips: Temporarily work around build error caused by <arch/io.h> mismatch]
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Run 'mem w 0xff800000 0x9' on a Jerry, watch how a "Hardware
watchdog reset" event appears in the eventlog after the reboot.
Change-Id: I0a33820b236c9328b2f9b20905b69cb934326f2a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fffc484bb89f5129d62739dcb44d08d7f5b30b33
Original-Change-Id: I7ee1d02676e9159794d29e033d71c09fdf4620fd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242404
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: c919c72ddc9d2e1e18858c0bf49c0ce79f2bc506
Original-Change-Id: I509c842d3393bd810e89ebdf0dc745275c120c1d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242504
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9749
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Turns out there are uses for memlayout regions not specific to vboot2.
Rather than add yet another set of headers for a single region, let's
make the vboot2 one common for chromeos.
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Booted Jerry, compiled Blaze, Cosmos, Ryu and Storm.
Change-Id: I228e0ffce1ccc792e7f5f5be6facaaca2650d818
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b
Original-Change-Id: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242630
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9748
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The 4 byte offset value will be stored in SRAM and shared between
different coreboot stages.
BRANCH=storm
BUG=chrome-os-partner:3416, chromium:445938
TEST=with the rest of the patches in, storm successfully boots into
Linux login prompt
Change-Id: Id8df75b0c679e274532660d55410291e59f3b520
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8f2f7cf6263f4c2db70b1c87ec67f6b0308059b3
Original-Change-Id: I1ebfada93e222992300cd695d04669988206d4b1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237660
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Pistachio UART closely matches 8250, the only difference is that its
register file is mapped to a 32 bit bus.
Provide a function to report register with so that the Coreboot table
entry gets correct value.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the rest of the patches integrated depthcharge console messages
show up when running on the FPGA board
Change-Id: Icd72b115b4f339800d6c8b210a6617398232f806
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e1dc4156949b20efafbca2c19ff424436a400087
Original-Change-Id: Icafb014af338e05bbf1044b791683733685ffab3
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240028
Original-Reviewed-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9740
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some SOCs (like pistachio, for instance) provide an 8250 compatible
UART, which has the same register layout, but mapped to a bus of a
different width.
Instead of adding a new driver for these controllers, it is better to
have coreboot report UART register width to libpayload, and have it
adjust the offsets accordingly when accessing the UART.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the rest of the patches integrated depthcharge console messages
show up when running on the FPGA board
Change-Id: I30b742146069450941164afb04641b967a214d6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2c30845f269ec6ae1d53ddc5cda0b4320008fa42
Original-Change-Id: Ia0a37cd5f24a1ee4d0334f8a7e3da5df0069cec4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240027
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9738
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
we use Kconfig define sdram size before, but there may use
different sdram size in the same overlay, so we must detect
sdram size at runtime now. If we use 4G byte sdram, we can
use[0x00000000:0xff000000], since the [0xff000000:0xffffffff]
is the register space.
BUG=chrome-os-partner:35521
TEST=Boot from mighty
BRANCH=None
Change-Id: I7a167c268483743c3eaed8b71c7ec545a688270c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ad4f27dd08c467888eee87e3d9c4ab3077751898
Original-Change-Id: Ib32aed50c9cae6db495ff3bab28266de91f3e73b
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/243139
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9734
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We've traditionally tucked the framebuffer at the end of memory (above
CBMEM) on ARM and declared it reserved through coreboot's resource
allocator. This causes depthcharge to mark this area as reserved in the
kernel's device tree, which may be necessary to avoid display corruption
on handoff but also wastes space that the OS could use instead.
Since rk3288 boards now have proper display shutdown code in
depthcharge, keeping the framebuffer memory reserved across the handoff
(and thus throughout the lifetime of the system) should no longer be
necessary. For now let's just switch the rk3288 implementation to define
it through memlayout instead, which is not communicated through the
coreboot tables and will get treated as normal memory by depthcharge.
Note that this causes it to get wiped in developer/recovery mode, which
should not be a problem because that is done in response to VbInit()
(long before any images are drawn) and 0 is the default value for a
corebootfb anyway (a black pixel).
Eventually, we might want to think about adding more memory types to
coreboot's resource system (e.g. "reserved until kernel handoff", or
something specifically for the frame buffer) to model this situation
better, and maybe merge it with memlayout somehow.
CQ-DEPEND=CL:239470
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes
than before (curiously not 0x80000 bytes, I guess there's some alignment
waste in the kernel somewhere). Made sure the memory map output from
coreboot looks as expected, there's no visible display corruption in
developer/recovery mode and the 'cbmem' utility still works.
Change-Id: I12b7bfc1b7525f5a08cb7c64f0ff1b174df252d4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2
Original-Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240819
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9732
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change defines a custom romstage entry for bg4cd. the entry code
stalls subcores, sets up the stack, and clears the bss before jumping to main.
BUG=none
BRANCH=tot
TEST=built all current boards. booted cosmos p1
Change-Id: Idde43f94555bec7804a16928c58ce673956a39e5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a35e12eb29b351cc0baaea24344f00d2ba905f6
Original-Change-Id: I9172e873a43847f3ea82cd1d9fd0841f0db83994
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/238022
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9722
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current display init code causes Brain to crash when trying
to allocate resources. This just avoids doing display init if a
config variable is set. Once code has been implemented to properly
setup different types of displays we can get rid of this hack.
BUG=none
BRANCH=none
TEST=built and booted (to depthcharge) on Brain, compiled for
pinky with FEATURES=noclean and ensured config variable is 0
Change-Id: I9a7266c6bff5b7a6eb05b2b21fb65797bee392d6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 804632ca67eaaf4174ca597d83b8923cb9abd1b7
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I04c9e8181c58fa0608fd20776fa8c4798a023474
Original-Reviewed-on: https://chromium-review.googlesource.com/235922
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9720
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch activates the chip driver for Winbond SPI flash (which,
incidentally, looks 99.9% the same as the Gigadevice driver but still
requires some extra 500+ bytes of object code... there's definitely room
for improvement here). Shuffle around rk3288 memlayout to make a little
more room in the bootblock.
BRANCH=veyron
BUG=chrome-os-partner:34176
TEST=Booted Pinky. Checked bootblock and verstage memsz of final binary
and noticed that both only have less than 500 bytes left against their
memlayout boundary. The next piece of code we add will cause some
serious headaches...
Change-Id: I97ea6ac334104e4219e310afc557c164b2ff19d9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8769e5a34ad3cd417132646fbb58ff51c29fb640
Original-Change-Id: Id2f1204c30aa28251cf85cb80d7ca44947388dba
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236977
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9719
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
we use the delay 200ms to meet the edp power timing request before,
it waste time, so we use the HPD function to detect the edp panel now.
In previous version, the hardware may not support the edp HPD function,
so in the code it will spend 200ms to detect hpd single, if it don't get
the hpd single, it will contiue the edp initialization process, to compatible
all of the hardware version.
BUG=chrome-os-partner:35623
TEST=Boot from Mighty, and display normal
BRANCH=None
Change-Id: I82c6a80e37fa42eef3521e6ebbf190d7e80fcece
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 7a5343eb9af12cae9a15284217762a91ae24bac6
Original-Change-Id: I21c0ef6ce4643e90a192d8b86659264895b5fda9
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/242792
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9659
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Our use of the bucks may exceed their default maximum inductor current.
Just set it to the highest possible value for every buck we configure to
avoid problems... the kernel can later fine-tune the values further if
needed. (Also some slight grammar updates while I'm in there.)
BRANCH=veyron
TEST=Build and Boot on Jerry
BUG=None
Change-Id: If8258cf4feefe191604365405bff1f20c8ab8746
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 065a163bb902b8c96d05bfef6ed4885aa20f31cc
Original-Change-Id: I3801cabeb93d7bf7ecc02db0e69d4932c9394db9
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242785
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: http://review.coreboot.org/9655
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
tMRD request 10nCK in LPDDR3, we set the DDR_PCTL_TMRD BIT0~BIT2 to generate
this signal, but the max value we can set is 7, so the standard can not be met.
So, now we send the Mode Register Set command manually, and hence we can add
the delay manually.
BUG=chrome-os-partner:34608
TEST=loop reboot
BRANCH=veyron
Change-Id: Id974ab935c2df6ea35dcdd240378ffc68de0204d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: b60a4de6ff3ad3720c2c06ed7de03ed942360e6c
Original-Change-Id: I0d29ea9cd82ef018e835ae53090a47d0299ef61d
Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/242176
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9654
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We want a reset signal to last 200us. The length of a reset signal is
represented by BIT0~BIT16 in DDR_PUBL_PTR2. When DDR memory runs at
667MHz, the calculated value for the reset signal is 0x20850, which is
bigger than the maximum value that can be described with 17 bits
(0x1ffff). As a result, the memory controller only sees 0x850, which
generates a 3.5us reset cycle instead, which violates the standard and
negatively impacts memory stability.
So instead, we now set it to the maximum value (0x1ffff) to prevent this
overflow, resulting in a reset signal of 196us for 667MHz DDR memory.
BUG=chrome-os-partner:34875
TEST=loop reboot
BRANCH=veyron
Change-Id: Ia01f8a0414b49fa3ecf4d543cfa1822e29ee4cc4
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 767a4a3cb8dff47cb15064d335b78ffa5815914d
Original-Change-Id: I9b410e1605c87f12a5ca96ead12f8527ca4f417f
Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/242175
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9653
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch finds the RPM image in the CBFS, loads it as defined by the
MBN header and signals to the RPM processor where the image is
located and waits for confirmation of the RPM starting.
The interactions with the RPM processor are copied as is from the
vendor provided sample code.
Debug messages added to help identify problems with loading the blobs,
should they ever happen.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=ramstage reports both TZBSP and RPM starting.
Change-Id: I81e86684f9d1b614f2059ee82c6561f9484605de
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bbf2eda04a6e72b4f7b780f493b5a1cea0abfeb7
Original-Change-Id: Ic10af0744574c0eca9b5ab7567808c1b8d7fe0c2
Original-Signed-off-by: Vikas Das <vdas@codeaurora.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236661
Original-Reviewed-by: Varadarajan Narayanan <varada@qti.qualcomm.com>
Reviewed-on: http://review.coreboot.org/9692
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use the apps processor watchdog reset to do a hard reset.
The watchdog reset drives the RESETOUT on the chip.
Modify register address definitions to be able to use pointers and
pointer arithmetics.
BRANCH=storm
BUG=chrome-os-partner:34334
TEST=the chip resets and the control returns to start of SBL.
Change-Id: Ib5772ab152b27058fde1be9de2d2ac26bfe00ca4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d50413cb614ef05ada93be1252fe5ef617a94d91
Original-Change-Id: I9b249d057b473429335587f7241ca462b4a6a8b7
Original-Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236141
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Reviewed-on: http://review.coreboot.org/9691
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Read the TZBSP blob from CBFS and run it. A side effect of the blob
execution is switching the processor into User mode.
Starting TZBSP requires processor running in Supervisor mode, TZBSP
code is compiled for ARM. Coreboot is executing in System mode and is
compiled for Thumb. An assembler wrapper switches the execution mode
and interfaces between Thumb and ARM modes.
BUG=chrome-os-partner:34161
BRANCH=Storm
TEST=manual
With the preceeding patches the system successfully loads to
depthcharge in recovery mode.
Change-Id: I812b5cef95ba5562a005e005162d6391e502ecf8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7065cf3d17964a1d9038ec8906b469a08a79c6e2
Original-Change-Id: Ib14dbcbcbe489b595f4247d489d50f76a0e65948
Original-Signed-off-by: Varadarajan Narayanan <varada@qti.qualcomm.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229026
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9690
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Booting depthcharge requires much larger CBFS cache, but by the time
depthcharge is being booted DRAM is already initialized. Use different
memory spaces for CBFS cache before and after DRAM is available.
Also, make sure that CBMEM uses memory below CBFS cache in DRAM.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=with this change on Storm ramstage finds and boots depthcharge in
recovery mode
Change-Id: Icd1bbf4bcc5f9d92b2653b5a8891409105a25353
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e1e0b029b7fb09b84784373150cc4ce9eea7b3f5
Original-Change-Id: I33fd97806b2db6fab2adc44b67e5f54258642967
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234543
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9688
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Read two blobs from CBFS: cdt.mbn (memory configuration descriptor)
and ddr.mbn (actual memory initialization code).
Pointer to CDT which starts right above the MBN header is passed to
the memory initialization routine. Zero return value means memory
initialization succeeded.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=with upcoming patches memory initialization succeeds.
Change-Id: Ia0903dc4446c03f7f0dc3f4cc3a34e90a8064afc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1d79dadd7d47dd6d01e031bc77810c9e85dd854b
Original-Change-Id: Ib5a7e4fe0eb24a7bd090ec3553c57cd1b7e41512
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234644
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9686
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change sets up the list of source files for vboot2's
verstage without enabling it.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=not much testing yet, just successful compilation.
Change-Id: I4052c20795459bf0e057c0f0952226ea4a8c89f1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 48847ab8acfbe4b33d61d3d012c72c025cd8f364
Original-Change-Id: I1d7944e681f8a4b113a90ac028a0faba4423be89
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234643
Reviewed-on: http://review.coreboot.org/9684
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With introduction of uber-sbl SRAM usage pattern is changing, this
introduces the new memory layout.
This patch overlays DDR initialization code with uber-sbl, as uber-sbl
goes out of scope as soon as bootblock starts.
A 4K block at offset 0x3f000 added in the comments, this is a shared
structure used by different QCA modules.
This suggested layout is not final, but will allow to move closer to
the production image.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=with other patches applied Storm boots all the way to rombase and
initializes DRAM.
Change-Id: I46af81b39b09935aa7fffdabda223e7e64c7a446
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a20c0570361038c0ae406dcb1f4bc657eea120f6
Original-Change-Id: I927f6ffc524fc8f0effd7b91d3f5d1e8d6be1530
Original-Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229023
Reviewed-on: http://review.coreboot.org/9683
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
LPAE (large physical address extension) is not available on this SOC
core, do not enable it.
[pg: we already had this one, but somehow LPAE slipped in again]
BUG=chrome-os-partner:27784
TEST=coreboot still comes up on AP148
Change-Id: Iaa80022c611f7377d8f4100487d32654150836d8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e6e12c39efd54e4fcbd444134bf30e211948a71b
Original-Change-Id: I9e9ad1aeaf613f04987c0c306a574085042d0e7b
Original-Signed-off-by: Deepa Dinamani <deepad@codeaurora.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198023
Original-Reviewed-by: deepa dinamani <deepad@quicinc.com>
Reviewed-on: http://review.coreboot.org/9682
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- These should be 64bit values so when they try to return -1
it is interpreted properly by the kernel.
- The GPE value needs to be reset at the start so it does not
return stale data from a previous resume.
- If a GPE register is zero the value should only be updated
if it has not yet found a set bit.
BUG=chrome-os-partner:34532
BRANCH=samus,auron
TEST=build and boot on samus, suspend/resume with various
wake sources and ensure the reported _SWS values are correct
in every case.
Original-Change-Id: Ic6897f20ad2f321f3566694c032b75a3db120556
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235012
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit be3c79b87b81563f744eb885708a52730debaccb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I801c6e4f90dde0f5f69685f987a9831ee5e99e4a
Reviewed-on: http://review.coreboot.org/9699
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This code that stores the initial timestamp is not being used,
instead the timestamp is passed to romstage_main().
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Original-Change-Id: I0e0fa1ba74ab93d4454fdfa12208e712d2ae913c
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234402
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
(cherry picked from commit 838112cf79e2b4d51e5dc87d5ac9cd7e03807f29)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8fd7ba72c14c1e39f7bfa3a1ae8d03289a2abf73
Reviewed-on: http://review.coreboot.org/9698
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to avoid a 300ms timeout waiting for mbp_cleared flag
to be set there is a new flow for the ME10 1.5MB firwmare that
we can follow which will save significant boot time.
This requires sending new commands that do not generate an ACK
message, and ensuring an HMRFPO LOCK message is sent.
In addition now that the delay is removed clean up the ME path
to do the work in init() step and add a final() step that does
the disabling of the PCI device.
BUG=chrome-os-partner:30637,chrome-os-partner:34134
BRANCH=samus,auron
TEST=build and boot on samus, measure ~300ms speedup in boot time
Original-Change-Id: I753087ecd65f6ebed9f812318a359f893e01da9f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234400
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 25aff4b188dc94a99af30869a162e01e3fa8dee7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia35373548a902a718155a1a57057f55067d2f3ac
Reviewed-on: http://review.coreboot.org/9697
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove the blobs from the coreboot tree and get them from
3rdparty.
Change-Id: I0798091530be9654d7e073839b4efeb3f9c0302c
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/9694
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Remove the blobs from the coreboot tree and get them from
3rdparty.
Change-Id: I4938b5c47e6ae7059eda144b664aeafdd674f0fb
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/9693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
decode_edid() parses the whole EDID buffer, regardless of whether there
is an extension buffer, so we pass the size of the EDID actually read to
prevent EDID parser getting the wrong data.
BUG=chrome-os-partner:35053
TEST=Boot from jerry
BRANCH=veyron
Change-Id: I5951b670f129cf4765a5199cb58ac6abff5478a6
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4d508647efc0a9d48b2a4b23c12a54b63af2813e
Original-Change-Id: I8cd8e09025520322461fe940b01e4af3995b5ecd
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/240643
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9645
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This adds RTC functions to the existing RK808 driver.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=with eventlog patches applied to pinky, booted and saw eventlog
entries generated with correct timestamps:
localhost ~ # mosys -k eventlog list
entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096"
entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0"
entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode"
Change-Id: I1df70a2ca94ff463ffea8d9f02d951d6c62e6b08
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a304f7e6954f585f04feef54c4902dcb25a39fcc
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I3a240e342a54b2e7023da71708d0d70f5131f0b9
Original-Reviewed-on: https://chromium-review.googlesource.com/238525
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9643
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This moves PMIC_BUS from each mainboard's board.h file to a per-
mainboard Kconfig variable. To prevent humans from forgetting to
set a valid value, an invalid default is set in the rk3288 Kconfig
and checked in rk808.c so that compilation will fail if the mainboard
Kconfig does not override it.
Originally, PMIC_BUS was only used by mainboard code as an argument
to RK808 PMIC functions. To conform to the generic RTC API, however,
the RK808 code needs to have the bus number globally defined somewhere
since the rtc_get() and rtc_set() functions don't take any args.
Since CONFIG_PMIC_BUS is globally visible, we no longer need to pass
bus number to the PMIC functions.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I73783878e507b2e7b1526dd2f81cfbdf8f1e2a55
Reviewed-on: https://chromium-review.googlesource.com/240203
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9642
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This patch implements support for the CRYPTO module in RK3288 and ties
it into the new vboot vb2ex_hwcrypto API. We only implement SHA256 for
now, since the engine doesn't support SHA512 and it's very unlikely that
we'll ever use SHA1 for anything again.
BRANCH=None
BUG=chrome-os-partner:32987
TEST=Booted Pinky, confirmed that it uses the hardware crypto engine and
that firmware body hashing time dropped to about 1.5ms (from over 70ms).
Change-Id: I91d0860b42b93d690d2fa083324d343efe7da5f1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: e60d42cbffd0748e13bfe1a281877460ecde936b
Original-Change-Id: I92510082b311a48a56224a4fc44b1bbce39b17ac
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236436
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9641
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This switches all the rk3288 platforms to use the common CBFS wrapper
instead of implementing its own CBFS media driver. It also happens
that veyron_* platforms use Gigadevice SPI flash (at least for now).
As we use more SPI-related stuff, for example eventlog and vboot data in
Brain's case, we will need to use more of the SPI API anyway. This
prevents us from having to duplicate pieces of it for rk3288.
BUG=none
BRANCH=none
TEST=built and booted on Pinky
Change-Id: Ie462456814646fdc277485d9e2d8c901fd4936e7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2d6df2fe6d78bc8eee8689019b9aaf29c82b6b30
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Id307bd5fb6cc8f79411d8c66e1370e80c58d017b
Original-Reviewed-on: https://chromium-review.googlesource.com/235882
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9678
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We use the devicetree to pass the backlight control gpio before,
but if there have different board version, and it uses different
io to control backlight, it will hard to distinguish it. So, we
move the backlight control to mainboard, and use board_id
to distinguish the backlight control.
BUG=None
TEST=emerge veyron_pinky and Boot the pinky board
BRANCH=None
Change-Id: Ifa81eb2455296f4b4285b681208f4393f266fb34
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2ff7f65134dcf97f97757750eab41dcf8c7765d3
Original-Change-Id: I1ec8e04f4982c3a8c7e31d8dc2c75311b7199ffc
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234711
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9630
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Like Nyan, Veyron boards use a GPIO to reset the system so that we can
make the accompanying TPM reset secure and unforgeable. The normal
kernel reboot driver knows that, but the SoC-internal watchdog doesn't.
This patch implements a check for the global reset status register in
the early bootblock and triggers a hard_reset() when it matches "first
global watchdog reset" or "second global watchdog reset". Seems that
the difference between the two is is a choice controlled by
wdt_glb_srst_ctrl (unconfirmed), and we want this code to run in both
cases.
BRANCH=None
BUG=chrome-os-partner:33141
TEST=Run 'mem w 0xff800000 0x9' from the command line, watch how you end
up in recovery without this patch but can boot normally with it.
Change-Id: Ice79648831e1e97d22325711da9e82bbf6bf3c75
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 5d7cb52b2c2dcb2fff0bf83fc168439dade4b1b7
Original-Change-Id: I2581bde84f0445c15896060544e9acb60de91c8c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231734
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9629
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The only way to reliably reset an SD card in an unknown state is by
power-cycling. Since a kernel may crash and reboot at any point, SD
cards may be left in one of them fancy high-throughput modes that
depthcharge (or, in fact, a newly booting kernel without prior
knowledge) doesn't support, so we need to reset the card on every boot.
This patch adds support to turn off an RK808 regulator completely and
uses that to turn off SD card power rails in early romstage. The time
until configure_sdmmc() in ramstage turns them back on should be more
than enough to drain the power rail for an effective power-cycle.
BRANCH=None
BUG=chrome-os-partner:34289
TEST=Booted a Pinky from SD card, noticed that it works before and
after this patch.
Change-Id: Iaa5f7adaa59da69a964785c5e369ad73c6620224
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 95fba21907f1f3f686cb5a95b993736247db8f96
Original-Change-Id: I904b2d23ca35f765c000f9bee7637044f674eff9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233713
Original-Reviewed-by: Alexandru Stan <amstan@chromium.org>
Original-Tested-by: Alexandru Stan <amstan@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9626
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This function was added in upstream but was missing in Chromium OS
Change-Id: I35debf65153e5f280343eebfe91438ecf665ba22
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9677
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This is not a standard feature so it should be included by the
mainboard if it is actually present in a system.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=build and boot on samus
CQ-DEPEND=CL:226663, CL:226664
Change-Id: Id4d0e5ed243dcb95e64fb8c848667f651b75aa4e
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 8909913f5c11c5805c77a3373859634b02a301e2
Original-Change-Id: Ib7c171a5a007a2dddfb3d80341c6dc488e383e99
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226662
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; I2C0 clock is
set up properly.
BRANCH=none
Change-Id: I15ffc5f7d8e8aadfc3cd249284bc492d0d13d9a1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6404ab6ad12ea1579eaf5ae55a9eddd9bd9f96e2
Original-Change-Id: Iafdf492291b47f0088f3b5e621d630b8d21ab106
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/250450
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9673
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The base address used was TOP CLOCK control address instead of
the PERIPH CLOCK CONTROL. That was incorrect and is fixed with
the current patch.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; now the hash accelerator,
fed by this clock, is correctly clocked at 200MHz.
BRANCH=none
Change-Id: I0ead3951dc1dfc872881b8d1ae9b63f8104af50d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 871cb50ca43a6c760f346eb447e8ff102d8ca0b6
Original-Change-Id: I198d64f97a85a6fcf00c3853bf23d2d767e0e631
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/245313
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9670
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some of the asserts were not done properly: the value has
to be shifted before is matched with the mask.
Added condition to exit while loop for USB clock setup.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; after this patch is
applied none of the asserts fail and the code is executed
properly.
BRANCH=none
Change-Id: Ib3aae9f7751a9f077bc95b6e0f9d63e3e16d8e4b
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 96999a4322ba98e87bc6746ad05b30cc56704e2e
Original-Change-Id: I8d2d468d618ca1ffcb1421409122482444e6d420
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/243214
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9667
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With the added code for clock and MFIOs setup, bootblock
now exceeds 16KB. This patch increases the allowed limit
to 18KB.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; works as expected
BRANCH=none
Change-Id: I166f882bd3db446bcd6f9e1f828cab22266c6ac7
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: da95db5ed348419b7905dc1ab68fd64d7b2eb5e0
Original-Change-Id: I0cacc6163f21ae3673c2716b12dde66bd48290f9
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/243213
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9665
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As the payload increases in size, a bigger CBFS cache is required.
Therfore, bootblock, romstage and the cbfs cache were placed in
GRAM (128 K) and the stack and cbmem console were moved to
SRAM (64 K). With the exception of CBFS cache, the sizes of all
the other regions remains the same.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA and bring up board;
behavior was as expected.
BRANCH=none
Change-Id: I19857f785ca1514f7483d582c7ad6ee470a8fefc
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c895660dbdcd113bdc9d832beab30886313c28d6
Original-Change-Id: I004f8f081d04f83e3f5cee969e50803685cfdf67
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/236551
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9664
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When using this mode data is received and transmitted on the same
edge of the SPFI clock, which allows for higher frequencies of
operation. In this mode the maximum supported frequency is 50Mhz.
If this mode is not enabled the maximum supported frequency is
25Mhz.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; the SPFI hardware block is
fed by the system clock (with a fixed freqency of 400 MHz).
To achieve the SPFI frequency of 50MHz the internal divider of
SPFI must be set to 64. To achieve a frequency of 25 Mhz the
internal divider must be set to 32.
A value of 64 = division by 8
A value of 32 = division by 16
BRANCH=none
Change-Id: Ifd5f739b6157b99e4c1f92b5bb72615ee610ae6c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 8b6cce616ec7926682d4eff096563acf1dfd6c65
Original-Change-Id: I337b6fcf462bcf6021ca77a8b1133cf49140ba76
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241425
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9663
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Set elements:
- UART1 clock dividers and MFIOs
- SPIM1 clock dividers and MFIOs
- USB clock dividers
- System clock divider
- System PLL
- MIPS CPU PLL
BUG=chrome-os-partner:31438
TEST=tested on Pisachio bring up board; UART, SPI NOR, SPI NAND, and USB
have proper functionality.
BRANCH=none
Change-Id: Ib01186a652fd59295a4cafc3ca99b94aa9564f74
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 65e68d82f34bb40ef3cfb397ecf5df0c83201151
Original-Change-Id: Ia2c31bbbfc020dc4fd71c72b877414adfdfc42a8
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241423
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9662
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The GPU MMU won't function properly until it sees the VPR
is locked down. Therefore, do the appropriate work.
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I6011c75c1e6c231f2fa416e0057cb5805a88a2bb
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: ca9cc9917b98a148442468d1d1541a0408ab6c2c
Original-Change-Id: I3601f419b561cee392391577ef8db66b9fbd8c1b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242910
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: http://review.coreboot.org/9660
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add and call display shift clock divider function to set shift clock
divider.
This change is also intended for code sharing on dc settings.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and rush
Change-Id: I9ad1b32de50395720355bb2d00f5800c7f6c4b73
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 24a72fa3411652d54ae1f7d69db0a7293aad7877
Original-Change-Id: I01582c6863d31627ac93db9fddda93f4f78249cd
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/238943
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9614
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add these parameters so that they can be specified in devicetree.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and rush
Change-Id: I77ee16263e1ce6a8c32b3cd203c1b8a499514a8e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c3b254936e696f81ca7eeeb7f6968a5350352b59
Original-Change-Id: Iba47afe95c3889047a82582730be7a253fae76e7
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/238940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9611
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Freeing up memory on rk3288 is like squeezing water out of a stone right
now, but I still managed to get a few drops here and there. Let's hope
this will be enough.
BRANCH=None
BUG=None
TEST=Pinky builds and boots again. memsz is ~15K in bootblock and ~39K
in verstage.
Change-Id: Icf7ff3369bf367426a34f1490e0a041ae9bd6367
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9a3737ab535cdef228a1607433860f881db04412
Original-Change-Id: I90d9eab5b5d3af7a2e4b836a9c7b735b7c1c48e6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235870
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9609
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since we can now reduce our vboot2 work buffer by 4K, we can use all
that hard-earned space for the CBMEM console instead (and 4K are
unfortunately barely enough for all the stuff we dump with vboot2).
Also add console_init() and exception_init() to the verstage for
CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model
requires those functions to be called again at the beginning of every
stage... even though some consoles like UARTs might not need it, others
like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is
expected to be done by the platform-specific verstage entry wrapper, and
already in place for the only implementation we have for now (tegra124).
(Technically, there is still a bug in the case where EARLY_CONSOLE is
set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would
run init_console_ptr() as if they were there first, so the romstage
overwrites the verstage's output. I don't think it's worth fixing that
now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless
use-case and I think we should probably just get rid of the
CONFIG_BOOTBLOCK_CONSOLE option eventually.)
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I87914df3c72f0262eb89f337454009377a985497
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85486928abf364c5d5d1cf69f7668005ddac023c
Original-Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232614
Reviewed-on: http://review.coreboot.org/9607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have known for a while that the old x86 model of calling init_timer()
in ramstage doesn't make sense on other archs (and is questionable in
general), and finally removed it with CL:219719. However, now timer
initialization is completely buried in the platform code, and it's hard
to ensure it is done in time to set up timestamps. For three out of four
non-x86 SoC vendors we have brought up for now, the timers need some
kind of SoC-specific initialization.
This patch reintroduces init_timer() as a weak function that can be
overridden by platform code. The call in ramstage is restricted to x86
(and should probably eventually be removed from there as well), and
other archs should call them at the earliest reasonable point in their
bootblock. (Only changing arm for now since arm64 and mips bootblocks
are still in very early state and should sync up to features in arm once
their requirements are better understood.) This allows us to move
timestamp_init() into arch code, so that we can rely on timestamps
being available at a well-defined point and initialize our base value as
early as possible. (Platforms who know that their timers start at zero
can still safely call timestamp_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa
Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234062
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9606
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c
Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229975
Reviewed-on: http://review.coreboot.org/9620
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Files necessary for the SOC bringup are added to the CBFS as raw
blobs.
Ipq8064 specific MBN header will allow to determine were the blobs
should be loaded and what start address should be used.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=build storm firmware and verify that the right components are added:
$ emerge-storm coreboot chromeos-bootimage
$ cbfstool /build/storm/firmware/image.bin print
image.bin: 8192 kB, bootblocksize 32488, romsize 2883584, offset 0x7f40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x7f40 raw 376
ddr.mbn 0x8100 raw 25820
rpm.mbn 0xe640 raw 78512
tz.mbn 0x21940 raw 85360
fallback/verstage 0x36700 stage 39500
fallback/romstage 0x401c0 stage 15652
fallback/ramstage 0x43f40 stage 24328
config 0x49e80 raw 2701
fallback/payload 0x4a940 payload 65592
u-boot.dtb 0x5a9c0 (unknown) 2922
(empty) 0x5b580 null 2509336
$
Change-Id: I967cd20364c90a1ef7add959621992c2356f158d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6b5238d47da417b8b1993ad3348f4c32381cd0e4
Original-Change-Id: Id642ae68ef07750624f85b31ad891752d8af99bf
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233672
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9577
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The first blob in the Storm bootimage is a concatenation of the
Uber-sbl produced by the qca-firmware ebuild and the coreboot
bootblock.
The new tool is used to add the bootblock to uber-sbl and update the
size values in the combined header.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=no execution tests yet, the build succeeds.
Change-Id: I4f1fe8a97ffab04eee4f82bc43e6f5406dd9bb42
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a126a62f65a568d62fe35bdcf27eaec38fd1a997
Original-Change-Id: Iec3c1e943f1f9ee5ca20320a6365fc4aa5516e38
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232310
Original-Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9573
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The first 64 bytes of the framebuffer contain garbage after running
the option rom and after calling the VBE mode set with the flag to
clear the framebuffer.
Work around this issue by clearing the first 64 bytes in the framebuffer
in the broadwell graphics setup code after it executes the VBIOS.
BUG=chrome-os-partner:32771
BRANCH=samus,auron
TEST=build and boot on samus in dev mode, check for graphical corruption
Change-Id: I0381e32a5ea17e13c4ed598835999c12136418cf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f29c1b0b7c100cf290f82de671042823032f71c9
Original-Change-Id: I072bc913f7daea16e4861a7549e1b4ec85cde4cd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/222676
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9464
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Some boards spread their timer implementation out in multiple files with
one function each for no discernable reason. Let's clean that up to make
things a little simpler to find.
BRANCH=None
BUG=None
TEST=Booted Pinky, compiled Daisy and Pit.
Change-Id: I8b543d1a0d9af37bde5433b0c9271d687b2404b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 887765e1bd88d7aa49ad9a5e98b8831c10da6c10
Original-Change-Id: I43d29cd1b4a1d89cfd40f6cba5ca99ada3b00f82
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234061
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9601
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch doubles the ACLK peripheral clock for the PD_BUS power domain
to 297MHz, which is the closest to the maximum of 300MHz we can reach by
dividing GPLL. This frequency directly translates into SRAM speed, so
maximizing it has a huge impact on boot speed (especially with the lack
of SRAM caching).
BUG=chrome-os-partner:32987
TEST=Booted Veyron_Pinky. Hacked timestamps into vboot and confirmed
that the (visibly) long signature verification times are nearly halved.
Change-Id: Iafa3044854a4058a7f885c775119d964a6295de4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c230585f4344d0eab4f8eeaa761869965f2da08a
Original-Change-Id: I3f19eaa3d97dcc6235d820c71eb5edf2ae87d647
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224524
Original-Trybot-Ready: Doug Anderson <dianders@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9600
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Commit 257aaee9e3a (arm: Add bootblock_mainboard_early_init() for
pre-console initialization) inadvertently moved the timer initialization
after console initialization for IPQ806x, which is apparently not a good
idea for this platform. This patch solves the issue by moving
init_timer() to bootblock_mainboard_early_init(), which is the new hook
explicitly provided to perform pre-console tasks.
BRANCH=None
BUG=None
TEST=Built and booted Storm with 257aaee9e reverted. Noticed that it was
already broken. Bisected coreboot and tracked down breakage to commit
a126a62f (ipq8064: use the new utility to build bootblock). Built and
booted successfully with this patch and a revert of a126a62f to confirm
that the bug in question here is fixed.
Change-Id: I4a3faa2aec8ff1fbbe6c389f1d048475aa944418
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 752d1f879f9bd841f18bd84842491f747458cf52
Original-Change-Id: Ie4aa2d06cb6fda6d5ff8dd5ea052257fb7b8a24b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233290
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9574
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
this is a preparation for porting these drivers to coreboot. the code will be modified by the following patches.
BUG=chrome-os-partner:33647
BRANCH=ToT
TEST=None
Change-Id: I2baeed5b6130ace2515d6e28115f8d1008004976
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 7c03a186a599be9d274c6fcdea1906529cc117d7
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I9f3428ef02d2ba15ae63c99b10fe0605dd595313
Original-Reviewed-on: https://chromium-review.googlesource.com/231461
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/9582
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch uses the new bootblock_mainboard_early_init() hook to run the
UART pinmuxing on rk3288-based boards before initializing the console.
This allows us to get rid of the hacky second console_init() call in
bootblock_soc_init(). We can also simplify the pinmux selection a bit
since we know that a given board always uses the same UART (still keep
an assert around to be sure, though).
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky.
Change-Id: I3da8b0e4bd609f33cedd934ce51cb20b1190024b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: caabda8fc1ddb4805d86fd9a0d5d2f3cf738bfaf
Original-Change-Id: Ia56c0599a15f966d087ca39181bfe23abd262e72
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231942
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9604
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On most platforms, enabling the console and exception handlers are
amongst the very first things you want to do, as they help you see
what's going on and debug errors in other early init code. However, most
ARM boards require some small amount of board-specific initialization
(pinmuxing, maybe clocks) to get the UART running, which is why
bootblock_mainboard_init() (and with it almost all of the actual
bootblock code) always had to run before console initialization for now.
This patch introduces an explicit bootblock_mainboard_early_init() hook
for only that part of initialization that absolutely needs to run before
console output. The other two hooks for SoC and mainboard are moved
below console_init(). This model has already proven its worth before in
the tegra124 and tegra132 custom bootblocks.
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Daisy, Storm and Ryu.
Change-Id: I510c58189faf0c08c740bcc3b5a654f81f892464
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f58e84a2fc1c9951e9c4c65cdec1dbeb6a20d597
Original-Change-Id: I4257b5a8807595140e8c973ca04e68ea8630bf9a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231941
Reviewed-on: http://review.coreboot.org/9603
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch makes some slight changes to the way bootblock_cpu_init() and
bootblock_mainboard_init() are used on ARM. Experience has shown that
nearly every board needs either one or both of these hooks, so having
explicit Kconfigs for them has become unwieldy. Instead, this patch
implements them as a weak symbol that can be overridden by mainboard/SoC
code, as the more recent arm64_soc_init() is also doing.
Since the whole concept of a single "CPU" on ARM systems has kinda died
out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had
already been done on Storm/ipq806x, which is now adjusted to directly
use the generic hook.) Also add a proper license header to
bootblock_common.h that was somehow missing.
Leaving non-ARM32 architectures out for now, since they are still using
the really old and weird x86 model of directly including a file. These
architectures should also eventually be aligned with the cleaner ARM32
model as they mature.
[pg: this was already partly upstreamed. These are the remains.
Further cleanup is necessary and on the short-term TODO, but beyond
the scope of this commit]
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Storm and confirmed in the
disassembly that bootblock_soc_init() is still compiled in and called
right before the (now no-op) bootblock_mainboard_init().
Change-Id: Idf655894c4fec8fce7d3348d3b3e43b1613b35db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 257aaee9e3aeeffe50ed54de7342dd2bc9baae76
Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9602
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Display configuration is board specific. The change here is preparing
for supporting other than dsi interface.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and test dev/rec mode, also build rush ok
Change-Id: Ied39d5d539d2be4983ab70976bffbe51fccba276
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 36be6b2e35c6246d5384d71b9ab9d4ddbf17764a
Original-Change-Id: I494a04f7d6c0dbad2d472f4c2cd0aabfb23b8c97
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234271
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9584
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
dc supporting functions can be used for other than dsi display
interfaces. This change is preparing for supporting sor display
interface.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and test dev/rec mode, also build rush ok
Change-Id: I8a310e188fae70d7726c4360894b392c4546e105
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a7ab7225e3419a0fd93894dbb9a959390f29945b
Original-Change-Id: Id14cbd89457cb91c23526927a432f4eb7cc6291b
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234270
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9583
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
After DDR PHY reset de-asserted, DLL automatically starts to
lock, and the lock time is maximum 5.12us. The output clock of
DLL supplies the clocks of DDR controller and PHY digital logic.
So before DLL lock, the clocks of DDR controller and PHY digital
logic are indeterminate. When programming DDR in the period of
DLL unlock, the programming maybe unstable because of the
indeterminate clocks. So we need wait for at least 5.12us after
de-asserting reset, then start to program DDR registers.
10us provide some safety margin.
BUG=chrome-os-partner:33148
TEST=I'm using the following command line test ok(15000 cycles).
"while sleep 4 && dut-control cold_reset:on sleep:.1 cold_reset:off;
do : ; done"
BRANCH=None
Change-Id: Ie7d615f5a2264c615c4b4413d6b828cd3d78cd2b
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 54e1a439c0e29aaf4fc542ae756f7bb036ceaf3e
Original-Change-Id: I55f8cb11ed3d7962567c5f40a31e6c8aed8fdcb0
Original-Signed-off-by: DaiLunXue <dlx@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/232894
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Lunxue Dai <lunxue.dai@rock-chips.com>
Original-Tested-by: Lunxue Dai <lunxue.dai@rock-chips.com>
Reviewed-on: http://review.coreboot.org/9578
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Used for audio on Rush/Ryu. I2S1/DAP2 provides the audio
'stream' for the dev/rec mode 'beeps'.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=With follow-on CLs that make use of this support,
audio beeps (via VbExBeep) can be heard on Rush. Built
both Rush and Ryu OK.
Change-Id: Iea5559db4431e48001adbbce17fa0f3aaaf8387c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2bd701a5f4186e49739b25f4afd5000d5d9b4970
Original-Change-Id: Ia8c32303979f25300e22b5a14609d9d9d5ce3132
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233670
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9576
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some SPI controllers (like Imgtec Pistachio), have a hard limit on SPI
read and write transactions. Limiting transfer size in the wrapper
allows to provide the API user with unlimited transfer size
transactions.
The tranfer size limitation is added to the spi_slave structure, which
is set up by the controller driver. The value of zero in this field
means 'unlimited transfer size'. It will work with existion drivers,
as they all either keep structures in the bss segment, or initialize
them to all zeros.
This patch addresses the problem for reads only, as coreboot is not
expected to require to write long chunks into SPI devices.
BRANCH=none
BUG=chrome-os-partner:32441, chrome-os-partner:31438
TEST=set transfer size limit to artificially low value (4K) and
observed proper operation on both Pistachio and ipq8086: both
Storm and Urara booted through romstage and ramstage.
Change-Id: Ibb96aa499c3eec458c94bf1193fbbbf5f54e1477
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4f064fdca5b6c214e7a7f2751dc24e33cac2ea45
Original-Change-Id: I9df24f302edc872bed991ea450c0af33a1c0ff7b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232239
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9571
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
WPT-LP has 4 SATA ports. Current code assumes 6 SATA ports and as a result,
some reserved bits are written with 1. No specific issue has been observed
so far.
BUG=None
BRANCH=None
TEST=Verify SATA PCI configure space dump on Auron
Change-Id: I737719b3d5cd788158cd5b6991405ba098be4078
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2b55587a74ac5d45354dc123937b562290468855
Original-Change-Id: I9c53ac86e2bf72901647bd2cfa48ac0ce31abea0
Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233661
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9479
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The information about the DMA memory area is further passed
through the coreboot table to the payload.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA; DMA memory area was used to test the
functionality of the DWC2 USB controller driver; behavior was
as expected.
BRANCH=none
Change-Id: I658e32352bd5fab493ffe15ad9340e19d02fd133
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 0debc105b072a37e2a8ae4098a9634d841191d0a
Original-Change-Id: Icf69835dc6a385a59d30092be4ac69bc80245336
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/235910
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/9593
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
RAM repair has to be performed to cluster 1 also.
BRANCH=none
BUG=none
TEST=Test on Rush and make sure RAM repair completes
Change-Id: I0daf969a995a2be152270bc06501eaf086a13a97
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6b07894cc737cb192f68e254d522b55d8ca3b2f3
Original-Change-Id: I458e0a66d76318c6a4aa82547c9037c7b969f1e1
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/239360
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9592
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Rather than enable this in every mainboard just enable
it by default for all broadwell devices and let a
specific mainboard disable it if needed.
BUG=chrome-os-partner:34420
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I6e47c20abf29abfbd1f4b7905914b4c9fadb0ae7
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 25d3a685893e1c85f7b78e302da3187947a1f84f
Original-Change-Id: I26d9f2e2a12d3f2f888ecb5af0d949eec5928f57
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/238400
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9590
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is necessary for the subsequent changes that will add to the size
of romstage.
BUG=chrome-os-partner:31438
TEST=coreboot builds successfully;tested on Pistachio FPGA
BRANCH=none
Change-Id: I132215bd44708913d878bbd8b6147bef535b52df
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 00f73f9d80a36fc43735f093365564b9d74ed7f7
Original-Change-Id: Ie858416a1c9ab63cfe85eea40a76a093cbd2c79c
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233871
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9589
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
edp must reset when device power up, otherwise the edp
register maybe uncertain, now the edp source clock default
select 27M, and in pinky and jerry board we use 24M as edp
sourec clock, if we want to reset edp, we must after the clock
source select 24M.
BUG=chrome-os-partner:34023
TEST=Booted Veyron jerry and read edid normal
BRANCH=None
Change-Id: I4b03dbabe5d3d595d2d56efb0cd82f510f8d2e1b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2292da77cc2322b85c4b4f4f20e4ebcc4c4d060d
Original-Change-Id: Ica031d2d52deb539c1a0a56968786d6952b3d0e8
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231336
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9555
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Implement VOP and eDP drivers, vop and edp clock configuration,
framebuffer allocation and display configuration logic.
The eDP driver reads panel EDID to determine panel dimensions
and the pixel clock used by the VOP.
The pixel clock is generating using the NPLL.
BUG=chrome-os-partner:31897
TEST=Booted Veyron Pinky and display normal
BRANCH=None
Change-Id: I01b5c347a3433a108806aec61aa3a875cab8c129
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e4f863b0b57f2f5293ea8015db86cf7f8acc5853
Original-Change-Id: I61214f55e96bc1dcda9b0f700e5db11e49e5e533
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219050
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9553
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
LDO7 (VCC10_LCD_PWREN_H) is essentially just a glorified GPIO that turns
the real VCC10 regulator on or off. We tried setting it to 3.3V since it
matches the VCC33_SYS voltage on the input of that regulator. However,
we didn't notice that the LDO only supports going up to 2.5V.
This patch changes the voltage to the allowed maximum, which should
still work fine as an enable line (and is the same value used by the
kernel). This removes an assertion error in the ramstage.
Also change the PMIC driver to assert maximum VSEL values based on the
LDO, because the lower-voltage ones support one more setting. (LDO3 is
actually listed to only go up to 0b1111 in the manual, and has a weird
jump from 0b1101 -> 2.2V (skipping over 0b1110) to 0b1111 -> 2.5V. I
don't know if that's a documentation error or what they were smoking
when they designed that, but we don't need to care for now.)
BRANCH=None
BUG=None
TEST=Booted on Pinky, no more ASSERTION FAILED.
Change-Id: I38bf99e38822fd0883fd4d0bd9a1b01143545a95
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 70f3149efbc3aa9a03ab3fd5be99d17d9c5e1c87
Original-Change-Id: I68a3bb882cf25d98aca8922ede2a17e1ef6524de
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228292
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-by: Jerry Parson <jwp@chromium.org>
Reviewed-on: http://review.coreboot.org/9547
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The CPU on/off functions are the method for the Kernel to support CPU
hot-plug function in PSCI. To support this, we still need flow controller
support to capture the WFI from the CPU and inform PMC to power gate the
CPU core. On the other path, we turn on the CPU by toggling the PMC and
use flow controller to let go when the power is steady.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=built the kernel with PSCI enabled,
check both of the CPUs are coming up,
test the CPU hot-plug is working on Ryu
Change-Id: If2c529b6719c5747d5aea95fb5049b2d7353ff17
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0f078e89daad1c4d8b342a395f36b3e922af66f5
Original-Change-Id: Ie49940adb2966dcc9967d2fcc9b1e0dcd6d98743
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231267
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9542
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Kyösti Mälkki