Age | Commit message (Collapse) | Author |
|
Change-Id: I156077bf5571764d0e4bc044be80c8ab94556de4
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5178
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: I857755976b17b0e492c086162f395a77933eeed8
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4698
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
After running the MRC blob print out some information
on the training: MRC version, number channels, DDR3
type, and DRAM frequency.
Example output:
MRC v0.90
2 channels of DDR3 @ 1066MHz
Apparently there are two dunit IOSF ports -- 1 for each
channel. However, certain registers really on live in
channel 0. Thus, there was some changes to dunit support
in the iosf area.
BUG=chrome-os-partner:22875
BRANCH=None
TEST=Built and booted bayleybay in different configs.
Change-Id: Ib306432b55f9222b4eb3d14b2467bc0e7617e24f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172770
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4882
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
If a payload is compiled to use SSE instructions it will
fault with an undefined opcode because SSE instructions weren't
enabled. Therefore enable SSE instructions at runtime.
BUG=chrome-os-partner:22991
BRANCH=None
TEST=Built and booted with SSE enabled payload. No exceptions seen.
Change-Id: I919c1ad319c6ce8befec5b4b1fd8c6343d51ccc1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172642
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4881
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Add suport for verifying the ramstage with vboot
during romstage execution. Along with this support
select CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM to
cache the relocated ramstage 1MiB below the
top end of the TSEG region.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with CONFIG_VBOOT_VERIFY_FIRMWARE=y
selected.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I355f62469bdcca62b0a4468100effab0342dc8fc
Reviewed-on: https://chromium-review.googlesource.com/172712
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4880
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The ASL compiler warned about "Control Method should be made Serialized
(due to creation of named objects within)". This commit eliminates the
warnings by changing those NonSerialized into Serialized.
Change-Id: I639e769cf7a9428c34268e0c555a30c7dee1e04c
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Reviewed-on: http://review.coreboot.org/5189
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
spd.bin can reside anywhere in CBFS, and we only use CBFS APIs to
access and read it. As such, there is no need to hardcode it, and it
can collide with mrc.bin or mrc.cache on some boards. Do not use a
specific position for spd.bin, but instead let cbfstool find the
optimal placement.
Change-Id: I496094d3c0de708813494095b7ac4be8addb4112
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5210
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Pull-ups and pull-downs can be active on functional pins. Add configs
for these options so they can be specified on board GPIO maps.
TEST=Manual on bayleybay. Verify that platform boots to payload load.
BUG=chrome-os-partner:22863
Change-Id: Ie4f77d8ce812f086cc8fe5a6bfcac59669f56f92
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172766
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5209
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
If the SerialIO devices are put into ACPI mode then it is possible
to use ACPI to instantiate the touchpad in the kernel without
needing to have a platform level driver to do the binding.
This is the "new way" of describing on-board I2C devices and the
upstream kernel is starting to add ACPI IDs to drivers so they can
be used in this fashion. For the Cypress touchpad use a generic
ACPI ID of "CYPA0000" to describe it.
In order to support the proper scoping of the touchpad device under
the appropriate I2C controller device the mainboard.asl file needs
to be included after pch.asl so the I2C device exists.
Change-Id: I81e053d27be478f3a19b6f9b13cd2b4fabcb88c0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5194
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Remove the bit of code that was putting the SerialIO devices into
D3Hot state when they are switched from PCI to ACPI mode. Instead,
add the appropriate ACPI Methods to allow the kernel to control the
power state of the device.
The problem seems to be that if the device is put in D3Hot state
before it is switched from PCI to ACPI mode then it does not properly
export its PCI configuration space and cannot be woken back up.
Adding the ACPI Methods for _PS0/_PS3 allows the kernel to transition
the device into D0 state only when it is necessary to communicate with
the device, then put it back into D3Hot state.
Change-Id: I2384ba10bf47750d1c1a35216169ddeee26881df
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5193
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These are almost one-to-one copies from pci_device.c. However,
devicetree has not been enumerated yet and we have no console.
Change-Id: Ic80c781626521d03adde05bdb1916acce31290ea
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5196
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
The files affected do not make any PCI configuration calls.
If they did, the more correct includes would be pci_ops.h,
pci_defs.h and pci_ids.h.
Change-Id: I3e7f009371be6ea50318eaabf0c15500cb3f1210
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5200
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Adding PCI functions for romstage in pci.h breaks ARMv7 build without
this. Also fix two related includes to use pci_def.h instead.
Change-Id: I5291eaf6ddf5a584f50af29cf791d2ca4d9caa71
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5199
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Top-level interface to console over USB mut not require low-level
details of ECHI debug port internals.
Change-Id: If3ca3b1f479e3f20976cd4abd8f5e682a58d5650
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5197
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
There were ASL compiler warnings about "Size mismatch". This commit
eliminates the warnings by changing the ASL declarations of those
fields.
Change-Id: If851ed4892ef6c96acbff861abd7001ab67d9d66
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Reviewed-on: http://review.coreboot.org/5190
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Missing copyright notes added.
Change-Id: I55b320a169b1125017c63b7a2384078465e7ce6e
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Reviewed-on: http://review.coreboot.org/5188
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Some out-commented code contained variables which changed name.
This commit fixes the "problem".
Change-Id: I8d9168c9f4b2cb6810b3e4dfeff2155f3c08357d
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Reviewed-on: http://review.coreboot.org/5187
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This platform has a hard reset button
Change-Id: Ic4d2f9382b6770654eea8842a37ad38cf12de459
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Reviewed-on: http://review.coreboot.org/5097
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Add cool-n-quiet functionality which allows the OS to dynamic
alter CPU voltage and frequency change in order to save power
e.g. when the CPU load is low.
Change-Id: I4c895a56bcf571d4276af192aeef87d120143063
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Reviewed-on: http://review.coreboot.org/5186
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
|
|
It is inappropriate for chipset code to be redefining
types -- especially NULL to a non-pointer type. There's
only one non-straight forward change. A condition
being checked was '!ptr_type == NULL' (0 as int). That
check is actually 'ptr_type != NULL'.
Change-Id: Iab5733e5a573baba6fec94e0c955ba4fad72c836
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5088
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
|
|
Configure GPIOs according to function on board.
TEST=compile only.
BUG=chrome-os-partner:22863
Change-Id: Ic38eeb64149606f2d7a19cc7a0144cc7e24807b8
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172657
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4875
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
gpncore config tables were previously missing -- add them.
Also, make the baytrail GPIO/PAD LUTs easier to read.
TEST=Manual. Build + boot on bayleybay.
BUG=chrome-os-partner:22865
Change-Id: I49a1b23c7ad4fb5f4c86618e8c78ea9a1a42f79d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172510
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4874
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
There are currently 4 SKUs:
0b000 - 4GiB total - 2 x 2GiB Micron MT41K256M16HA-125:E 1600MHz
0b001 - 4GiB total - 2 x 2GiB Hynix H5TC4G63AFR-PBA 1600MHz
0b010 - 2GiB total - 2 x 1GiB Micron MT41K128M16JT-125:K 1600MHz
0b011 - 2GiB total - 2 x 1GiB Hynix H5TC2G63FFR-PBA 1600MHz
Add each of the 4 spds to the build, and use the proper
parameters to MRC to use the in-memory SPD information.
BUG=chrome-os-partner:22865
BRANCH=None
TEST=Built. Noted 1024 bytes of SPD content.
Change-Id: Ife96650f9b0032b6bd0d1bdd63b8970e29868365
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172280
Reviewed-on: http://review.coreboot.org/4872
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
It's helpful to have a lot of the early init happen
before the handoff to mainboard. One example of this
need is having the BARs programmed so that the mainboard
can read board-specific gpios.
BUG=chrome-os-partner:22865
BRANCH=None
TEST=Built. Booted and saw console outout in bayleybay
mainboard.
Signed-off-by; Aaron Durbin <adurbin@chromium.org>
Change-Id: I030d7b4f9061ad7501049e8e204ea12255061fbe
Reviewed-on: https://chromium-review.googlesource.com/172290
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4871
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
- Add functions to peek at GPIO input pad values (need to be used from
romstage for board ram_id GPIOs)
- Modify UART GPIOs to use existing fn-assignment function
TEST=Manual. Add debug print and verify that GPIO functions return input
values. Also, verify UART still functions in romstage.
BUG=chrome-os-partner:22865
Change-Id: Ib2e57631c127a592cfa20ab6e2184822424e9d77
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172189
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4870
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Set the BSP to operate at max frequency early in romstage.
The call to punit_init() is when the frequency actually ramps as
that makes the punit actually start working.
BUG=chrome-os-partner:22857
BRANCH=None
TEST=Built and booted. Noted operating frequency status is max.
Change-Id: Icfd9e5c7682aa21fc740bd687607ca6a66597d5e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172131
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4869
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
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>
|
|
Like the bunit and dunit, add the punit accessor functions.
BUG=chrome-os-partner:23085
BRANCH=None
TEST=Built.
Change-Id: Ifd7184dfca8c0491c107bc1c562ea1ded444e372
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171931
Reviewed-on: http://review.coreboot.org/4867
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
- Set config0 defaults for hysteresis disable, pad bypass, etc.
- Set config1 power-on defaults.
- Set pad_val for input as default.
BUG=chrome-os-partner:22863
TEST=Manual. Enable GPIO_DEBUG and verify pad registers are set
according to expectation. Also verify bayleybay still boots to payload
loading.
Change-Id: I0f1c9e4d4f39c5c56d7e14a82eb4825612e19420
Reviewed-on: https://chromium-review.googlesource.com/171903
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4866
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
We should not have x86 specific includes in lib/.
Change-Id: I18fa9c8017d65c166ffd465038d71f35b30d6f3d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5156
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Needs printk and is not a console core function.
Change-Id: Id90a363eca133af4469663c1e8b504baa70471e0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5155
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: Ic97a497a634533f44d94df297ca6e35d94c34565
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/5160
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Basic ACPI support for this old platform. Created by copying and
tweaking similar motherboard ACPI implementations in coreboot.
Works reasonably well under Linux, providing HPET-timers
and more under linux (tested under OpenSUSE 12.2 kernel 3.4.63-2.44).
Not tested under Windows.
Change-Id: I69431be962a0d272db398ecf4ac9f0249de8ebab
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Reviewed-on: http://review.coreboot.org/5185
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
There are EHCI compatible host controllers on ARM without PCI bus
architecture. Currently we have not come across one with the debug
capability though.
Change-Id: I8775c9814f6fdf8754f97265118a7186369d721d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5175
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
USB device end toggles data PID when we ACK'd the zero-length data
packet. As USB host we need to toggle data PID too or the next data
received would get discarded.
Change-Id: I3203bc874c7ded9244c7548a666d7041a0fbb379
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4775
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
This claim is useless when done before EHCI controller reset. Code in
usbdebug_init_() already sets this properly after reset, see use of
DBGP_OWNER.
Change-Id: Ic17493fe4edbbbed6ebcbef35a264fbf188f1fba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4709
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Read from USB endpoint_in 8 bytes at a time, the maximum what
EHCI debug port capability has to offer.
Change-Id: I3d012d758a24b24f894e587b301f620933331407
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4700
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
LDN is 8-bit but coreboot squeezes unrelated info: VLDN in this field.
Increase to 16-bit to handle this.
Change-Id: I97af1b32dcfaed84980fa3aa4c317dfab6fad6d8
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5165
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Be more conservative and only add VGA devices' prefetchable
resources as write-combining in the address space. Previously
all prefetchable memory was added as a write-combining memory
type. Some hardware incorrectly advertises its BAR as
prefetchable when it shouldn't be.
A new memranges_add_resources_filter() function is added
to provide additional filtering on device and resource.
Change-Id: I3fc55b90d8c5b694c5aa9e2f34db1b4ef845ce10
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5169
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I5223c54c8ddbc60a176e4d718730e99decc772a3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5112
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The calculations for static allocation are no longer valid.
Change-Id: I6740cdcec789abddf78485a0edaf24882ef8c2a5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4569
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Change-Id: Ia410b61c4babdfa3c984539527a9739462d3ad80
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5141
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
This call is already in console_init().
Change-Id: Ie0cb3595af514e37efac5ac5d474f52ba551bf22
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5140
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: If723896cc31da75dbb3a63d5dc959764e96fded1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5139
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Change-Id: Ie915ef9dbc45604bd5ca1b610acb12af634fdebe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5138
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Unused and hard-coded to use uart8250 on IO.
Change-Id: I3f84c50039a450a2ae97a5fd2af89992f8567e6c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5137
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Also prepare this console for use in romstage.
Change-Id: I26a4d4b5db1e44a261396a21bb0f0574d72aa86d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5136
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
Change-Id: I978b6009c09c31be4429f57be40ef82f438f7574
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5135
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I46eb17ab19cea8759b3e4822019285cbe907e83a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5134
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Also relocate and split header files, there is some interest
for EHCI debug support without PCI.
Change-Id: Ibe91730eb72dfe0634fb38bdd184043495e2fb08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: I918ca1d0d0d7bcb7e16d41a12830a0357f15b8ed
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5130
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
Change-Id: I44194153817b8e6b641e407fc4a9e0fd5bc3f318
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5152
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
If the MTRR usage exceeds the BIOS allocation for MTRR usage
re-try without the WRCOMB type.
Change-Id: Ie70ce84994428ff6700c36310264c3c44d9ed128
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5151
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
|
|
The memranges_update_tag() function replaces all instances
that are tagged with old_tag and update to new_tag. This
can be helpful in the MTRR code by adjusting the address
space if certain memory types cause the MTRR usage to
become too large.
Change-Id: Ie5c405204de2fdd9fd1dd5d6190b223925d6d318
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5150
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Flash prefers 32-bit sequential access. On some platforms ROM is
not cached due to i.a. MTRR shortage. Moreover ROM caching is not
currently enabled by default. With this patch payload decompression
is sped up by theoretical factor of 4.
Test on X201, with caching disabled:
Before:
90:load payload 4,470,841 (24,505)
99:selfboot jump 6,073,812 (1,602,971)
After:
90:load payload 4,530,979 (17,728)
99:selfboot jump 5,103,408 (572,429)
Change-Id: Id17e61316dbbf73f4a837bf173f88bf26c01c62b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5144
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
Speeds up coreboot and especially payload load.
Before:
90:load payload 4,530,979 (17,728)
99:selfboot jump 5,103,408 (572,429)
After:
90:load payload 4,390,051 (14,849)
99:selfboot jump 4,505,966 (115,915)
Change-Id: I45c3042594cda16ab3adde6472e00ec1b2d2a688
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5145
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
BUG=chrome-os-partner:23121
BRANCH=None
TEST=None
Change-Id: I283415be326e2d92e1e1bf7866954f17a7266edb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171940
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-on: http://review.coreboot.org/4865
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The punit is responsible for a number of things. Without
performing the sequence included it won't change processor
frequency when requested and apparently there are some bizarre
hangs introduced if this sequence isn't included either. Lastly,
this needs to come after microcode has been loaded. As that is
done in bootblock the ordering is correct.
One other side effect is that this fixes the graphics devices'
device id. Before it was showing up as the same device id of the
SoC transaction router.
BUG=chrome-os-partner:22880
BUG=chrome-os-partner:23085
BUG=chrome-os-partner:22876
BRANCH=None
TEST=Built and booted.
Change-Id: Ib7be1d4b365e9a45647c778ee5f91de497c55bf1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171862
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4864
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Start loading microcode in the bootblock. This way
no caching has been set up and cache-as-ram mode
will be running in a validated configruation (with ucode
patch).
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and booted. Confirmed microcode is loaded.
Change-Id: I6fd1d8e55bcc9d799b11d9faed771ac50dc120a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171861
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4863
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The TCO timer always starts ticking out of reset.
However, depending on microcode loading and punit
initialization the TCO timing out has a different
impact on the sytem. Without loading microcode
or initializing the punit the tco times out and
nothing happens. However, when microcode is loaded
a timeout will reset the system. Lastly, if the
punit is initialized but the microcode isn't loaded
the TCO timeout will shut down the system.
To fix all the weird symptoms disable the TCO.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and booted with microcode loading. Reset doesn't
occur.
Change-Id: I49cd62f510726a96bf734ae728a352c671d1561e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171860
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4862
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Apparently there was another BAR living at 0x5c in the LPC
bridge that mapped the PUNIT registers. EDS 2.0 released
and this register is now documented.
BUG=chrome-os-partner:23085
BRANCH=None
TEST=Built and booted.
Change-Id: I5892c2a14923b57826060e92b4335cb1952ea057
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171612
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4861
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The 316 microcode is the newest version. Include that in the build.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and partially booted with microcode loading. Noted 316
loaded.
Change-Id: Iba01dd58688737ae38bc58a84014ee9526540db1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171611
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4860
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Allow for one to write an individual byte of a 32-bit register
when sending a read/write through the IOSF messaging system.
Add PUNIT registers and fields for early sequencing.
BUG=chrome-os-partner:23085
BRANCH=None
TEST=Built and partially booted with changes that use PUNIT
registers and individual byte en fields.
Change-Id: I929fb5c51d805c55c478cab884e3572254987fc7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171710
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4859
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The mrc_wrapper.h was changed to protect against ABI differences
between the two sets of compilers and flags used. This requires
a prope shim for the console output funciton.
BUG=chrome-os-partner:23048
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I976e692e66dcfc0eacadae6173abfd9b81e31137
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171580
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4858
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
According to vendor (Pascal Dornier) they're the same from coreboot
perspective.
Change-Id: I43aeb77f21c251b3d9c5c2dcfa01d4d1de0bc87b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5114
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Broken with/since commit d1cb0eec.
Original intention was to set the frequency for 'Fast Read' command
in bits 15..14, and enable 'Fast Read' command.
Modified register contains SPI frequency for 'Normal Read' command
in bits 13..12. Default for this is 11b for 16.5 MHz. Existing code
unintentionally clears these bits, increasing SPI frequency to 66MHz
for 'Normal Read' command.
This is above specifications for many common SPI flash components
and also makes flashrom older than 0.9.7-r1750 to operate unreliably
on read/write/erase for these platforms.
Change-Id: I30109e2a0410c0bb0bdc968ea71787396b32e761
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5089
Tested-by: build bot (Jenkins)
Reviewed-by: Kevin O'Connor <kevin@koconnor.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The added CPU's are OSA248CEP5AU and a OSP280 processors.
The OSP280 VID/FID numbers have been found by experimentation
and extrapolation/guesses from similar models. It has been
verified to work fine under Linux (OpenSuse 12.2, kernel
3.4.63-2.44) with four different test-processors.
Windows is untested.
Change-Id: I3afa1cba5f55c8a78917b3636382af7706a80fee
Signed-off-by: Oskar Enoksson <enok@lysator.liu.se>
Reviewed-on: http://review.coreboot.org/5095
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
|
|
During ramstage, call mainboard_get_gpios to get initial GPIO configuration
from the mainboard code, then initialize GPIOs as requested.
BUG=chrome-os-partner:22863
TEST=Manual. Using bayleybay GPIO table, set UART GPIOs to 'function 1',
and verify UART still works after GPIO configuration. Also, verify
legacy GPIO config is functional by toggling test pin.
Change-Id: Ic58d8ddd15c4dc48a751a83f6d26c7809c1efc42
Reviewed-on: https://chromium-review.googlesource.com/170306
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4855
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Port 2 is used by msata. Enable it.
Change-Id: Ib75227f64c9d77f6cfca1902a78d63b5cdd23d76
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4789
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This completes the improvements to the ELF file parsing code. We can
now parse section headers too, across all 4 combinations of word size
and endianness. I had hoped to completely remove the use of htonl
until I found it in cbfs_image.c. That's a battle for another day.
There's now a handy macro to create magic numbers in host byte order.
I'm using it for all the PAYLOAD_SEGMENT_* constants and maybe
we can use it for the others too, but this is sensitive code and
I'd rather change one thing at a time.
To maximize the ease of use for users, elf parsing is accomplished with
just one function:
int
elf_headers(const struct buffer *pinput,
Elf64_Ehdr *ehdr,
Elf64_Phdr **pphdr,
Elf64_Shdr **pshdr)
which requires the ehdr and pphdr pointers to be non-NULL, but allows
the pshdr to be NULL. If pshdr is NULL, the code will not try to read
in section headers.
To satisfy our powerful scripts, I had to remove the ^M from an unrelated
microcode file.
BUG=None
TEST=Build a peppy image (known to boot) with old and new versions and verify they are bit-for-bit the same. This was also fully tested across all chromebooks for building and booting and running chromeos.
BRANCH=None
Change-Id: I54dad887d922428b6175fdb6a9cdfadd8a6bb889
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181272
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5098
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The trailing whitespace breaks the Git commit hook
`util/lint/lint-stable-003-wihitespace`. So remove it.
Change-Id: I70e4ac71529884a9a4fabf2aa9a4ea6e0323b9d4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5092
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
The AGESA resumes the GPP ports in the romstage using FchInitResetGpp(),
which does FchGppPortInitS3Phase() for S3 resume. The PreInitGppLink()
looks into CMOS to figure out what ports to just force to Gen1 or
Gen2 PCIe. Then boot continues and in the ramstage the rest of GPP
init is executed. There is a problem that nobody sets properly the
PortDetected flags in the S3 path. As the consequence FchGppDynamicPowerSaving()
thinks the GPP port is not enabled and shut downs it.
The best fix would be also to remove the CMOS dependency which
might be some left over, because AGESA does not use CMOS much for
anything else. There could be also some way how to pass the GPP state
structure from romstage to ramstage possibly via hudson/resume.c
but I don't know how to do that. Similar problem is that the "late"
stage of init again "forgets" the PortDetected state.
This fix fixes the resume issue on Asus F2A85-M. With this patch applied
both GPP ports (used as PCIe x1 and internal ethernet) are working again
after resume.
Change-Id: Idaf609043abb09441c6790504d66d23e0637588f
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/4671
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
AT24RF08 was inherited from RE of original BIOS. As we don't really care
if the chip in question is really AT24RF08 or a generic replacement,
we can skip this check.
Change-Id: I862dd66b2332314beb835f215f1c1cd838aa07b9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4769
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: I4e56f6b37314bff569728b732b4115fb940f70dd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4756
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
imc_reg_init: init fan control related registers.
enable_imc_thermal_zone: AGESA does not enable thermal zone. We enable
it here.
Change-Id: I93c729982d78b6d2c7c20bcb1a3e27a7dd0eba91
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/4300
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
|
|
EEPROM/RFID chip present in thinkpad should be locked in a way to avoid
any potential RFID access.
Read serial number, UUID and P/N from EEPROM.
This info is stored on AT24RF08 chip acessible through SMBUS.
Change-Id: Ia3e766d90a094f63c8c854cd37e165221ccd8acd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4774
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
|
|
Change-Id: I045f1cff794d3c965c502fff98dd2442af2143bd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4839
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
|
|
Change-Id: Iaab076cc014a1ee463866c243636f4f71798ddc4
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4838
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
|
|
Many of SMBus functions are unavailable on many controllers.
While calling unavailable function is bad, it shouldn't lead
to spectacular crash.
Change-Id: I7912f3bbbb438603893223a586dcedf57e8a7e28
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4837
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
|
|
Found in some X201t.
Tested on X201t.
Change-Id: I3fc4c3f5b1abf9fe61746ab8f401d1b6ee67f3ea
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5090
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The pattrs structure is intended for the supporting coreboot
code to reference instead of going back to the source of
the values (msrs, cpuid, etc). It essentially serves as a global
structure for collecting attributes about the platform/processor.
Additionally, the implementation provides a point during boot to
hoook work before device enumeration/initialization by providing
a init() function to soc_intel_baytrail_ops that is called before
device work in the boot state machine.
BUG=chrome-os-partner:22862
BUG=chrome-os-partner:22863
BRANCH=None
TEST=Built and booted. Noted pattrs output.
Change-Id: I073da8aca29635146fb0d4a2625b2b7564fd8414
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170403
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4854
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The dunit on baytrail is the dram unit. Provide a means
to access the configuration registers there using the
proper IOSF mechanisms.
BUG=chrome-os-partner:22875
BRANCH=none
TEST=Built and booted. Able to read dram registers.
Change-Id: I4d5c019720a7883fe93f3e1860bcd57ce2ea6542
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170490
Reviewed-on: http://review.coreboot.org/4853
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Prior to this commit the coreboot resource allocator
was not using proper addresses. That's not surprising there
wasn't any code to initialize the resources properly. This
commit initializes the memory map accoring to the BUNIT
registers.
BUG=chrome-os-partner:22860
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted. Noted output for resource assignments
is sane.
Change-Id: Ice8d067d8b993736de5c5b273a0f642fa034a024
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170429
Reviewed-on: http://review.coreboot.org/4852
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The coreboot device modeling for pci devices wants
a pci_operations structure for all devices. This structure
just sets the subsystem vendor and device id. Add a common
one that all the other pci drivers can use for Bay Trail.
BUG=chrome-os-partner:22860
BRANCH=None
TEST=Built and booted while utilizing this new structure.
Change-Id: I39949cbdb83b3acb93fe4034eb4278d45369e321
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170428
Reviewed-on: http://review.coreboot.org/4851
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The graphics device needs to have its resource contraints
initialized before running the reference code. Right now just
use a 256MiB aperture, 32MiB of stolen memory data, and 2MiB
GTT memory.
BUG=chrome-os-partner:22869
BRANCH=None
TEST=Built and booted. Noted amount of stolen memory matches
configuration as well as BAR size within the graphics
device.
Change-Id: I328bf858f288363187cf705d6340947393b5ff10
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170427
Reviewed-on: http://review.coreboot.org/4850
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Take advantage of the cache early in bootblock. The
intent is to speed up cbfs walking when trying to locate
romstage.
BUG=chrome-os-partner:22857
BRANCH=None
TEST=Built and booted.
Change-Id: If03210103c9782390230915db3b4a9759d172dce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170426
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4849
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
B2 and B3 steppings are now bumped to version 313.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built.
Change-Id: I09ae5110b66c725e959e95fc15bc85ccf371495d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4848
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>
|
|
In the past the turbo disable setting (bit 38) of the
IA32_MISC_ENABLES msr has been package scoped. That means
knocking the turbo disable bit down enabled turbo for the
entire package. Sadly, that's no longer true on all Intel
processors. Therefore, allow non-packaged scoped turbo
setting by introducing the CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED
Kconfig option. It defaults to false which was the original
assumption.
BUG=chrome-os-partner:25014
BRANCH=baytrail
TEST=Built and ran both ways successfully.
Change-Id: I71a31e76ff47878023081fc47da643187517b597
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182405
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5047
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
In order for the cpu code to start SMM relocation 2 new
functions are added to be shared:
- void smm_initiate_relocation_parallel()
- void smm_initiate_relocation()
The both initiate an SMI on the currently running cpu.
The 2 variants allow for parallel relocation or serialized
relocation.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi using these functions.
Change-Id: I325777bac27e9a0efc3f54f7223c38310604c5a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173982
Reviewed-on: http://review.coreboot.org/4891
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
The Bay Trail SMM save state revision is 0x0100.
Add support for this save state area using the
type named em64t100_smm_state_save_area_t.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted using this structure with forthcoming CLs.
Change-Id: Iddd9498ab9fffcd865dae062526bda2ffcdccbce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173981
Reviewed-on: http://review.coreboot.org/4890
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Provide a common entry point for bringing up the APs
in parallel. This work is based off of the Haswell one
which can be moved over to this in the future. The APs
are brought up and have the BSP's MTRRs duplicated in
their own MTRRs. Additionally, Microcode is loaded before
enabling caching. However, the current microcode loading
support assumes Intel's mechanism.
The infrastructure provides a notion of a flight plan
for the BSP and APs. This allows for flexibility in the
order of operations for a given architecture/chip without
providing any specific policy. Therefore, the chipset
caller can provide the order that is required.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted on rambi with baytrail specific patches.
Change-Id: I0539047a1b24c13ef278695737cdba3b9344c820
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173703
Reviewed-on: http://review.coreboot.org/4888
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4876
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
In order to incorporate external blobs into
CBFS besides MRC have a notion of a reference code
blob. By selecting HAVE_REFCODE_BLOB and providing
the file name the refcode blob will be added to
cbfs as a stage file.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Using this option and other patches able to build,
boot, and run blob code.
Change-Id: I472604d77f4cb48f286b5a76b25d8b5bfb0c7780
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174423
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4895
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Some boards need to override which IRQ the i8042 keyboard
controller has its interrupt on instead of the default
IRQ#1. The SIO_EC_PS2K_IRQ macro provides the mainboard
an ability to override the interrupt location.
BUG=chrome-os-partner:23965
BRANCH=None
TEST=Built and booted rambi using this option. New IRQ is correctly
picked up by kernel allowing keyboard support.
Change-Id: Ic2b222018dfc3aa30e24a31009e832ae0fb7e9cf
Reviewed-on: https://chromium-review.googlesource.com/177222
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4978
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
FixedIO seems like a nice short version of IO but in reality
it is limited to 10-bit ISA addresses and so should not really
be used in most situations.
Change all the references to use IO() directly instead.
BUG=chromium:311294
BRANCH=none
TEST=emerge-samus chromeos-coreboot-samus and check for iasl
warnings using updated iasl compiler revision 20130117.
Boot the imge and ensure that EC regions are still exported
in /proc/ioports.
Change-Id: I54de65892bed9e43dbba916990cf2b70c370843c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174810
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4910
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|