Add the onboard I2C devices for Slippy trackpad/lightsensor
and generate SMBIOS Type41 tables for them.
Add ACPI device for the trackpad to expose the interrupt map
to the OS so it can be used.
Configure interrupt GPIOs as PIRQ type and wake GPIOs as
just standard input type. The wake GPIO is reconfigured as
ACPI SCI in the specific device _DSW method. This prevents
the wake GPIO from generating a flood of SCI at runtime.
LTE_WAKE_L_Q and WLAN_WAKE_L_Q are left as ACPI SCI as these
are not repurposed interrupt pins so they are not generated
at runtime.
SIM_DET and ALS_INT_L are set as input since we don't have an
interrupt handler for them.
BUG=chrome-os-partner:19664
BRANCH=none
TEST=manual: tested on slippy with trackpad with additional
kernel changes to chromeos_laptop.c to initialize devices.
1) Ensure trackpad interrupt is functional and that there
is not a flood of ACPI SCI when trackpad does interrupt:
9: 1 0 0 0 IO-APIC-fasteoi acpi
37: 421 0 0 0 IO-APIC-fasteoi cyapa
2) Ensure that devices are exposed as wake capable:
Device S-state Status Sysfs node
TPAD S3 *enabled pnp:00:00
TSCR S3 *disabled pnp:00:01
3) Ensure that trackpad can wake from S3 by default, but
that it does not cause an immediate wake when entering suspend.
4) Ensure that trackpad can be disabled as a wake source with
echo TPAD > /proc/acpi/wakeup
Change-Id: Id562d20b54eeefec56040b8f70ef238911312628
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56622
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is an LPT-LP specific method that will enable a specific
GPIO as an ACPI SCI wake source.
It can be used by a device _DSW method to enable a pin that is
otherwise not configured to generate SCI at runtime.
It will set:
- GPIO owner to ACPI
- GPIO route to SCI
- GPIO config to GPIO, Input, Inverted
Also clean up and remove ACPI field definitions that are unused
and/or incorrect.
BUG=chrome-os-partner:19664
BRANCH=none
TEST=manual: This commit just adds a new method but does not use it.
Followon commit will make use of this to enable wake from trackpad.
Change-Id: I14acc2de50e6200f61c2898a7bd1252400e0f0be
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56621
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
LynxPoint-LP has an additional 16 entries in the IOAPIC that
can be assigned to specific GPIOs when they are configured
as PIRQ.
The maximum redirection entries field in the IOAPIC needs to
be set to 0x27 when this is enabled.
Additionally specific GPIOs need to be routed to PIRQ so they
interrupt via the IOAPIC instead of the GPIO IRQ 14/15.
BUG=chrome-os-partner:19664
BRANCH=none
TEST=manual: nothing specific changes with this commit, but
it is used with a series of commits to enable the trackpad
interrupt on slippy.
Change-Id: Ie587e1d203422ff6fb7fc5056d20a5ae66720991
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56620
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The LynxPoint southbridge ACPI code needs the SSDT2 table to function
properly. Otherwise the ACPI evaluator in the kernel spews errors.
BUG=None
BRANCH=None
TEST=Booted and noted no more ACPI errors.
Change-Id: I73918545a07e43f4a281ff34d8537340d601b102
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56601
Mainboards were defining their own SMBIOS type41
write function. Instead pull this into the generic
SMBIOS code and change the existing mainboards to
make use of it.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: emerge-{link,parrot,butterfly}
chromeos-coreboot-{link,parrot,butterfly}
Change-Id: I3c8a95ca51fe2a3118dc8d1154011ccfed5fbcbc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56619
Reviewed-by: Stefan Reinauer <reinauer@google.com>
A parrot device with a bad flash part has been seen to hang
in the elog_shrink code becuase the flash was not successfully
erased and it gets stuck in a loop trying to shrink the log
and then add an event.
BUG=chrome-os-partner:18852
BRANCH=parrot
TEST=manual: power cycle testing on device with bad flash
Change-Id: I8bb13dbadd293f9d892f322e213c9255c8e9acb3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56405
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Update and use the new pei_data data structure. Now that the
reference code is fixed it's possible to properly disable/enable
the USB2 and USB3 ports correctly.
BUG=None
BRANCH=None
TEST=emerge slippy. All USB connections available to me still work. Both
USB3 and USB2. Other boards assumed to work.
Change-Id: I075c646e7574be354420b6e59507e8917a97d0f0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56594
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
- Only the first two DIMM SPDs are specified so far
- GPIO map is updated
- iSSD power sequencing removed
- USB port map updated
BUG=chrome-os-partner:19637
BRANCH=none
TEST=manual: emerge-falco chromeos-coreboot-falco
Change-Id: I4172460d3b075bfd5bb22013a6225cf0e8f95b9c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56329
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Minor tweaks to variable names in the slippy mainboard
that make it easier to base a new board from without
as much renaming.
Also properly set up the thermal variables for the
thermal zone that is defined in ACPI instead of using
the generic setup from WTM2.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: emerge-slippy chromeos-coreboot-slippy
Change-Id: I752c1a50bfdc06b6ddad95bd1331c6870b9f9df2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56328
The ssdt2 generation code was calling acpigen_patch_len().
However, none of the entries had AML object lengths that
needed patching. That resulted in the following message:
ASSERTION FAILED: file 'src/arch/x86/boot/acpigen.c', line 52
Additionally, this caused an errant write to a memory address
whose value was in the variable ltop. This was the 0 address.
BUG=chrome-os-partner:18635
BRANCH=none
TEST=Built and booted. Noted no more error message.
Change-Id: I44abf5a4e4225220575aee6b5c9bb6b0be093a28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56299
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The ACPI code was defining two EHCI controllers and ignoring
the XHCI controller. This changes the second EHCI controller
to be XHCI instead and changes the wake resource to indicate
S3 and not S4.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: cat /proc/acpi/wakeup
Device S-state Status Sysfs node
HDEF S4 *disabled pci:0000:00:1b.0
EHCI S3 *enabled pci:0000:00:1d.0
XHCI S3 *enabled pci:0000:00:14.0
Change-Id: If28775e6ef8608c22c85ca91d91d1f598ec7755d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56263
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The new code is stolen from U-Boot with little or no understanding of how it
works.
BUG=chrome-os-partner:16132
TEST=Built for pit. Verified that boot progressed past clock initialization.
BRANCH=None
Change-Id: I3f826e799529adee89898015af9e3f3a5114b7f5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55570
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This function had been declared in a public header file, but was marked
static when actually defined.
BUG=chrome-os-partner:16132
TEST=Built for pit.
BRANCH=None
Change-Id: I7cc9e583c20e54c926b805fcc49b06b629c8a508
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55569
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The UART doesn't seem to be working early on boot.
BUG=chrome-os-partner:16132
TEST=Built for peach.
BRANCH=None
Change-Id: Iadc42e4bbb8d99e321751f081bbfeb1701011802
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55568
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
- 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=not yet, pit is still in early bringup.
BRANCH=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I8165622580e1fbe76e1ad06805dc87b4a06b27d8
Reviewed-on: https://gerrit.chromium.org/gerrit/55808
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The architecture name for our ARM port is armv7, not arm.
Hence, none of those flags were ever actually used.
Fix the architecture name and remove the flags, they should
not be set in xcompile, but in the Makefile, like in coreboot.
BUG=chrome-os-partner:18635
TEST=compile tested
BRANCH=none
Change-Id: Id9c5db7ebceafddb58a1ce1988417f09c074ba6c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56084
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This will log and clear EC events so they do not take effect
when the SMI handler is enabled.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: ensure system does not shut down when booting
after lidclose/lidopen sequence on EC console.
Change-Id: I5ef563f7cedc8977410cc3f69e2655fc4e14c9eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56055
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
