Enable display only developer and recovery mode.
Will add in the actual display supporting functions in coming
patches.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: Idfa24d23c81baaedb944d2b9835255edad4e422b
Reviewed-on: https://chromium-review.googlesource.com/226904
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
This changes the broadwell graphics init path to only do the delay
before initializing graphics when running chromeos if we are also
going to execute the option rom.
BUG=chrome-os-partner:33671
BRANCH=samus
TEST=build and boot on samus
Change-Id: I350f85738efe3d17152de4f025adbfd52ae15b95
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228882
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
C0_COUNT register is a free running counter clocked by the CPU
frequency divided by two. On the FPGA board it results in 25 MHz, on
real SOCs it will have to be figured out later.
Some magic addresses and numbers are used to find out if the code is
running on the FPGA board.
timestamp_get() and timer_monotonic_get() are kept in the same file.
The CPU initialization makes sure that CO COUNT is in fact enabled and
starts from zero.
BRANCH=none
BUG=chrome-os-partner:33595,chrome-os-partner:31438
TEST=with timer enabled, the startup code properly initializes UART
and prints the coreboot bootblock banner message on the serial
console.
Change-Id: I2d518213de939e91a35f8aea174aed76d297dd72
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227888
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Urara CBFS header configuration is broken. CBFS header needs to be
right above the bootblock, and the CBFS data - 0x100 bytes above, to
allow room for proper CBFS wrapper structures.
Ideally only the header offset should be specified (and even that
could be derived from the bootblock size). But this is a more generic
problem to be addressed with different architectures' image layout
requirements in mind.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=coreboot image passes the integrity check now (it was failing
before because CBGS header was overlaying the bootblock)
$ FEATURES=noclean emerge-urara coreboot
$ /build/urara/tmp/portage/sys-boot/coreboot-9999/work/coreboot-9999/build/util/bimgtool/bimgtool \
/build/urara/firmware/coreboot.rom.serial
$ cbfstool /build/urara/firmware/coreboot.rom.serial print
coreboot.rom.serial: 1024 kB, bootblocksize 9956, romsize 1048576, offset 0x4100
alignment: 64 bytes, architecture: mips
Name Offset Type Size
fallback/romstage 0x4100 stage 7100
fallback/ramstage 0x5d00 stage 18995
config 0xa780 raw 2452
(empty) 0xb140 null 1003096
Change-Id: Id200ab5421661ef39b7c7713e931c39153fdc8be
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227523
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Our CBFS header offset on rk3288 was very low and overlapped with the
end of the bootblock on recent Pinky builds. This can create all kinds
of fun effects like BSS variables suddenly being initialized to
something else than zero, in an effect that jumps somewhere else for
every slightest code size change.
This patch moves the CBFS header offset up a bit and the CBFS ROM offset
down (because there's really no point in leaving such a large gap). This
resolves our immediate booting problems, and I'll also start on a patch
to add further checks somewhere that catch these overlaps in the future.
BRANCH=None
BUG=None
TEST=Created a Pinky image from the exact same commit version as the
official 6443.0.0 build, with a KERNELREVISION string of the exact same
length as the builder (which for some arcane reason is different than
running emerge locally, shifting the whole bootblock around with it).
Confirmed that I saw the same "Not enough room for another
sub-pagetable!" hang, and that this patch fixes it.
Change-Id: I8be5b7b7e87021cc1b3a91d336e8d233546ee188
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228326
Reviewed-by: Gediminas Ramanauskas <gedis@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
since the LAST_THSUT bit is uncertain value when it cold-reboot,
so we remove the printout about this bit status in coreboot.
BUG=chrome-os-partner:33521
TEST=Boot on veyron_pinky rev2
Change-Id: I258750797e32c28f86e73a01eede005e890a6906
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/228391
Reviewed-by: Julius Werner <jwerner@chromium.org>
LDO7 (VCC10_LCD_PWREN_H) is essentially just a glorified GPIO that turns
the real VCC10 regulator on or off. We tried setting it to 3.3V since it
matches the VCC33_SYS voltage on the input of that regulator. However,
we didn't notice that the LDO only supports going up to 2.5V.
This patch changes the voltage to the allowed maximum, which should
still work fine as an enable line (and is the same value used by the
kernel). This removes an assertion error in the ramstage.
Also change the PMIC driver to assert maximum VSEL values based on the
LDO, because the lower-voltage ones support one more setting. (LDO3 is
actually listed to only go up to 0b1111 in the manual, and has a weird
jump from 0b1101 -> 2.2V (skipping over 0b1110) to 0b1111 -> 2.5V. I
don't know if that's a documentation error or what they were smoking
when they designed that, but we don't need to care for now.)
BRANCH=None
BUG=None
TEST=Booted on Pinky, no more ASSERTION FAILED.
Change-Id: I68a3bb882cf25d98aca8922ede2a17e1ef6524de
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228292
Commit-Queue: Lin Huang <hl@rock-chips.com>
Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-by: Jerry Parson <jwp@chromium.org>
Serial port on ITE 8772 SuperIO must be initialized before
console_init is called. So the pre console init callback
is added to let mainboard code do proper initialization.
Change-Id: I594e6e4a72f65744deca5cad666eb3b227adeb24
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/227933
Reviewed-by: Kenji Chen <kenji.chen@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Rajmohan Mani <rajmohan.mani@intel.com>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
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>
slowly raise to max cpu voltage to prevent overshoot,
and in our experience,when cpu run in 1.8GHz,the
vdd_cpu must up to 1.4V
BUG=chrome-os-partner:32716, chrome-os-partner:31896
TEST=Boot on veyron_pinky rev2,check the rk808 buck1 voltage 1400mv
and measure the overshoot is 1440mv
Change-Id: I9bb739b49ae4b4f7a60133fa38b0fe51b95c0d78
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/226753
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use timestamp region instead of storing timestamps in local data structures
before cbmem is up.
BUG=None
BRANCH=None
TEST=cbmem -t reports correct timestamps on rambi(for both normal boot and
suspend/resume).
Change-Id: I4cce22514041edc7808278d45eac4370a2bf0810
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226421
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Use timestamp region instead of storing timestamps in local data structures
before cbmem is up
BUG=None
BRANCH=None
TEST=Compiles successfully for Auron and Samus. cbmem -t reports correct
timestamps on auron(for both normal boot and suspend/resume)
Change-Id: Ib70a3632c2034963c819c1bb90a3cdb2d7d9c355
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226420
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Add a region TIMESTAMP to store all the timestamps starting from bootblock to
end of romstage. At the end of romstage take all the timestamps in TIMESTAMP
region and put it into cbmem
BUG=chrome-os-partner:32973
BRANCH=None
TEST=Compiles successfully and cbmem -t prints all timestamps
Change-Id: I856564de80589bede660ca6bc1275193f8a2fa4b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/223110
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Need to configure debug uart port to have proper baudrate/width/parity.
Hard-code it to 115200n8.
BUG=chrome-os-partner:32015
BRANCH=None
TEST=successfully suspend/resume on Rush/Ryu
Change-Id: I6a96c80654ce52f5b877fd46995ca8c1aceb7017
Signed-off-by: Yen Lin <yelin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/226407
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is not a standard feature so it should be included by the
mainboard if it is actually present in a sysetm.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=build and boot on samus
CQ-DEPEND=CL:226663, CL:226664
Change-Id: Ib7c171a5a007a2dddfb3d80341c6dc488e383e99
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226662
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
file; configuration needed to enable UART.
BUG=chrome-os-partner:31438
TEST=built urara bootblock and ran it on the Pistachio FPGA,
observed exepected console output
BRANCH=none
Change-Id: I4947ea8608593ec3f44e336ebdf3930f44493ec9
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/226841
Reviewed-by: David Hendricks <dhendrix@chromium.org>
In order to properly support more arm64 SoCs PSCI needs
to handle the hierarchy of cpus/clusters within the SoC.
The nodes within PSCI are kept in a tree as well as
a depth-first ordered array of same tree. Additionally,
the PSCI states are now maintained in a hierachal manner.
OFF propogates up the tree as long as all siblings are
set to OFF. ON propogates up the tree until a node is
not already set to OFF.
The SoC provides the operations for determining how many
children are at a given affinity level. Lastly, the
secmon startup has been reworked in that all non-BSP CPUs
wait for instructions from the BSP.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Can still boot into kernel with SMP.
Change-Id: I520a9726e283bee7edcb514cda28ec1eb31b5ea0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226480
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
I2C bus SDA hold time can be marginal with 60ns value, especially
when there is level shifter on the bus. So program it to 300ns
based on Fast-mode specification, which is between 0 to 900ns.
Apply the same timing for Standard-mode as well.
Refer to original bug on BayTrail chrome-os-partner:28092, this
is to carry forward the fix to Broadwell.
BRANCH=chromeos-2013.04
BUG=chrome-os-partner:33378
TEST=suspend resume test, watch for I2C errors
Change-Id: I995d6868a44f2578a6d0b18dd5e8548f3c3cd494
Signed-off-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/226386
Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This is necessary to support generic gpio interface in src/lib. This
file will be later populated with more GPIO definitions.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Change-Id: I68c9c3a28fcc747575436b502cb25b31afed8700
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226181
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In the case of an EC wake event that is pending but not cleared
it is possible for the EC wake pin (i.e. GPIO27) to be asserted
after the kernel triggers the sleep SMI but before the system
goes to sleep.
If this happens then the GPE will be reported as a wake source
when the system wakes up again.
BUG=chrome-os-partner:33218
BRANCH=samus,auron
TEST=build and boot on samus, use the keyboard to enter suspend
with suspend_stress_test and ensure that only the RTC is listed
as a wake source upon resume.
Change-Id: I319dc22e21126a3086415f8f8b2b35eaec66fd50
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Add the Whirlwind board ID to the enum
- Replace comparisons of the board ID with 0 to the proto0 constant
TEST=Booted Storm with this coreboot version
BUG=none
BRANCH=none
Change-Id: I75c7c98732c3d4569611de54d7aa149dd3b0fb7d
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225460
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This patch runs basic NAND initialization code on Proto 0.2 boards which
have been reworked for NAND. It makes sense to do this in coreboot for
two reasons:
- In general, it is reasonable for coreboot to initialize clocks and such
in preparation for depthcharge's use. Waiting times can be pooled, and
the initialization itself here is very fast.
- There is a kernel bug which requires that the clock already be initialized
before the kernel loads NAND support. Coreboot is a more sensible place
to put a workaround than depthcharge because depthcharge initializes
things lazily, but when booting from USB, depthcharge won't need to look
at NAND. Partner bug 33270
This change involves bringing in an additional header file, ebi2.h, from uBoot.
TEST=Booted a kernel from USB and verified that NAND came up without any
depthcharge hacks, whereas previously a USB-booted kernel would be unable
to access NAND even with the same drivers compiled in due to an initialization
failure.
BUG=chromium:403432
BRANCH=none
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Change-Id: I1760ecb4e47438311d80e34326e45578c608481c
Reviewed-on: https://chromium-review.googlesource.com/225277
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220975
Reviewed-by: Aaron Durbin <adurbin@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>
This patch aligns bg4cd to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Cosmos.
Change-Id: Ia5299659ad186f2e7d698adfa7562396e747473f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224506
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns tegra132 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Rush_Ryu.
Change-Id: Ifafd4d42d4fb04a1c37e8a5f23877c2b550cf44c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224505
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns tegra124 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Nyan, Nyan_Big and Nyan_Blaze.
Change-Id: Ia126cff8590117788d1872e50608c257d2659c1f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224504
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns pistachio to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Urara.
Change-Id: I3ed405a3efdeec28965538d19a22f2b5b8204f01
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224503
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns ipq806x to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Storm.
Change-Id: I283cc7e6094be977d67ed4146f376cebcea6774a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224502
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns exynos5420 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Peach_Pit.
Change-Id: I338559564e57bdc5202d34c7173ce0d075ad2afc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224501
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns exynos5250 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Daisy.
Change-Id: Ic358061ddcbbe7d83a95ca11247b8b505b20491d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224500
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch is the start of a series to change all non-x86 SoC-specific
headers to be included as <soc/header.h> instead of the old
<soc/vendor/chip/header.h> or "header.h". It will add an include/soc/
directory under every src/soc/vendor/chip/ and append the .../include/
part of that to the global include path.
This matches the usage of <arch/header.h> for architecture-specific
headers and had already been done for some headers on Tegra. It has the
advantage that a source file which does not know the specific SoC used
(e.g. Tegra files common for multiple chips, or a global include file)
can still include SoC-specific headers and access macros/types defined
there. It also makes the includes for mainboard files more readable, and
reduces the chance to pull in a wrong header when copying mainboard
sources to use a different-related SoC (e.g. using a Tegra124 mainboard
as template for a Tegra132 one).
For easier maintainability, every SoC family is modified individually.
This patch starts out by changing Rk3288. Also alphabetized headers in
affected files since we touch them anyway.
BUG=None
TEST=Whole series: compared binary images for Daisy, Nyan_Blaze,
Rush_Ryu, Storm, Urara and Veyron_Pinky. Confirmed that they are
byte-for-byte identical except for timestamps, hashes, and __LINE__
macro replacements. Compile-tested individual patches.
Change-Id: I415b8dbe735e572d4ae2cb1df62d66bcce386fff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222025
check the cpu and gpu temperature in romstage,
if over 120 degrees celsius,shut down the device.
BUG=None
Test=Boot on veyron_pinky rev2, write value
3421(125 celsius) to grf_tsadc_testbitl register,
the device will be shut down
Change-Id: If406d6a4f6201150f52ea7fc64cd50b45778d7aa
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/223259
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
As per NV SysEng, setting PINMUX_CLAMP_INPUTS=1 is now
considered a bad thing. It clamps _all_ tristated inputs
to zero, and isn't really the panacea for duplicated pinmux
mappings as was stated previously.
BUG=None
BRANCH=None
TEST=Built both Rush and Ryu OK. Tested on Rush, booted kernel
OK.
Change-Id: I566c4516b34686b744a47a2b0c18c4b801456727
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/224032
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Solving the DACR bug will mean that XN bits suddenly become enforced on
non-LPAE systems, and we will no longer be able to execute out of a
region mapped DCACHE_OFF. When we enable the MMU in romstage we are
still executing out of SRAM, so we would instantly kill ourselves.
Solve this issue by enabling the MMU earlier (in the bootblock) and
mapping the SRAM regions as DCACHE_WRITETHROUGH. They should really be
DCACHE_WRITEBACK, but it looks like there might be hardware limitations
in the Cortex-A12 cache architecture that prevent us from doing so.
Write-through mappings are equivalent to normal non-cacheable on the A12
anyway, and by using this attribute we don't need to introduce a new
DCACHE_OFF_BUT_WITHOUT_XN_BIT type in our API. (Also, using normal
non-cacheable might still have a slight speed advantage over strongly
ordered since it should fetch whole cache lines at once if the processor
finds enough accesses it can combine.)
CQ-DEPEND=CL:223783
BUG=chrome-os-partner:32118
TEST=None (depends on follow-up CL)
Change-Id: I53e827d95acc2db909f1251de78d65e295eceaa7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223782
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SOC code should include the SPI controller driver when configured.
With the upcoming configuration change media.c is not needed anymore.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=the driver compiles when the upcoming patches are applied
Change-Id: If7e12e2fb04e63c36d9696d13e08397b91a77a8c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223750
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This file provides the SOC specific SPI driver API, it needs to be
filled up with code. Function descriptions can be found in
src/include/spi-generic.h.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=compiles with the upcoming patches applied.
Change-Id: I0ee04ca17874a13403007bba80d5e8a7708bc625
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223719
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add necessary configuration to enable the inclusion of the UART driver
into the image when serial console is enabled.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=building with serial console enabled includes the skeleton uart
driver into the build
Change-Id: I6cbd110f600169021901b3f864d596404587fbcc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223598
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds the file to be filled up with the uart driver implementation
for bg4cd.
The console driver structure when required is provided by
src/console/uart_wrapper.c.
BRANCH=none
BUG=chrome-os-partner:32772
TEST=none yet, this file is not event being compiled
Change-Id: I73c12ddcd6f5099cc2196820452e714eeb736cdc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223595
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MEI PCI device has internal logic to flush out the posted writes
before returning completion for non-posted request. When doing a RCBA
write to function disable and then using the PCI CFG RD cycle, need
to do RCBA posting read after writing to it to make sure the write
went through.
As Aaron sugegsted, abstracted function disable path to a common
function.
BUG=chrome-os-partner:33048
TEST=run warm and cold reboot testing
Change-Id: I87aa8ccd604446263fc3621c9a01839a5a75b644
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/223715
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
before the rkclk_init(), we must set rk808
buck1 voltage up to 1300mv
BUG=chrome-os-partner:32716, chrome-os-partner:31896
TEST=Boot on veyron_pinky rev2,check the rk808 buck1 voltage 1300mv
and check the cpu frequency up to 1.8GHz
Change-Id: I6a8c6e35bd7cc6017f2def72876a9170977f206e
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/222957
Reviewed-by: Doug Anderson <dianders@chromium.org>
change i2c clock low period and high perid propoton to 7:3
guarantee the low period more than 1.3us
BUG=None
TEST=Boot on veyron_pinky rev2,check the i2c clock frequency
Change-Id: I235e9e3ff54ab3b9cabad36bab58a8409f7005a0
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/223002
Reviewed-by: Julius Werner <jwerner@chromium.org>
