These allow to define a kernel image, initrd and command line.
BUG=None
BRANCH=None
TEST=Compiles successfully
Change-Id: Ia07b08b4cf385b17dc85f779cc7583db354bf99b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3893
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/222624
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@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>
The architectiure check in fmap.c is in fact used to delineate between
platforms where SPI flash is mapped to memory address space and where
it needs to be accessed through CBFS.
In fact cosmos board uses an ARM SOC which also maps SPI flash to
processor address space, this will have to be addressed when that
SOC's support is introduced, for now let's just presume that all but
X86 platforms require CBFS layer to access fmap.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Change-Id: Id135dc63278555a7fc5039a568fb28864f7cb8d1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226180
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Chrome OS support needs to be enabled on urara. This patch adds a
placeholder file to keep Chrome OS support code.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Change-Id: I8ec328d4f965ff80d17847f2f8ce62b402c42a46
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226179
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The kernel will not track wakeup events for devices unless they have
a defined _PRW. There is no EC output of the lid signal coming to
a GPIO and instead it pulses WAKE#. There is no actual GPE for
WAKE# so pretend that PCI_EXP is the right GPE.
From the EDS: "WAKE# is treated as a wake event, but does not cause
any bits to go active in the GPE_STS register."
BUG=chromium:427769
BRANCH=none
TEST=manual on auron
- Run lidclose + lidopen in rapid succession, verify that suspend
request is aborted.
Change-Id: I116f3b98f5f31f3ded7c6b403ffa35724176a52d
Signed-off-by: Wei Shun Chang <wei.shun.chang@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/226160
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Invoke the function which copies WiFi calibration data in a CBMEM
table.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=verified that the WIFI entry is added to CBMEM when the
calibration data is present in the VPD.
Change-Id: I5fa77da98e37b88da01fb7884e713535fc178006
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225272
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds functions looking in the VPD for WiFi calibration
data, and if found, copying the calibration blobs into CBMEM.
Two possible key names templates are used: wifi_base64_calibrationX
and wifi_calibrationX, where X is replaced by the WiFi interface
number. Up to four interfaces can be provisioned.
The calibration data will be retrieved from CBMEM by the bootloader
and placed into the device tree before starting the kernel.
The structure of the WiFi calibration data CBMEM entry is defined
locally: it is a concatenation of the blob names and their contents.
Each blob is padded as necessary to make sure that the size divisible
by four.
To make sure that the exactly required amount of memory is allocated
for the CBMEM entry, the function first scans the VPD, caching the
information about the available blobs and calculating their combined
size.
Then the required size CBMEM entry is allocates and the blobs are
copied into it.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=when this function is called, and the VPD includes calibration
data blobs, the WIFI entry shows up in the list of CBMEM entries
reported by coreboot.
Change-Id: Ibe02dc36ff6254e3b9ad0a5bd2696ca29e1b2be3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225271
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds plumbing necessary to ensure that the CBMEM WiFi
calibration blobs entry, if present, is referenced if the coreboot
table.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=none - the entry is not yet in the CBMEM
Change-Id: I04d52934ad1c5466d0d124b32df5ab17c0f59686
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225270
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>
This is essentially a copy of veyron_pinky for now.
BUG=chrome-os-partner:33269
TEST=build and boot
Change-Id: I0d473361e0850ee3b11da5a809f8396826ccdad6
Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225301
- 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>
The ethernet switch, as soon as it is taken out of reset comes up in
default (bridging) mode, which allows traffic to flow freely across
the ports.
Let's keep it in reset such that there is no cross port traffic
happening while the device boots up.
BRANCH=storm
BUG=chrome-os-partner:32646
TEST=verified that the switch is held in reset during boot.
Change-Id: I6bf698beddc98ce18fee6b3b39622e356c8cfbad
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224989
Reviewed-by: Toshi Kikuchi <toshik@chromium.org>
this change sets the stack pointer to the value specified in
memlayout.ld before jumping to the bootblock.
BUG=none
BRANCH=ToT
TEST=Built cosmos and all other current boards.
Change-Id: I4bb8cea7435d2a0e2c1ced050c3366d2e636cb8a
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225420
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
this change makes bootblock and verstage built for armv7-m use generic memset,
memcpy, and memmove because arch/arm/memset.S, memcpy.S, and memmove.S are not
compatible with armv7-m.
BUG=none
BRANCH=ToT
TEST=Ran bootblock on Cosmos prototype board. Emerged all current boards.
Change-Id: Ie1df2525362ffc2e8438ff7bd5fad7629b0477de
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225312
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>
This is a no-op change just sorting the CBMEM entries' definitions for
easy look up and comparison.
BRANCH=storm
BUG=none
TEST=Booted a storm device, observed the expected CBMEM entries
present in the console output.
Change-Id: Ibcd4f184ef1bade10ad677384f61243da7e3c713
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225259
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The new API allows to find VPD objects in the VPD cache. There is no
need for the caller to allocate or free the per object memory.
The existing API (cros_vpd_gets) now uses the new function as well.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=verified that MAC addresses still show up in the device tree on
the booted storm device
Change-Id: I6c0b11bb844d6235930124d642da632319142d88
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225258
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
this adds an entry point jumping to main for the bootblock.
BUG=None
BRANCH=ToT
TEST=Built coreboot for cosmos
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I74f2f5e3b3961ab54a7913e6b3a3ab0e6fd813a3
Reviewed-on: https://chromium-review.googlesource.com/225205
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The function to read board IDs from tristate GPIOs currently supports
two output modes: a normal base-3 integer, or a custom format where
every two bits represent one tristate pin. Each board decides which
representation to use on its own, which is inconsistent and provides
another possible gotcha to trip over when reading unfamiliar code.
The two-bits-per-pin format creates the additional problem that a
complete list of IDs (such as some boards use to build board-ID tables)
necessarily has "holes" in them (since 0b11 does not correspond to a
possible pin state), which makes them extremely tricky to write, read
and expand. It's also very unintuitive in my opinion, although it was
intended to make it easier to read individual pin states from a hex
representation.
This patch switches all boards over to base-3 and removes the other
format to improve consistency. The tristate reading function will just
print the pin states as they are read to make it easier to debug them,
and we add a new BASE3() macro that can generate ternary numbers from
pin states. Also change the order of all static initializers of board ID
pin lists to write the most significant bit first, hoping that this can
help clear up confusion about the endianness of the pins.
CQ-DEPEND=CL:219902
BUG=None
TEST=Booted on a Nyan_Blaze (with board ID 1, unfortunately the only one
I have). Compiled on Daisy, Peach_Pit, Nyan, Nyan_Big, Nyan_Blaze, Rush,
Rush_Ryu, Storm, Veryon_Pinky and Falco for good measure.
Change-Id: I6133cdaf01ed6590ae07e88d9e85a33dc013211a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219901
Reviewed-by: Aaron Durbin <adurbin@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>
GPIO IRQ support has been added in upstream rt5677 driver,
with new jack detect platform config options.
BUG=chrome-os-partner:29649
BRANCH=samus
TEST=headphone and mic detect works on Samus
Change-Id: I379087b8acdb13e65776a18c9ee3a58d4cb4e73c
Signed-off-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224513
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Retrieving MAC address from VPD should be the board responsibility,
add a call to the recently introduced function.
BRANCH=storm
BUG=chromium:417117
TEST=verified that MAC addresses still show up in the device tree on
storm
Change-Id: I3913b10a425d8e8621b832567871ed4861756381
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223797
Reviewed-by: Julius Werner <jwerner@chromium.org>
Retrieval of the MAC address from the VPD is a Chrome OS specific
feature, required just on one platform so far. There is no need to
look for the MAC address in the VPD on all other Chrome OS boards.
BRANCH=storm
BUG=chromium:417117
TEST=with the upcoming patch applied verified that MAC addresses still
show up in the device tree on storm
Change-Id: I8e6f8dc38294d3ab11965931be575360fd12b2fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223796
Reviewed-by: Julius Werner <jwerner@chromium.org>
This matches the label exported by the GPIO controller in the
kernel and allows more speicific matches if there are other
devices that also export GPIOs.
BUG=chrome-os-partner:33098
BRANCH=samus
TEST=crossystem wpsw_cur returns 1
Change-Id: I655549d0f0eca341581bfbf845162d8b9f5e993d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224136
Reviewed-by: Aaron Durbin <adurbin@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>
Since the PD software sync is slow enable support for displaying
a screen telling the user that something is happening.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Change-Id: I125744f58c6b84df1af3943d9be98fe55c7117d5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223850
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Paging code is tricky and figuring out what is wrong with it can be a
pain. This patch tries to ease the burden by giving a little more
information for prefetch and data aborts, dumping the Instruction Fault
Address Register (IFAR), Instruction Fault Status Register (IFSR) and
Auxiliary Instruction Fault Status Register (AIFSR) or the respective
Data registers. These contain additional information about the cause of
the abort (internal/external, write or read, fault subtype, etc.) and
the faulting address.
BUG=None
TEST=I have read through enough imprecise asynchronous external abort
reports with this patch that I learned the bit pattern by heart.
Change-Id: I56a0557d4257f40b5b30c559c84eaf9b9f729099
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223784
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to display a "update in progress" screen on devices with
a slow EC or PD chip it may be necessary to also load the VGA
Option ROM when doing EC software sync.
This adds config options for VBOOT_EC_SLOW_UPDATE which simply sets
a flag in the input parameters that is already handled by vboot.
It also adds a config option for VBOOT_OPROM_MATTERS which is a bit
more tricky in that it sets a flag in input parameters, but also
needs to keep track of the option rom being loaded and pass that
flag into VbInit as well.
Since VbInit will clear the NV bit for option rom loaded the check
that is done in vboot_wants_oprom() needs to first compare against
the vboot handoff copy of the input flags.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Change-Id: Ic2b34bf9e7c6cc5498413fa1b8dff6e6207c9d0a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223831
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remember the XN bit? The one we had so much fun with on Nyan (LPAE)
because not setting it allows random instruction prefetches to device
memory that hang the system every few thousand boots? Thankfully, we had
always been setting it in the non-LPAE MMU code already...
"When the XN bit is 1, a Permission fault is generated if the processor
attempts to execute an instruction fetched from the corresponding memory
region. However, when using the Short-descriptor translation table
format, the fault is generated only if the access is to memory in the
Client domain, see Domains[...]" - ARM A.R.M. section B3.7.2
Oops. This patch changes our Domain Access Control Register (DACR) to
set domain 0 (the only one we are using) to Client. This means that
access permissions (AP[2:0] bits) become enforced, but they are already
set to full access (0b011). It also means that non-LPAE systems will not
be allowed to execute from DCACHE_OFF memory with enabled MMU anymore.
As far as I can see, Veyron_Pinky has been the only board that does
that.
BUG=chrome-os-partner:32118
TEST=Booted Veyron_Pinky with MMU in the bootblock, saw hangs that look
like spurious prefetches and confirmed that this patch fixes them.
Change-Id: I30676a5bfe12d516e5f910f51ee6854f6e5be557
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223783
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>
