Age | Commit message (Collapse) | Author |
|
Change-Id: Ib7d2a5c14675427fe9556a6b81ed5397f17937d8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6049
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: I0ea09d75cb05687407fb152642578e19824d1c4c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6048
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
CONFIG_ARCH is a property of the cpu or soc rather than a property of the
board. Hence, move ARCH_* from every single board to respective cpu or soc
Kconfigs. Also update abuild to ignore ARCH_ from mainboards.
Change-Id: I6ec1206de5a20601c32d001a384a47f46e6ce479
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5570
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
With the recent improvement 3d6ffe76f8a505c2dff5d5c6146da3d63dad6e82,
speedup by CACHE_ROM is reduced a lot.
On the other hand this makes coreboot run out of MTRRs depending on
system configuration, hence screwing up I/O access and cache
coherency in worst cases.
CACHE_ROM requires the user to sanity check their boot output because
the feature is brittle. The working configuration is dependent on I/O
hole size, ram size, and chipset. Because of this the current
implementation can leave a system configured in an inconsistent state
leading to unexpected results such as poor performance and/or
inconsistent cache-coherency
Remove this as a buggy feature until we figure out how to do it properly
if necessary.
Change-Id: I858d78a907bf042fcc21fdf7a2bf899e9f6b591d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5146
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: I2ecfd9733b65b6160bc2232d22db7b16692a847f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5149
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
This may need further tuning but will start at 1.0%.
boot on falco and check /sys/firmware/log
localhost ~ # grep RTD2132 /sys/firmware/log
RTD2132: Enable 1.0% Spread Spectrum
I2C: 01:35 (Realtek RTD2132 LVDS Bridge)
Change-Id: I96e1c14dbc6a7bfaf1c8deb1806c48bf2fd3e32a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61895
Reviewed-on: http://review.coreboot.org/4366
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
This config option was not enabled which was preventing
the user from enabling developer mode from recovery mode.
With this enabled we can disable the "dev mode by default"
behavior and let people enable it by entering recovery mode.
This will make the firmware behave like a typical chromeos
device.
Peppy is left in "default dev mode" until after bringup.
1) boot slippy in normal mode by default
2) enter recovery mode with servo button
3) Ctrl+D on USB keyboard to enter developer mode
4) boot slippy in developer mode
Change-Id: I414c0d10dd0489e3c89798f75a2872a43297c8d8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57350
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4220
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Those building Chromebook firmware from coreboot git might be more
interested in building without ChromeOS extras.
Change-Id: I2f176d059fd45bf4eb02cc0f3f1dcc353095d0ce
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3977
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The EC was disabling flash commands and sysjump was not working
properly. With those two fixed software sync works properly.
Google Chrome EC MKBP driver ready, id 'slippy_no_version'
Clearing the recovery request.
EC hash:7fea29992ef72e3e64d8ffe522aa1dfa68dcb44a2da96a4c19530ea1a0bd22c4
EC-RW hash address, size are 0xffa1cfe8, 32.
Hash = 727e79934d9394184da496cebc27f7275b9d2d91079bf125d8f977a1f8aa4cde
Expected hash:727e79934d9394184da496cebc27f7275b9d2d91079bf125d8f977a1f8aa4cde
EC-RW firmware address, size are 0xffad000c, 57180.
VbEcSoftwareSync() - expected len = 57180
Computed hash of expected image:727e79934d9394184da496cebc27f7275b9d2d91079bf125d8f977a1f8aa4cde
VbEcSoftwareSync() updating EC-RW...
VbEcSoftwareSync() jumping to EC-RW
VbEcSoftwareSync() in RW; done
Change-Id: I63ca00d6c94854f2b395eb736ce20792da5f8de2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56821
Reviewed-on: http://review.coreboot.org/4208
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
- Only the first two DIMM SPDs are specified so far
- GPIO map is updated
- iSSD power sequencing removed
- USB port map updated
Change-Id: I4172460d3b075bfd5bb22013a6225cf0e8f95b9c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56329
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4184
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|