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 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>
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>
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 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>
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>
Aaron Durbin