When modifying the page tables, use writel to ensure the writes happen, flush
the page tables themselves to ensure they're visible to the MMU if it doesn't
look at the caches, and invalidate the right TLB entries.
The first two changes are probably safer but may not be strictly necessary.
The third change is necessary because we were invalidating the TLB using i
which was in megabytes but using an instruction that expects an address in
bytes.
One symptom of this problem was that the framebuffer, which was supposed to be
marked uncacheable, was only being partially updated since some of the updates
were still in the cache. With this change the graphics show up correctly.
BUG=None
TEST=Built and booted on Snow. Verified that vboot screens were displayed
completely.
BRANCH=None
Change-Id: I9f3c3d3d1547b85d5b2d7035050a5107ead1f236
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55638
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already known
when that structure was put together. Eliminate the extra space, and pass the
single value instead of the structure.
BUG=None
TEST=Built and booted on Snow.
BRANCH=None
Change-Id: Ied4d293cd96dfd93543aa523b8c3a14aec7080f5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55637
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
The page tables need to be aligned to a 16KB boundary and are 16KB in size.
The CBMEM allocator only guarantees 512 byte alignment, so to make sure
things are where they're supposed to be, the code was allocating extra space
and then adjusting the pointer upwards. Unfortunately, it was adding the size
of the table to the pointer first, then aligning it. Since it allocated twice
the space of the table, this had the effect of moving past the first table
size region of bytes, and then aligning upwards, pushing the end of the table
out of the space allocated for it.
You can get away with this if you push things you don't care about off the
end, and it happened to be the case that we were allocating a color map we
weren't using at the start of the next part of cbmem.
BUG=None
TEST=Built and booted on Snow
BRANCH=None
Change-Id: I13e28e015a3acf0dbb627aa5eff5f99bf4211ce6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55636
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Coreboot knows that, for the snow board, certain pins are to be connected to
bus controllers in the SOC and to the wires of a bus external to the SOC. It
can configure them as such and free its payload from having to know how to
set everything up.
BUG=None
TEST=Built and booted on Snow.
BRANCH=None
Change-Id: Ia39cc5d0909f1be86dee828c0419bffa16edb69b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55635
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
These pins will be driven by the internal controller which shouldn't have pull
ups or downs in the pin fighting with them.
BUG=None
TEST=Built and booted on snow.
BRANCH=None
Change-Id: Ia0fc84cd4575e80b2148dce27e14bb7e5042d473
Reviewed-on: https://gerrit.chromium.org/gerrit/55634
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
The vendor ids were never updated to reflect LynxPoint's device
ids. Therefore, none of the initialization was being ran. Fix
this.
BUG=chrome-os-partner:19555
BRANCH=None
TEST=Booted and noted the codec was attempted to be initialized.
Change-Id: Ic6ec00c9fb1cbcb6087fd89b0acff3d83294ac6a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55821
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BUG=chrome-os-partner:16132
TEST=Built for pit and verified that it was able to get past setting up the
pinmux for the serial port which it wasn't before. Used some primitive checks
to verify that some of the registers being modified were in the right place.
BRANCH=None
Change-Id: I2fff71d821a6ed092cd2ecbd197a93e2189e6596
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55567
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
BUG=none
TEST=boot tested on Snow, no serial garbage and no multiple UART
init in bootblock.
BRANCH=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I3c203fa541ea5fffa2ae38943278d6358db45379
Reviewed-on: https://gerrit.chromium.org/gerrit/51497
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
This change adds a pit mainboard which is mostly a copy of snow, except that
mentions of the 5250 were replaced with the 5420, and mentions of snow were
replaced with pit.
BUG=chrome-os-partner:19420
TEST=With this and other changes, built for pit.
BRANCH=None
Change-Id: I59fb42b291cee54fe3ea217a2c87a45fef021fbe
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51460
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Some of the settings which were defaulted to or automatically selected for the
exynos5420 which were inherited from the exynos5250 were not correct for this
SOC.
BUG=chrome-os-partner:19420
TEST=With this and other changes, built a pit image for this CPU.
BRANCH=None
Change-Id: I2ea6d7a2531100348c365347b92bdcab8125ab4a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51459
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This change creates an exynos5420 directory with code that will eventually
implement support for the exynos5420 cpu from Samsung. Currently it's a copy
of the exynos5250 directory with the name changed. There are going to be some
problems where headers in src/cpu/samsung/exynos-common include headers in the
exynos5250 directory directly.
BUG=chrome-os-partner:19420
TEST=With this and other changes, built a pit image which uses this CPU.
BRANCH=None
Change-Id: Ib793edea2709fecbbc31e3178a0d3887f2e277b5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51458
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The haswell code allows for vboot ramstage verification.
However, that code path relies on accessing global cache-as-ram
variables after cache-as-ram is torn down. In order to avoid
that situation enable cache-as-ram migration.
cbmemc_reinit() no longer needs to be called from romstage
because it is invoked automatically by the cache-as-ram
migration infrastructure.
BUG=chrome-os-partner:19342
BRANCH=none
TEST=Built and booted. Noted that CAR values are not read incorrectly.
Change-Id: I1a8de380a70d8b375ba138da3219408ef5c823b7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51390
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Allow for automatic cache-as-ram migration for the cbmem
console. The code was refactored in the thought of making
it easier to read. The #ifdefs still exist, but they are no
longer sprinkled throughout the code. The cbmem_console_p
variable now exists globally in both romstage and ramstage.
However, the cbmem_console_p is referenced using the
cache-as-ram API. When cbmem is initialized the console
is automatically copied over by calling cbmemc_reinit()
through a callback.
BUG=chrome-os-partner:19342
BRANCH=none
TEST=Built and booted. Noted that CAR values are not read incorrectly.
Change-Id: I73581599fb6c9ecc36c301c3a30154d80b36f172
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51389
Reviewed-by: Stefan Reinauer <reinauer@google.com>
It's possible that the vbnv global variables may be accessed
in romstage after cache-as-ram is torn down. Therefore use
the cache-as-ram migration API. Wrappers were written to
wrap the API to keep the existing code as close as possible.
BUG=chrome-os-partner:19342
BRANCH=none
TEST=Built and booted. Noted that CAR values are not read incorrectly.
Change-Id: I00fa4128fd2f197f238f38814b158ffc3387ea48
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51388
Reviewed-by: Stefan Reinauer <reinauer@google.com>
As the TPM driver can be accessed in romstage after
cache-as-ram is torn down use the cache-as-ram migration
API to dynamically determine the global variable address.
BUG=chrome-os-partner:19342
BRANCH=none
TEST=Built and booted. Noted that CAR values are not read incorrectly.
Change-Id: I1333f5456976edae647ede5fdefd60d806861fe1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51387
Reviewed-by: Stefan Reinauer <reinauer@google.com>
There are some boards that do a significant amount of
work after cache-as-ram is torn down but before ramstage
is loaded. For example, using vboot to verify the ramstage
is one such operation. However, there are pieces of code
that are executed that reference global variables that
are linked in the cache-as-ram region. If those variables
are referenced after cache-as-ram is torn down then the
values observed will most likely be incorrect.
Therefore provide a Kconfig option to select cache-as-ram
migration to memory using cbmem. This option is named
CAR_MIGRATION. When enabled, the address of cache-as-ram
variables may be obtained dynamically. Additionally,
when cache-as-ram migration occurs the cache-as-ram
data region for global variables is copied into cbmem.
There are also automatic callbacks for other modules
to perform their own migration, if necessary.
BUG=chrome-os-partner:19342
BRANCH=none
TEST=Built and booted. Noted that CAR values are not read incorrectly.
Change-Id: Ie0104a6e24cc6430a575ee3691671900c36db0d9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51386
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The dev screen was not displaying properly. With the
PWM values programmed the screen displays correctly.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=Noted PWM is functional during dev screen in BIOS.
Change-Id: I82b56a92e4168022082a2e519026977ee2ae0c9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51472
The Exynos GPIO code has three different APIs that, unfortunately,
were widely used throughout the code base. This patch is cleaning
up the mess.
BUG=none
TEST=booted on Snow
BRANCH=none
Change-Id: Iafc0a27ee5266a397abfd0aa2abdb88a63298384
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51371
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
BUG=none
TEST=booted on Snow
BRANCH=none
Change-Id: I7581e9005e09ad264f85d57b6771f40faa2e63af
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51216
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
The device at function 0 also needs to be enabled
or the kernel will ignore all other functions.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: ensure devices show up in PCI list
00:15.0 DMA controller: Intel Corporation Lynx Point-LP Low Power Sub-System DMA (rev 03)
00:15.1 Serial bus controller [0c80]: Intel Corporation Lynx Point-LP I2C Controller #0 (rev 03)
00:15.2 Serial bus controller [0c80]: Intel Corporation Lynx Point-LP I2C Controller #1 (rev 03)
Change-Id: I0e1bc7bb719756496c46664d66dc1b1cf2f4d1ba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51370
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to report whether coreboot enabled a SerialIO device
in ACPI mode we had been relying on reading NVS in the _STA
method for the SerialIO device.
The ACPI _STA method has restrictions on what it can access
and is unable to access OperationRegions outside its scope
which means it should not be trying to read NVS.
This change adds a new SSDT to the ACPI tables and fills it
with constants that indicate whether or not a device is enabled
in ACPI mode.
The ACPI code is changed to read these variables from the
SSDT and use that instead of trying to query a variable in NVS.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: Attempt to use lpt-clk driver to probe the
device clocks for SerialIO devices and see that the kernel
does not complain about accessing the GNVS region.
Change-Id: I8538bee4390daed4ecca679496ab0cb313f174ce
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Thread support is added for the x86 architecture. Both
the local apic and the tsc udelay() functions have a
call to thread_yield_microseconds() so as to provide an
opportunity to run pending threads.
BUG=None
BRANCH=None
TEST=Built
Change-Id: I9d65a8e67ffdee5fd813f7554ecafbdf37b93af0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51163
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
The cooperative multitasking support allows the boot state machine
to be ran cooperatively with other threads of work. The main thread
still continues to run the boot state machine
(src/lib/hardwaremain.c). All callbacks from the state machine are
still ran synchronously from within the main thread's context.
Without any other code added the only change to the boot sequence
when cooperative multitasking is enabled is the queueing of an idlle
thread. The idle thread is responsible for ensuring progress is made
by calling timer callbacks.
The main thread can yield to any other threads in the system. That
means that anyone that spins up a thread must ensure no shared
resources are used from 2 or more execution contexts. The support
is originally intentioned to allow for long work itesm with busy
loops to occur in parallel during a boot.
Note that the intention on when to yield a thread will be on
calls to udelay().
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I980a6daf8ea3f0475124329253ace2695fc39aa7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51162
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
It turns out that the exynos5-common code previously imported from
u-boot is not common code at all but very specific to the 5250 and
not compatible with the 5450. Hence, unify the directories exynos5250
and exynos5-common. We will try to factor out common code while
progressing with the 5450 port.
BUG=none
TEST=boot tested on snow
BRANCH=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I5d4ae4533174d42802dc4d0af19b81224b89c9cd
Reviewed-on: https://gerrit.chromium.org/gerrit/51169
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
This patch unfortunately incorporates a number of changes,
all of which are making future ARM ports easier.
- drop cruft that came in with u-boot
- move serial console from mainboard Kconfig to Exynos Kconfig
- factor out non-board specific wakeup code
- move generic bootblock code from mainboard to Exynos
- actually call arch_cpu_init()
- remove dead code
- fix up copyright messages
- remove snow_ prefix from a lot of code to reduce the noise
when creating a new mainboard based on that code.
BUG=none
BRANCH=none
TEST=boot tested on snow
Change-Id: Ibc56b5bf7ec60ee730b32180ad9ef415438fffaf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50911
Reviewed-by: David Hendricks <dhendrix@chromium.org>
- Disable EC software sync for now
- Report correct EC active firmware mode
- Force enable developer mode by default
- Set up PCH generic decode regions in romstage
- Pass the oprom_is_loaded flag into vboot handoff data
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: Boot in developer mode
Change-Id: Ib7ab35e6897c19455cbeecba88160ae830ea7984
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51155
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These boards were returning 0 to indicate success when
the realmode handler expects it to return 1 to indicate
that it handled the interrupt.
BUG=none
BRANCH=none
TEST=emerge-link chromeos-coreboot-link
Change-Id: I2baeaf8c2774fa7668a8b2f2d9ad698302eefb21
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50881
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This was changed to 0x80000000 in SA BWG 1.5.0.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=build and boot on wtm2
Change-Id: Ic6773f45057f3eb93b2d93ee543e3db77fccf805
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50852
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
... and drop the wrapper on ARMv7
BUG=none
TEST=boot tested on snow
BRANCH=none
Change-Id: Ib2b4315b664292653f8cb898fc5633fce421deca
Reviewed-on: https://gerrit.chromium.org/gerrit/50728
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
In ram stage, all code flow should be tied to the resource allocator.
Stuff that has to happen before everything else goes into the mainboard
enable function in mainboard.c. This patch empties the main() wrapper
around hardwaremain.c, allowing to get rid of this special case in the
ARM port.
BUG=none
TEST=Boot tested on Snow
BRANCH=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I45537e871a51b1962b1fdd981296575eb863b07a
Reviewed-on: https://gerrit.chromium.org/gerrit/50727
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1]
made romcc not choke on function prototypes anymore. This
allows us to get rid of a lot of ifdefs guarding __ROMCC__ .
[1] http://review.coreboot.org/2424
BUG=none
TEST=boot tested on Link
BRANCH=none
Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50723
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
This option has not been enabled on any board and was considered
obsolete last time it was touched. If we need the functionality,
let's fix this in a generic way instead of a K8 specific way.
This was mostly a speedup hack back in the day.
BUG=none
TEST=not needed (inactive option dropped)
BRANCH=none
Change-Id: Ib1ca248c56a7f6e9d0c986c35d131d5f444de0d8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3211
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50722
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Since this parameter is not used anymore, drop it from
all calls to copy_and_run()
BUG=none
TEST=boot tested on snow+link
BRANCH=none
Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3213
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50721
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
it has been unused since 9 years or so, hence drop it.
BRANCH=none
BUG=none
TEST=boot tested on snow
Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3212
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50720
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
The cbfs core code would print out the name of the file it is
searching for and when it is found would print out the name
again. This contributes to a lot of unnecessary messages in a
functioning payload’s output. Change this message to a DEBUG one
so that it will only be printed when CONFIG_DEBUG_CBFS is enabled.
BUG=None
BRANCH=None
TEST=Compiled and booted.
Change-Id: I142166bfdfcb5e7f6dba6c1ecbd13f3c0ff15088
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50459
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
The smm_handler_t type was added before the introduction
of the asmlinkage macro. Now that asmlinkage is available
use it.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: I8a5c98b1ee2df69494ca4c671992e4c635d09a21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50458
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Since the TSC udelay() function can be used in SMM that means the
TSC can count up to whatever value. The current loop was not handling
TSC rollover properly. In most cases this should not matter as the TSC
typically starts ticking at value 0, and it would take a very long time
to roll it over. However, it is my understanding that this behavior is
not guaranteed. Theoretically the TSC could start or be be written to
with a large value that would cause the rollover.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: I0f86672e0951b51c791c63bb1173eb371b347f40
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50457
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Internally there were states that had an attribute to
indicate that the timers needed to be drained. Now that
there is a way to block state transitions rely on this
ability instead of draining timers. The timers will
drain themselves when a state is blocked.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: Idfeabcc5249ca315a48740652b8892e465d08990
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50456
Reviewed-by: Stefan Reinauer <reinauer@google.com>
In order to properly sequence the boot state machine it's
important that outside code can block the transition from
one state to the next. When timers are not involved there's
no reason for any of the existing code to block a state
transition. However, if there is a timer callback that needs to
complete by a certain point in the boot sequence it is necessary
to place a block for the given state.
To that end, 4 new functions are added to provide the API for
blocking a state.
1. boot_state_block(boot_state_t state, boot_state_sequence_t seq);
2. boot_state_unblock(boot_state_t state, boot_state_sequence_t seq);
3. boot_state_current_block(void);
4. boot_state_current_unblock(void);
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: I3de15e5b91e7fd1c833bc99b0d0af46a5a7c4bee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50455
Reviewed-by: Stefan Reinauer <reinauer@google.com>
When the haswell MP/SMM code was developed it was using a coreboot
repository that did not contain the asmlinkage macro. Now that the
asmlinkage macro exists use it.
BUG=None
BRANCH=None
TEST=Built and booted.
Change-Id: I2ebd567c7c40cf5013f2c1d7e3b381171ad17a4a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50454
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Some boards use the local apic for udelay(), but they also provide
their own implementation of udelay() for SMM. The reason for using
the local apic for udelay() in ramstage is to not have to pay the
penalty of calibrating the TSC frequency. Therefore provide a
TSC_CONSTANT_RATE option to indicate that TSC calibration is not
needed. Instead rely on the presence of a tsc_freq_mhz() function
provided by the cpu/board. Additionally, assume that if
TSC_CONSTANT_RATE is selected the udelay() function in SMM will
be the tsc.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: Ic7096b7f5c9dec26a3f0441e6715fe02b15d44db
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50453
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Instead of using the local apic timer for udelay() use the tsc.
That way SMM, romstage, and ramstage all use the same delay
functionality.
BUG=None
BRANCH=None
TEST=Compiled and booted
Change-Id: Iac35eb02b424b54e490b4fdaa2fc74f35066db27
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50452
Reviewed-by: Stefan Reinauer <reinauer@google.com>
These are both pulled up to 3.3V in the schematic.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=compile tested only, still need devices to test with
Change-Id: I12e055a39ff6100300c3d285899b8d6239e3773d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50356
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With the XHCI controller enabled we no longer hang the
system when dropping into a package C-state so remove
the code that was disabling it.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=boot wtm2 and verify package C2 residency with powertop
Change-Id: Icd60488fd2506dac04fb6ec96a77bec265b10d8c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50355
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The chromeos_acpi driver sysfs naming is not what
crossystem expects if there is just one entry in the package
because it does not add a ".#" suffix in that case.
Specify all the expected GPIOs on wtm2 as undefined, which
should be 0xFF and not 0x00 becuase 0 is a valid GPIO.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: build and boot image on wtm2 and
check for 3 GPIOs exposed in /sys/devices/platform/chromeos_acpi
Change-Id: I9b17e9bab94219695e65b17914c84acf02a0983b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50337
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current microcode blobs contain both ULT and non-ULT
revisions. Only include one or the other based off of the
CONFIG_INTEL_LYNXPOINT_LP Kconfig option.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-fox_wtm2 chromeos-coreboot-fox and inspected microcode
FIT entries.
Change-Id: I3e4e41d4cd727b1a974361fb469267e6f6022d5a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50318
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In order for the FIT entries to be populated in the table the
update-fit command needs to be done on the coreboot image. That
way the microcode entries are added to the table properly.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-fox_wtm2 chromeos-coreboot-fox and inspected microcode
FIT entries.
Change-Id: I44595aee1ca710f4f04d482d8900cf95fbc1797f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50317
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
We have the monotonic timer implemented on exynos now, and this
also enables helpful bootstage prints with timing info.
Change-Id: I3baa4c9d70d4b4d059abd5e05eddcabd5258dbfd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3210
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
