Enable GPIO SMI for GPIO34 and set it as inverted so it
is only generated when it is raised by the EC.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual:
1) ec console command: lidopen
2) wait until booted to developer screen
3) ec console command: lidclose
4) ensure system turns off
Change-Id: I7d50f171f3f4539c7c264103d1ffc7c5d0f1c7ba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56052
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SerialIO devices have specific requirements for PCI
interrupt mode to use PIRQ{E,F,G,H} that are not being met.
D21:F0 uses PIRQE, which must not be shared with other PCH
D21:F1-F6 share PIRQF, which must not be shared with other PCH
D23:F0 uses PIRQH, which must not be shared with other PCH
- Fix D20IR -> D20IP typo
- Remove D25/EHCI2 as it does not exist
- Reorder other interrupts to clear PIRQE/PIRQF/PIRQH
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: check device interrupts in the kernel
0: IO-APIC-edge timer
1: IO-APIC-edge i8042
8: IO-APIC-edge rtc0
9: IO-APIC-fasteoi acpi
16: IO-APIC-fasteoi ath9k
18: IO-APIC-fasteoi i801_smbus
19: IO-APIC-fasteoi ehci_hcd:usb1
21: IO-APIC-fasteoi i2c-designware-pci--1, i2c-designware-pci--1
40: PCI-MSI-edge PCIe PME
41: PCI-MSI-edge i915
42: PCI-MSI-edge ahci
43: PCI-MSI-edge xhci_hcd
44: PCI-MSI-edge snd_hda_intel
Change-Id: Id4c08d11d2860f270c6387138acdc7d3d83a85b5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56028
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With LynxPoint-LP the SCI GPE is no longer a GPIO
that is offset by 16. Remove the Add and fix up
the link definition so it is still accurate.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: ensure SCI is working on slippy
1) Enable ACPI_DEBUG and ACPI_EC_DEBUGFS in kernel config
2) cat /sys/kernel/debug/ec/ec0/io > /dev/null
3) cat /sys/firmware/acpi/interrupts/gpe24
512
Change-Id: I5c97a8397cdee8f081d690d930da2df61b4695f9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56027
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The USB ports are in USB2 mode in firmware and are using
the EHCI driver so we can disable this to save boot time.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=boot from usb on slippy
Change-Id: Ia9ee614281b6eab4dcb2ad098a248e2add5e7521
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56026
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In case we are going to use this in future designs.
BUG=none
TEST=none
BRANCH=none
Change-Id: I750addf10e4fe6f8240f8c8262253f8af7027e29
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55844
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BUG=chrome-os-partner:18635
TEST=Boot from USB in depthcharge on Snow
Change-Id: I472fbb9df22e4e1271d6c3a743744d4ee8a4f659
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49971
Restructure USB stack to not depend on PCI, and
make PCI stub available on x86, but provide fixed
BARs for ARM (Exynos 5)
BUG=chrome-os-partner:18635
TEST=Boot from USB in depthcharge on Snow
Change-Id: Iee7c8b134c22b661a9a515e24943470c9dbadd1f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49970
If we clear the framebuffer and then flush it back to memory using cache
operations, the writes are going to be full cachelines at a time. If we make
it uncacheable first, the writes will be serialized writes of whatever sized
chunks memset uses, probably 4 bytes or less.
BUG=None
TEST=Built and booted on Snow. Verified that graphics were drawn completely.
BRANCH=None
Change-Id: I94c81145b422eb440c7698273e7f3944c5ee486e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55640
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
At one time it seemed to be necessary to disable and then re-enable the MMU
when setting the framebuffer to be uncache-able due to bugs in the MMU
management code. Since those bugs have been fixed, this is no longer
necessary.
BUG=None
TEST=Boot on Snow and verified that graphics are still displayed correctly.
BRANCH=None
Change-Id: Ibfd12c1f45c57994cd970751be7aee106a5ff0a1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55639
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
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>
Two structures in the USB EHCI stack were pointing
to hardware but not marked attribute((packed)) hence
leaving it to GCC to correctly align the data structures.
Next, the number of reserved bytes in hc_op_t was wrong
(but implicitly aligned to the correct values on x86)
It seems this worked fine on x86, but on ARM it was doing
the wrong thing.
BUG=chrome-os-partner:18635
TEST=more changes needed
BRANCH=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I94bed4850ded7d3f7bbc7ff3079c103c6054c22d
Reviewed-on: https://gerrit.chromium.org/gerrit/55555
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>
BUG=chrome-os-partner:19420
TEST=With this and other changes, built for peach pit.
BRANCH=None
Change-Id: I81a02a3d9329fb7125909d286c670538fcb49fd2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51464
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
BUG=chrome-os-partner:19420
TEST=With this and other changes, built for peach pit.
BRANCH=None
Change-Id: Id262028b03dca49e5e7c347f2a79b01bfe777fa2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51463
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The libpayload config files are now identified by both the board and variant,
so this config file is no longer needed.
BUG=chrome-os-partner:19420
TEST=Built for wtm2.
BRANCH=None
Change-Id: I97a5cca21ae70b881deb55edc9675a278524d795
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51462
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
It may be necessary to use different config settings for different variants
of the same board. We should make it possible to use different config files
depending on the variant. This might lead to a number of similar or identical
configs if the variants don't actually vary very much, but hopefully if we've
gone to the trouble of identifying them separately there are some meaningful
differences.
The fox boards are the only ones currently supported by libpayload that
actually have variants.
BUG=chrome-os-partner:19420
TEST=Built for wtm2 with a change to the ebuild to use the new names.
BRANCH=None
Change-Id: Ic445e80be26ecdd348dc1de7d6a351ab6f9f2cba
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51461
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
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>
As choice dependency are now fully checked, it's quite easy to add support
for named choices. This lifts the restriction that a choice value can only
appear once, although it still has to be within the same group,
but multiple choices can be joined by giving them a name.
While at it I cleaned up a little the choice type logic to simplify it a
bit.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
BUG=None
TEST=Built for Pit, Link, Fox.
BRANCH=None
Change-Id: I3b03b9992094d0a21fb768597e0afddd664e946d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51056
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Properly check the dependency of choices as a group.
Also fix that sym_check_deps() correctly terminates the dependency loop
error check (otherwise it would continue printing the dependency chain).
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
BUG=None
TEST=Built for Pit, Link, Fox.
BRANCH=None
Change-Id: I71eba60a4124232dc825e924d0424b52f80d2928
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51055
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Fix reversal of dlg.border.atr and dlg.dialog.atr for draw_box()
Makes the inputbox look like expected
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
BUG=None
TEST=Built for Pit, Link, Fox.
BRANCH=None
Change-Id: Id1d0bbc7a06515f1f5a4acb904b188dcbaf0f191
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51054
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@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>
