Some lines in decode_edid have incorrect indent levels.
BUG=none
TEST=emerge-nyan coreboot
BRANCH=none
Change-Id: Icc9cb57ff8dd2e2056599b3dc733fe5ac4e41c16
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193010
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The vboot implementation previously assumed that ramstage would
be a relocatable module. Allow for ramstage not being a relocatable
module.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built nyan with vboot.
Change-Id: Id3544533740d77e2db6be3960bef0c129173bacc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190923
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The arm architecture currently exports cache_sync_instructions()
in <arch/cache.h>. In order for rmodule loading to work on arm
architectures the cache_sync_instructions() needs to be called to
sequence the instruction cache. To avoid sprinkling #ifdefs around
just add an empty cache_sync_instructions() definition.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built and booted nyan and rambi.
Change-Id: I1a969757fffe0ca92754a0d953ba3630810556e3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191551
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Certain CPUs require the default SMM region to be backed up
on resume after a suspend. The reason is that in order to
relocate the SMM region the default SMM region has to be used.
As coreboot is unaware of how that memory is used it needs to
be backed up. Therefore provide a common method for doing this.
BUG=chrome-os-partner:26563
BRANCH=baytrail
TEST=Confirmed SMM backup region in cbmem. Suspend and Resumed.
Change-Id: I65fe1317dc0b2203cb29118564fdba995770ffea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188716
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Fixing the location of the ram oops buffer can lead to certain
kernel and boot loaders being confused when there is a ram
reservation low in the address space. Alternatively provide
a mechanism to allocate the ram oops buffer in cbmem. As cbmem
is usually high in the address space it avoids low reservation
confusion.
The patch uncondtionally provides a GOOG9999 ACPI device with
a single memory resource describing the memory region used for
the ramoops region.
BUG=None
BRANCH=baytrail,haswell
TEST=Built and booted with and w/o dynamic ram oops. With
the corresponding kernel change things behave correctly.
Change-Id: Ide2bb4434768c9f9b90e125adae4324cb1d2d073
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186393
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The memory reference code doesn't maintain some of
the registers which contain valuable information in order
to log correct reset and wake events in the eventlog. Therefore
snapshot the registers which matter in this area so that
they can be consumed by ramstage.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Did various resets/wakes with logging patch which
consumes this structure. Eventlog can pick up reset
events and power failures.
Change-Id: Id8d2d782dd4e1133113f5308c4ccfe79bc6d3e03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181982
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This is always built into coreboot, and is enabled by a static variable
in src/lib/hardwaremain.c. Payload choosing can be enabled at build
time, or at runtime via jtag/gdb.
The operation is simple. The chooser, if enabled, lists the payloads and puts
up a prompt.
Payloads:
fallback/payload
Pick one>
The user then types in the name of a payload, e.g.
Pick one>fallback/payload
The line is ended by newline or carriage return.
And the payload is booted.
If you get it wrong, no backspace
or correction. Just hit return and try again.
I started with Bayou but feel the need is low and the complexity
high for that solution; this is just much simpler.
So, let's think about some UI here. Some options:
- default to the first payload if the user hits return
- time out after 5 seconds or so
- Don't make people type the name;
number the payloads as they are printed and let the user
hit, say, 2, to get the second payload
What would you like to see?
BUG=None
TEST=Works on Nyan
BRANCH=None
Change-Id: I4f93633636abf73e65e1b14c1b9e77ac2e25c453
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180343
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
For choosing payloads we need to be able to read out all the payload
headers. cbfs_payload_headers() delivers names and all the info available
about any payloads.
BUG=None
TEST=builds, tested on Nyan, works fine.
BRANCH=None
Change-Id: If98437819d53cc01d175234fc7429d6aa3383c2c
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180352
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
This will make it possible for payloads to find the ACPI
NVS region which is needed to get base addresses for devices
that are in ACPI mode.
BUG=chrome-os-partner:24380
BRANCH=none
TEST=build and boot rambi with emmc in ACPI mode
Change-Id: Ia67b66ee8bd45ab8270444bbb2802080d31d14eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179849
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Allow ramstage cache to be used from ramstage proper. Also
add a helper function for checking validity of ramstage
cache structure.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted. S3 resumed.
Change-Id: If1f2ad1bcf64504b42e315be243a12432b50e3d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179775
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There's a slew of ports required to initialize baytrail's
perf and power values. Therefore, add the necessary
functionality in the iosf module as well as the reg_script
library.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted.
Change-Id: Id45def82f9b173abeba0e67e4055f21853e62772
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179748
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The reg_script library has proven to be useful. It's
also shown that many scripts operate on devices. However,
certain code paths run the same script on multiple,
but different, devices. In order to make that easier
introduce reg_script_run_on_dev() which takes a device
as a parameter. That way, chained reg_scripts are not
scrictly needed to run the same script on multiple devices.
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I273499af4d303ebd7dc19e9b635ca23cf9bb2225
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179540
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This patch adds stub implementations of exception_init() to all archs
so that it can be called from src/lib/hardwaremain.c. It also moves/adds
all other invocations of exception_init() (which needs to be rerun in
every stage) close to console_init(), in the hopes that it will be less
likely overlooked when creating future boards. Also added (an
ineffective) one to the armv4 bootblock implementations for consistency
and in case we want to implement it later.
BUG=None
TEST=Made sure exceptions can fire and get handled correctly in romstage
and ramstage on Nyan and all three stages on Snow.
Change-Id: Iecad10172d25f6c1fc54b0fec8165d7ef60e3414
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176764
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Print a space after a full stop.
BUG=none
TEST=boot tested
BRANCH=none
Change-Id: Ic7d0522ae35079b64ce61956d06ea59843ef9d80
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/176756
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Add the LPSS IOSF port access to reg_script. This is
going to be used by baytrail.
BUG=chrome-os-partner:23790
BRANCH=None
TEST=Buit.
Change-Id: I0367acdb584f2de0bb871b136042b57fe6b7ec90
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176423
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This required changing value/mask types to uint64_t.
Another option would be to use id field to select low or high
32 bits of the MSR and set them independently.
BUG=chrome-os-partner:23505
BRANCH=none
TEST=build and boot on rambi
Change-Id: Ied9998058a8035bf3f003185236f3be3e0df7fc9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176304
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
The reg_script stuff only makes sense for those platforms that
need it: ARM V8 and all x86. Have its usage controlled by a config variable.
BUG=None
TEST=the broken nyan build is fixed.
BRANCH=None
Change-Id: Iad54773f412e2d829e68b98fd845cd72ae408ee1
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/175530
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This is based on the RCBA configuration setup from haswell.
It handles PCI, BARs, IO, MMIO, and baytrail-specific IOSF.
I did not extend it to handle MSR yet but that would be another
potential register type.
There are a number of approaches to this kind of thing, but in the
end they have a lot of switch statements and a mass of #defines.
I'm not particularly set on any of the details so comments welcome.
BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=emerge-rambi chromeos-coreboot-rambi
Change-Id: Ib873936ecf20fc996a8feeb72b9d04ddb523211f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175206
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
The CBFS core checks the result of a media->map() operation in multiple
places for CBFS_MEDIA_INVALID_MAP_ADDRESS, suggesting that this is a
valid response. However, it ironically fails to do so when actually
mapping the CBFS file itself, which can fail on buffer-constrained
systems since the size is much larger than when mapping metadata. This
patch adds a check with an error message and a NULL pointer return for
that case to make it easier to understand this condition.
BUG=None
TEST=None
Change-Id: Icae3dd20d3d111cdfc4f2dc6397b52174349b140
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174951
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The load_stage_from_cbfs() when CONFIG_RELOCATABLE_RAMSTAGE is
selected is incorrect in that it hard coded the wrong stage name.
Instead it should honor the name past in instead of using a
predetermined (and wrong!) name.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built booted. Noted fallback path works.
Change-Id: I61654313d15167efe50d5e4ff24fb06eab16f389
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174391
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There are 3 places rmodule stages are loaded in the
existing code: cbfs and 2 in vboot_wrapper. Much of the
code is the same except for a few different cbmem entry
ids. Instead provide a common implementation in the
rmodule library itself.
A structure named rmod_stage_load is introduced to manage
the inputs and outputs from the new API.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I146055005557e04164e95de4aae8a2bde8713131
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In order to identify the ram used in cbmem for
reference code blobs add common ids to be consumed
by downstream users.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted with ref code support. Noted reference
code entries in cbmem.
Change-Id: Iae3f0c2c1ffdb2eb0e82a52ee459d25db44c1904
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174424
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
CQ-DEPEND=CL:172643
CQ-DEPEND=CL:*146397
CQ-DEPEND=CL:*146398
CQ-DEPEND=CL:*146435
CQ-DEPEND=CL:*146445
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
BUG=chrome-os-partner:23009
TEST=Built libpayload and coreboot for link, pit and nyan. Booted into the
bootblock on nyan.
BRANCH=None
Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The register indexes and bitfield masks were guarded by the UART8250 config
options, but it might be (is) necessary to use them in a driver that is
UART8250 like without actually using the 8250 driver itself. To avoid any name
collision with other drivers, also change the constant prefix from UART_ to
UART8250_.
BUG=None
TEST=Built for link, lumpy, pit, and nyan. With this and other changes, got
bootblock serial output on nyan.
BRANCH=None
Change-Id: Ie606d9e0329132961c3004688176204a829569dc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171336
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Peppy had some issues with FUI. We decided it was time to create
peppy-specific gma.c and i915io.c files. Using yabel and the i915tool,
we generated a replay attack, then interpolated against the slippy
i915io.c to get something working.
Also, in preparation for moving code out of the mainboard gma.c to
generic driver code, we got rid of some hardcodes in the mainboard
gma.c that have no business being there. The worst were the
computation of gmch_[m,n] and it turns out that we had some
long-standing bugs related to confusion about 'bpp'. I've killed the
word bpp everywhere I could because there are at least 3 things that
correspond to bpp. We now have framebuffer, pipe, and panel bpp. The
names are long because I want to avoid all the mistakes we've all been
making in the last year :-) Sadly, that means a lot of changes not just
peppy-related, but they are simple and in a good cause.
The test pattern generation is driven by a global variable in
mainboard/peppy/gma.c. I've found in the past that it's very useful
to have a function like this available, as one can activate it while
using a jtag debugger: halt at the right place in ramstage, set the
variable to 1, continue. It's not enough code to worry about always
including.
The last hard-codes for M and N registers are gone, and the function
to set from generic intel_dp.c code works. To avoid screen trash on a
dev mode boot, which we liked but nobody else did :-), we now take the
time to put a pleasing background color that sort of doubles as a
power LED.
Rough timing is ramstage start is at 2.2, and dev setup is done at
3.3. These new platforms are depressingly slow to boot. Rom init alone
is taking 1.9 seconds. 13 years ago it was 3 seconds from power on to bash
prompt. These CPUs are at least 10x faster and take much longer to get going.
Future work, once we get this through, is to move more functions to the
intel driver, and combine the mainboard i915io.c into the mainboard gma.c.
That separation only existed because i915io.c was generated by a tool, and it
had lots of ugliness. Most ugliness is gone.
BUG=None
TEST=build and boot on peppy and get a screen, in both dev and normal modes.
BRANCH=None
Change-Id: I6a6295b423a41e263f82cef33eacb92a14163321
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/170013
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
When using dynamic CBMEM the CBMEM area is initialized before
entering ram stage, and so we need a way smaller temporary buffer
for the CBMEM console during early bits of ram stage. In practice
around 256 bytes are needed, but keep the buffer at 1k so we make
sure we don't run out.
TEST=Boot tested on pit
BRANCH=none
BUG=none
Change-Id: I462810b7bafbcc57f8e5f9b1d1f38cfdf85fa630
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168575
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some drivers (like the I2C TPM driver) call mdelay instead of
udelay. While it's a shame that these chips are so slow, the
overhead of having those functions available in romstage is
minimal.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=compile tested
BUG=none
Change-Id: I1fa888fc5ca4489def16ac92e2f8260ccc26d792
Reviewed-on: https://chromium-review.googlesource.com/167542
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
This is needed for early vboot selection
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=needs further changes
BUG=none
Change-Id: Ibfd36c59e96513b65f5ff5239b4ecc02e807039b
Reviewed-on: https://chromium-review.googlesource.com/167401
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
This patch adds a mechanism to set aside a region of cache-coherent
(i.e. usually uncached) virtual memory, which can be used to communicate
with DMA devices without automatic cache snooping (common on ARM)
without the need of explicit flush/invalidation instructions in the
driver code.
This works by setting aside said region in the (board-specific) page
table setup, as exemplary done in this patch for the Snow, Pit and Kirby
boards. It uses a new mechanism for adding board-specific Coreboot table
entries to describe this region in an entry with the LB_DMA tag.
Libpayload's memory allocator is enhanced to be able to operate on
distinct types/regions of memory. It provides dma_malloc() and
dma_memalign() functions for use in drivers, which by default just
operate on the same heap as their traditional counterparts. However, if
the Coreboot table parsing code finds a CB_DMA section, further requests
through the dma_xxx() functions will return memory from the region
described therein instead.
BUG=chrome-os-partner:21969
TEST=Manual
Change-Id: Ia9c249249e936bbc3eb76e7b4822af2230ffb186
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167155
There are three Coreboot table tags that all define some kind of memory
region, and each has their own homologous struct. I'm about to add a
fourth so I'll just clean this up and turn it into a generic struct
lb_range instead.
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Id148b2737d442e0636d2c05e74efa1fdf844a0d3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167154
Architecture provides a function for thread stack base, thread code uses it.
Build and boot tested on Falco with multitasking on and off.
BUG=None
TEST=Builds and boots on a Falco
BRANCH=None
Change-Id: I5016fab47f9954379acf7702ac7965b0a70c88ed
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66578
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
A bootblock overwalk was occuring when deriving the actual
length, the bootblock size was not taken into account and bootblock
size was not aligned.
Resolved merge conflict.
BUG=chrome-os-partner:21841
BRANCH=peppy
TEST=execute on DUT: "localhost ~ # sudo suspend_stress_test",
verfify there is no CBFS: ERROR
Change-Id: I7eb42f8deaaf223dcf07b37bb7dde4643acd508f
Signed-off-by: Steven Sherk <steven.sherk@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65989
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Steve Sherk <ssherk70@gmail.com>
Tested-by: Steve Sherk <ssherk70@gmail.com>
This includes the new dp code, which is better, and the fimd code,
which is changed and improved. We took the chance to remove un-needed
files, and also to remove some foolish u-boot habits, but not all of
them. That will take time.
With these changes we get graphics.
Since the only mainboards we have with 16 bit graphics are 5:6:5,
adjust edid.c to just use that format. If at some future time we need
4:4:4, which seems unlikely, we'll need to add a function to adjust
the lb_framebuffer. Note that you can't just divine this from the EDID,
as the graphics pipe format need not match the actual final format used.
The EDID reading works. We've been requested to support hard-coded
EDIDs and that will come in the next revision. Currently the hard-coded
EDID is ignored for testing.
BUG=None
TEST=Build, boot, graphics!
BRANCH=None
Change-Id: Ib4d06dc3388ab90c834f94808a51133e5b515a4d
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64240
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@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>
Works fine with all three panels with the change of 6 bits per color.
Change-Id: Ia47d152e62d1879150d8cf9a6657b62007ef5c0e
Reviewed-on: https://gerrit.chromium.org/gerrit/63762
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
- prints hex and ascii
- detects duplicate all zero lines
BUG=none
TEST=none
BRANCH=none
Change-Id: I557fed34f0f50ae256a019cf893004a0d6cbff7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62655
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
and add an ARMv7 version.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=no functional change
BRANCH=none
Change-Id: I13d9194235bf03e3cceb862c791572f89196b65b
Reviewed-on: https://gerrit.chromium.org/gerrit/59293
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
pixel_clock and link_clock.
Two undocumented registers 0x6f040 and 0x6f044 correspond to link_m and link_n respectively.
Other two undocumented registers 0x6f030 and 0x6f034 correspond to data_m and data_n respectively.
Calculations are based on the intel_link_compute_m_n from linux kernel.
Currently, the value for 0x6f030 does not come up right with our calculations. Hence, set to
hard-coded value.
Change-Id: I40ff411729d0a61759164c3c1098504973f9cf5e
Reviewed-on: https://gerrit.chromium.org/gerrit/62915
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
BUG=None
TEST=Built and booted on Link and Snow.
BRANCH=None
Change-Id: I0b05e2d128f3da0f4c9a6ee32de4ed359bf93ccd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61073
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
