Since CL:226662, all TPMP accessing should be removed as well,
else it will cause fox_wtm2 coreboot failed on build.
BUG=none
BRANCH=none
TEST=./setup_board --board=fox_wtm2 && emerge-fox_wtm2 coreboot
CQ-DEPEND=CL:226662
Change-Id: Ia0eebb1924bbb23979c880f7d05600a0cf1e4ca3
Signed-off-by: Harry Pan <harry.pan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/232165
Reviewed-by: Wei Shun Chang <wei.shun.chang@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
It can't compile due to tpmp flag was removed in nvs.h
BRANCH=none
BUG=none
TEST=compile ok and boot to OS on pearlvalley
Signed-off-by: Kane Chen <kane.chen@intel.com>
Change-Id: I718b70c6194365ee19b93224b52b7bcf3a5055d0
Reviewed-on: https://chromium-review.googlesource.com/228975
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Kane Chen <kane.chen@intel.com>
Tested-by: Kane Chen <kane.chen@intel.com>
Empty functions are provided when !CONFIG_COLLECT_TIMESTAMPS
so stop guarding the compilation.
BUG=None
BRANCH=None
TEST=Built
Change-Id: Ib0f23e1204e048a9b928568da02e9661f6aa0a35
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228190
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This code change is trying to avoid system hang due to "no enough MTRRs"
This is based on https://chromium-review.googlesource.com/174653
BUG=chrome-os-partner:33417
BRANCH=None
TEST=compile ok, make sure MTRRs are enough for memory regions.
Check 4GiB memory usage by cat /proc/meminfo
Change-Id: Ide8177577314fddceaf20e14615b745d888b3743
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/226511
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
This patch aligns baytrail to the new SoC header include scheme.
BUG=None
TEST=Tested with whole series. Compiled Rambi.
Change-Id: If5d2a609354b3d773aa3d482e682ab97422fd9d5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222026
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns broadwell to the new SoC header include scheme.
BUG=None
TEST=Tested with whole series. Compiled Auron and Samus.
Change-Id: I613ec0e2b970c75d1f8f7d9bb454bcf11abc78f0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224507
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
according to schematic, GPIO29 needs to output high to enable M.2
socket power
BUG=none
BRANCH=none
TEST=build ok and see wifi device on M.2 socket working in OS
Change-Id: I7f122541a7bf3a5d7872f37a866ea3f1e52e8b47
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/221927
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This introduces a new kconfig variable to select the VBNV backing
store explicitly instead of inferring it from CPU/SoC architecture.
x86 platforms have historically relied only on CMOS to store VBNV
variables, while ARM-based platforms have traditionally relied on
the EC. Neither of those solutions are going to scale well into
the future if/when CMOS disappears and we make ARM-based systems
without an EC.
BUG=chrome-os-partner:29546
BRANCH=none
TEST=compiled for nyan_blaze and samus
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I4a8dadfb6bb666baf1ed4bec98b29c145dc4a1e7
Reviewed-on: https://chromium-review.googlesource.com/213877
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
No need to define these everywhere, one place will serve all uses.
BUG=none
TEST=compiled various targets without any problem
Change-Id: Iabf31baad6049c758e078727ba3ebe830c3c7684
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210921
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a quick port from wtm2 to test on the broadwell Y CRB.
Note that it produces an 8MB image and yet the board has a
16MB SPI flash part. The build tools are not ready to handle
a 16MB image yet so just add 8MB of FFs to the end for now.
BUG=chrome-os-partner:28234
TEST=boot on pearl valley
Change-Id: I849075fc07fa017b5ccca17d0736342a1518db7d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210661
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
XHCI driver was not enabled in libpayload and some ports were
disabled that should be enabled.
The Chrome OS GPIOs also need to be reported as 0xFFFFFFFF to
properly indicate unused so crossystem does not attempt to
export GPIO number 255 in the kernel and trigger a warning.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2
Change-Id: Ib5727ef6e618c959640b200757cfa13f95c7cb0f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203184
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This commit includes bayleybay board related settings for bring up baytrail crb
BUG=none
TEST=emerge-bayleybay coreboot chromeos-bootimage compile ok.
It can boot to dev chromium desktop without verify boot(due to no TPM built in bayleybay)
Change-Id: I659293d7a8fcdae40b60fd127e19b7284e75aa10
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/201002
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Convert wtm2 board to use the broadwell soc chipset.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2 with haswell and broadwell
CQ-DEPEND=CL:201067
CQ-DEPEND=CL:*164226
Change-Id: Ifb0db15cc23a3b66430b32b2ad3f8ab2fb03c4c3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201070
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CONFIG_ARCH is a property of the cpu or soc rather than a property of the
board. Hence, move ARCH_* from every single board to respective cpu or soc
Kconfigs. Also update abuild to ignore ARCH_ from mainboards.
BUG=None
BRANCH=None
TEST=Compiled successfully for all mainboard/google boards. Successfully booted
link image.
Change-Id: I42323ac33c236d26654a26b591378781aeecabd4
Reviewed-on: https://chromium-review.googlesource.com/195350
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Baytrail has a configurable SCI irq. Add support for
properly configuring SCI irq. Note that it is currently
fixed to IRQ9, but the code supports setting it to the
other supported values. The current mainboards using
baytrail defer the madt IRQ override information to the
chipset.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted. Noted 'SCI is IRQ9' message.
Change-Id: I7b307bd58f9de944f0cb4c116107a15345499f2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176075
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The FADT for baytrail had incorrect offsets leading to
the kernel spewing a huge mess of ACPI errors. Fix these offsets
to be initialized in the chipset code.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted into kernel on rambi. Login screen comes up.
Change-Id: I89fc2a4fd800ff01cedf89b51cfb1369aceb9f03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175663
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This provides the initial support for interrupt routing
in bay trail. It includes both acpi changes and board changes
to ensure the interdependencies are met with the current ASL
code. The PIRQ routing is handled by the mainboard exporting
an irqroute.h header that describes the per device and PIRQ
PCI settings.
There are still a lot of ACPI errors in the kernel with this
change, though.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted rambi into kernel.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Id8a865a24fc8d49743c0b54efdb64aaef52fcd8e
Reviewed-on: https://chromium-review.googlesource.com/175700
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There is a lot of NVS allocated to things that are not really
used. Most of these are removed and some are moved around.
Thermals are expected to be handled with DPTF so I've removed
that bit of code but have not yet cleaned up the thermal zone.
I left in the SIO BARs since I think we will need those still
even though they may need work still.
BUG=chrome-os-partner:23505
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: Id16ee67e6b3709a303c001afd72947147f938127
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175626
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The callers of the following functions assume the storage
area provided by the pointers is initialized. That's not the
case as these were just place holders.
- void acpi_create_intel_hpet(acpi_hpet_t * hpet);
- void acpi_create_serialio_ssdt(acpi_header_t *ssdt);
To fix this properly initialize the hpet entry, and just remove
the serialio_ssdt function entirely.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted through depthcharge on rambi. Noted no more
ACPI errors relating to invalid length.
Change-Id: If56ab033562ef2d755e9c9de42f507c95d291aba
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174716
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There's some baked in assumptions internal to coreboot
that the BSP's cpu device exists in the device tree. Therefore
provide one in the device tree.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Compiled and booted with other changes.
Change-Id: I22ba10964760ee8efbc5bbd5d4ce65daf31b3839
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173702
Minor style changes to the way GPIO pull-ups are specified in
board-specific GPIO maps. Intent is to allow calls to GPIO_FUNC macro
from such maps.
BUG=chrome-os-partner:22863
TEST=Manual. Build + boot on bayleybay.
Change-Id: I80134b65d22d3ad8a049837dccc0985e321645da
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173748
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
The currently used Bay Trail devices comply with eMMC 4.51
specification and as such require the appropriate GPIOs to be
configured for func3.
Note that the CMD line termination requires 2K, otherwise when driven
by the eMMC device the front slope of the pulse in unacceptably
gentle.
BUG=chrome-os-partner:22580
TEST=manual
. with u-boot SDHCI driver implemented, the eMMC device on the
Bayley Bay CRB can be initialized and mounted
Change-Id: Ib53b6e42d8558c9ca2dff4b6bbf3bcf6fd22e136
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173241
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
The graphics.c file was never used. Just remove it.
BUG=chrome-os-partner:23121
BRANCH=None
TEST=built.
Change-Id: Ia6bc6251c76074dd73357564d22480122b6a3bb8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171930
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.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
and 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>
Configure all GPIOs as default (function 0), except for SMBus / UART
GPIOs.
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: I429e0b161767af296e7ff69ecbfde2c3a1c2e74a
Reviewed-on: https://chromium-review.googlesource.com/170839
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
The Bayley Bay reference board is a Bay Trail mobile and/or
desktop reference board.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=Built and booted to romstage.
Change-Id: Ia0a4f94244ce7ac3a960de796170c091e384f976
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168388
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This is causing hangs in depthcharge (again?) so for now
turn that port off so the resulting coreboot images are
at least useful.
BUG=none
BRANCH=none
TEST=boot on wtm2 and press Ctrl+D at developer screen with USB keyboard
Change-Id: I32c7774a95b0020b97105e0fa42c21ccb617c718
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65615
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Abstract the use of rdtsc() and make the timestamps
uint64_t in the generic code.
The ARM implementation uses the monotonic timer.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
BUG=chrome-os-partner:18637
TEST=See cbmem print timestamps
Change-Id: Id377ba570094c44e6895ae75f8d6578c8865ea62
Reviewed-on: https://gerrit.chromium.org/gerrit/63793
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
The management engine is slow, requiring at least 500ms between
when the Dram Init Done message is sent (right after memory training)
to when the MBP will report that it is successfully cleared and
that the ME can finally be sent the EOP message.
Currently this is adding 100-150ms to the boot time. If we defer
waiting for the MBP Clear indicator until the finalize step we
can gain back that lost time.
BUG=chrome-os-partner:19933
BRANCH=falco
TEST=manual: boot on falco with SMI debugging enabled to
ensure that the ME is locked down in the finalize step:
Finalizing Coreboot
SMI# #0
SMI_STS: PM1 APM
ME: MBP cleared
ME: mkhi_end_of_post
ME: END OF POST message successful (0)
Change-Id: Icab4c8c8e00eea67bed5e8154d91a1eb48a492d1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62633
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit ff81f50f0e.
Deferring this step until the finalize stage will allow us
to defer waiting for the MBP clear indicator and speeding
up the boot.
BUG=chrome-os-partner:19933
BRANCH=falco
TEST=manual: emerge-falco chromeos-coreboot-falco
Change-Id: Ib8edffd06689e72875830cd68b5aedb7ac3b0559
Reviewed-on: https://gerrit.chromium.org/gerrit/62631
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
In some header shuffling stdint.h no longer included a definition
for NULL. Pull in string.h for the proper definition. Also, disable
the xHCI controller in libpayload as the firmware leaves control
of the USB 3.0 ports to the EHCI controller.
BUG=None
BRANCH=None
TEST=Was able to boot in in non-dev mode. In dev mode there were no
longer errors about the xHCI controller.
Change-Id: Iabf15b3b17d88784e0718dc9f0fd885e6551e0b1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60874
Reviewed-by: Sameer Nanda <snanda@chromium.org>
SPD GPIOs were being read prior to initialization in romstage_common. To
fix, pass the copy_spd function to romstage_common, to be called at the
appropriate time (after PCH init, before DRAM init).
BUG=chrome-os-partner:20162.
TEST=Manual. Test on peppy board with non-zero SPD GPIOs, verify correct
SPD is selected.
Change-Id: I2554813e56a58c8c81456f1a53cc8ce9c2030a73
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58608
- Add a new USB location field
- Add a new "ddr_refresh_2x" field, enabled on Falco only
- Fix copy+paste bug in baskingridge
BUG=chrome-os-partner:19869
BRANCH=none
CQ-DEPEND=CL:*39053
TEST=manual: test to ensure refresh rate 2x can be enabled
Checked that tREFI is halved during memory setup in the memory
training log:
tREFImin = 6240 << DEFAULT
C(0).tREFI = 0xc30 << MODIFIED (=3120)
C(0).tREFI = 0xc30 << MODIFIED (=3120)
Also ensure that the SD card is detected properly again.
Change-Id: Ie3a82c08df06ada9af56282b5255caefa56487f2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57349
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
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>
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>
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>
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>
Now that we have RW ramstage we don't need to have the
management engine lock down step done in a final SMM.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: build and boot on wtm2 and look for messages
during the ME device init step:
ME: mkhi_end_of_post
ME: END OF POST message successful (0)
PCI: 00:16.0: Disabling device
Change-Id: I9db4e72e38be58cc875c1622a966d8fcacc83280
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49757
Instead of having an OS re-parse cbmem book-keeping records
for the cbmem allocator just to get the console buffer export
the pointer to the memory console directly in a field named 'CBMC'.
This field lives in the GNVS table.
BUG=None
BRANCH=None
TEST=Built and booted kernel with support for this field.
/sys/firmware/log correctly shows up.
Change-Id: Ief0c4da7b18df66feb9c816c9f4abdf5a72bd3a4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49764
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
For all the current haswell boards enable the monotonic timer.
The ULT boards use the 24MHz MSR while the non-ULT boards use the
local apic.
Change-Id: I8b19f526a5a49e8467f296c566a2c4263bc5a863
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49763
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Some handlers still had 2 variants, others were
incorrectly guarded by CONFIG_ variables. This
patch straightens them out.
This does not touch the siemens/sitemp_g1p1 which
provides an interestingly complex solution for the
int15 handler.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18638
BRANCH=none
TEST=none required.
Change-Id: I5d74fdf7c2ab1faa96ebc2b5ca5c69398449b069
Reviewed-on: https://gerrit.chromium.org/gerrit/48979
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
We've got enough of a handle on this to realize some things:
drm_dp_helper.h is by design device and architecture independent
i915.h is common to most intel graphics chipsets going back several years
i915_reg.h is as well
Move these files to src/include/device, and adjust the .c files accordingly.
Change-Id: Iee680a3513a957214294c19167d9487aaf2f4d97
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49184
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Add three functions to edid.c:
void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr)
takes an edid and uintptr_t, and fills in a static lb_framebuffer struct
as well as setting the static vbe_valid to 1 unless some problem
is found in the edid. The intent here is that this could be called from
the native graphics setup code on both ARM and x86.
int vbe_mode_info_valid(void)
returns value of the static vbe_valid.
void fill_lb_framebuffer(struct lb_framebuffer *framebuffer)
copies the static edid_fb to lb_framebuffer.
There is now a common vbe.h in src/include, removed the two special ones.
In general, graphics in coreboot is a mess, but graphics is always a
mess. We don't have a clean way to try two different ways to turn on
a device and use the one that works. One battle at a time. Overall,
things are much better.
The best part: this code would also work for ARM, which also uses EDID.
BUG=None
TEST=build coreboot with and without native graphics enabled. It builds.
Build with YABEL. It still builds.
BRANCH=NONE
Change-Id: Ieef2178e7e7fa850556c9af68e2d897a33aec871
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48923
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
This adds some macros for the common GPIO defines and drops
the gpio number definition from each entry. The end result
is much easier to read. The wtm2 mainboard gpio list is modified
to use this.
Also fix a bug in the LP version of get_gpio() that was always
returning zero due to a miscompare.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: build and boot on wtm2 mainboard
Change-Id: I143e5aee412af1eda84e35f8026f31cf13df508e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48946
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This code is the initial version of FUI for haswell and wtm2.
The code is simplified from before in many ways. I've gotten rid of
the opcode table, because it obscured meaning and I don't think it is
needed any more. Register sets, mainly used for reset, are just lines
of code -- not many of them. There are a bunch of not-yet-documented
registers here; the VBIOS seemed to think they were necessary and
testing shows they seem to be right.
As a bit of added paranoia, we always include the VBIOS code as our
emergency recovery path. You have to run it now anyways, so this is no
regression from our current situation; and, if all goes well, in a
week (or so), you'll never have to run it again, but like the Force
and nose hair, it will be with you always.
The code can return in three ways. The first, best way is success:
panel is up and the VBIOS need not run. The second mode is that we
tried to light up the panel but could not, for some reason, but will
return with the panel partly up. In this case, it's ok not to power
cycle the panel. The third, worst case, which will NEVER happen, ha
ha, is that we have to turn the panel off and wait the required 600ms
for it to cycle. Life sucks sometimes. This failure mode is in the
'hang on we're going to fix it' category now that we have ramstage in
RW.
The Big Goal here is to create something other coreboot ports can use
as well. The guys doing the x60 report that the link FUI works,
without too many mods, on that chipset, so it seems Intel is keeping
things from changing too much over time.
Also, again, please note: this and the next 3 versions will ALWAYS fail.
The goal is to verify the correctness of the recovery path.
The bizarre tab-space formatting in drm_dp_helper.h is from the original,
as in i915_reg.h
BUG=None
TEST=build and boot wtm2 and see that FUI failed in a way that VBIOS can
recover from
BRANCH=NONE
Change-Id: I6dfed46500b80c69967aa253a8f24556a5281dfc
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48848
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
The format of this function changed but was not updated in
all mainboards. This fixes BaskingRidge and WTM2.
The int15 handler no longer takes a regs structure as an
argument and instead uses global variables. The yabel interface
is now similar enough that we can drop the duplicate handler.
BUG=chrome-os-partner:18638
BRANCH=none
TEST=manual: boot in developer mode on wtm2 and see graphics
Change-Id: Ia717ae14f99cee6d83ccdb1e26b9d7defe1638c4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48896
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This was an early bring-up reference board for ULT but it is no
longer being worked on and was never complete enough to be useful
and I no longer have a board so it is already stale and untested.
All ULT bring-up work has moved to the wtm2 mainboard instead.
BUG=chrome-os-partner:16862
BRANCH=none
TEST=none
Change-Id: If64d61bf7a3fc8c9e16096ffc28fa4128aa99477
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
