| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Enabling the monotonic timer allows for collecting
boot stage times as well as each device initialization
time.
BUG=chrome-os-partner:23166
BRANCH=None
TEST=Built and booted. Noted timings in console output.
Change-Id: I5fdc703ea21710fd26de352f367c6fc0c767ab6a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174422
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4894
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Bring up the APs using x86 MP infrastructure.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi. Noted all cores are brought up.
Change-Id: I9231eff5494444e8eb17ecdc5a0af72a2e5208b5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173704
Reviewed-on: http://review.coreboot.org/4889
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Bay Trail has the following types of resets it supports:
- Soft reset (INIT# to cpu) - write 0x1 to I/O 0x92
- Soft reset (INIT# to cpu)- write 0x4 to I/0 0xcf9
- Cold reset (S0->S5->S0) - write 0xe to I/0 0xcf9
- Warm reset (PMC_PLTRST# assertion) - write 0x6 to I/O 0xcf9
- Global reset (S0->S5->S0 with TXE reset) - write 0x6 or 0xe to
0xcf9 but with ETR[20] set.
While these are documented this support currently provides support
for 2nd soft reset as well as cold and warm reset.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted.
Change-Id: I9746e7c8aed0ffc29e7afa137798e38c5da9c888
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172710
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4878
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The caching policy for romstage was previously using a 32KiB
of cache-as-ram for both the MRC wrapper and the romstage stack/data.
It also used a 32KiB code cache region. The BWG's limitations for
the code and data region before memory is up was wrong. It consists
of a 16-way set associative 1MiB cache. As long as enough addresses
are not read there isn't a risk of evicting the data/stack.
Now create a 64KiB cache-as-ram region split evenly between romstage
and the MRC wrapper. Additionally cache the memory just below
4GiB in CBFS size. This will cover any code and read-only data needed.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and booted quickly with corresponding changes to MRC warpper.
CQ-DEPEND=CL:*146175
Change-Id: I021cecb886a9c0622005edc389136d22905d4520
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172150
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4868
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
This is a no-op change for easier maintenance.
BUG=none
TEST=manual
. baitrail coreboot still builds and runs
Change-Id: I0c0bd78c6f361e8f81979f19cce148e7f51865ee
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171002
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4857
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This commit always selects COLLECT_TIMESTAMPS and starts
tracking TSC values from the early stages of bootblock.
The initial timestamp value is saved in mm0 and mm1 while
in bootlbock. This approach works because romcc is not configured
to use mmx registers for its compilation.
Additionally, the romstage api with the mainboard was changed to
always pass around a pointer to a romstage_params structure as the
timestamps are saved in there until ram is up.
BUG=chrome-os-partner:22873
BRANCH=None
TEST=Built and booted with added code to print out timestamps at
end of ramstage. Everything looks legit.
Change-Id: Iba8d5fff1654afa6471088c46a357474ba533236
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170950
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4856
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The initial Bay Trail code is intended to support
the mobile and desktop version of Bay Trail. This support
can train memory and execute through ramstage. However,
the resource allocation is not curently handled correctly.
The MRC cache parameters are successfully saved and reused
after the initial cold boot.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=Built and booted on a reference board through ramstage.
Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168387
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4847
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
