The UART hardware loses power while the system is suspended. However,
the kernel currently doesn't handle the notion of the serial port losing
its settings through a suspend. Because of this using a serial console
in the kernel can cause hangs. Work around this by always initializing
the serial port (if enabled) to 115200 8n1. Though the configuration
may differ it should at least keep hangs and crashes from occuring
with uninitialized serial port.
BUG=chrome-os-partner:25353
BRANCH=baytrail
TEST=Suspend/resume cycles successfully completed with and without
'echo N > /sys/module/printk/parameters/console_suspend'. With
a serial console enabled in the kernel. Also confirmed that
there are not any hiccups when coreboot has its console enabled.
Change-Id: I6fd8a0ae261318769d8f677ef04320a0d6ff1b6d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188011
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BUG=chrome-os-partner:21535
BUG=chrome-os-partner:25990
BRANCH=panther
TEST=manual: Boot on Panther and look in /sys/firmware/log for
the string "PCIe Root Port 4 ASPM is enabled"
Change-Id: I294571c113a8909adb2e97afca92aef9a1af917c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187153
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Change all pull down and pull up resistors from 10K to 20K,
it will save more power on various rails.
BUG=chrome-os-partner:24583
BRANCH=baytrail
TEST=build and boot on rambi, use modified kernel driver to execute
Change-Id: Id588bd9ac4dc71d0783ab933c15ecda0abdadad0
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/187570
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
On SECURITY_MODE (also known ODM Production mode), JTAG is disabled by
BootROM. We need this setting to reenable JTAG on lp0 exit.
BUG=None
TEST=Burn SECURITY_MODE fuse, build chip specific BCT.
wait for Penny to verify.
Change-Id: I81c6e3bc7c74d7915110f7bdd115c323b3a6b96c
Reviewed-on: https://chromium-review.googlesource.com/186677
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Penny Chiu <pchiu@nvidia.com>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Commit-Queue: Tom Warren <twarren@nvidia.com>
Replace sdram entry 1 with valid configurations since nyan 4GB board uses
RAM_CODE 1.
BUG=none
TEST=Flash and boot new image.bin. Console shows "RAMCODE=1" and
"Total SDRAM (MB): 4096"
BRANCH=none
Change-Id: Ia872bd7849f1b58075e1f97bf300e081293cb0d4
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187450
Reviewed-by: Julius Werner <jwerner@chromium.org>
The LZMA compression algorithm, currently the only one available, will fail
if you ask it to write more data to the output than you've given it space for.
The code that calls into LZMA allocates an output buffer the same size as the
input, so if compression increases the size of the output the call will fail.
The caller(s) were written to assume that the call succeeded and check the
returned length to see if the size would have increased, but that will never
happen with LZMA.
Rather than try to rework the LZMA library to dynamically resize the output
buffer or try to guess what the maximal size the data could expand to is, this
change makes the caller simply print a warning and disable compression if the
call failed for some reason.
This may lead to images that are larger than necessary if compression fails
for some other reason and the user doesn't notice, but since compression
errors were ignored entirely until very recently that will hopefully not be
a problem in practice, and we should be guarnateed to at least produce a
correct image.
BUG=chrome-os-partner:26060
TEST=Built for link and saw that a segment whos size had been set to 0 now has
the correct size and is loaded correctly. Booted into RW depthcharge which had
been broken before this change.
BRANCH=None
Change-Id: I5f59529c2d48e9c4c2e011018b40ec336c4fcca8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187365
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
BUG=chrome-os-partner:26085,chrome-os-partner:26051
TEST=With this change applied, check the clock in question
using a scope. Check that it shows up as 19.2Mhz.
Change-Id: I4f9d9132dce9e8a9314852de23838f8c8563021c
Reviewed-on: https://chromium-review.googlesource.com/187594
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
This is the first round of DPTF tuning for Rambi platform.
- Set TSR0 _PSV to 48C
- Set TSR2 _PSV to 55C
- Set TCPU _PSV to 80 and _CRT to 90
- Set mainboard _PDL to 8 (1ghz)
- Set _TRT sampling period to 60 seconds for all but CPU2CPU
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi
Change-Id: Ifcb078580fe674a5ad66559293508dcc6cf136f5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187577
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable the ability for the mainboard to override the _PDL
value exported by DPTF. This will limit the P-state depth
when passive throttling is enabled.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi
Change-Id: I700ef696ff7248997bfd8eb24785eca17d2d7f29
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187576
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The 4-core SKU needs to use SW_ALL for P-state coordination.
There are related bits in MSR_POWER_MISC that need to be set
based on whether or not hardware coordination is disabled.
2-core systems:
- MSR_PMG_CST_CONFIG_CONTROL clear bit 11
- MSR_POWER_MISC set bit 2,3
- \_PR.CPUx._PSD coordination set to 0xFE (HW_ALL)
4-core systems:
- MSR_PMG_CST_CONFIG_CONTROL set bit 11
- MSR_POWER_MISC clear bit 2,3
- \_PR.CPUx._PSD coordination set to 0xFC (SW_ALL)
BUG=chrome-os-partner:26125
BRANCH=baytrail
TEST=build and boot on (2-core) rambi. Check MSR and ACPI _PSD.
Change-Id: I17e84dc50b4bcbffa599498b2bfeac43c135e5b4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187575
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When compression fails for whatever reason, the caller should know about it
rather than blindly assuming it worked correctly. That can prevent half
compressed data from ending up in the image.
This is currently happening for a segment of depthcharge which is triggering
a failure in LZMA. The size of the "compressed" data is never set and is
recorded as zero, and that segment effectively isn't loaded during boot.
BUG=chrome-os-partner:26060
TEST=Built with this change and saw that cbfstool no longer seems to succeed
or inserts a broken payload.
BRANCH=None
Change-Id: Idbff01f5413d030bbf5382712780bbd0b9e83bc7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187364
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
After removing a file sandwiched between two other files, that file
could no longer be re-added at the same location. cbfstool tried to
add the file, and a new "empty" entry, which, together, would no
longer fit, so it continued checking for the next available space.
Change the behavior to add the file if there is enough space for the
file alone, then only add the "empty" entry if there is enough space
for it.
Change-Id: I885bb574bb230905bd42ca0fb6d4a6ef9b0cae03
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186983
The code was passing a reference to ^GBUF to ConcatenateResTemplate
when it needed to pass the buffer itself. This was resulting in parsing
errors from the kernel when trying to evaluate \_SB.LPEA._CRS().
BUG=chrome-os-partner:24380
BRANCH=baytrail
TEST=build and boot on rambi, use modified kernel driver to execute
\_SB.LPEA._CRS() and check for parsing problems.
Change-Id: Ifcefe9fcb43ffb7a62b4c9dff58934aa286e368b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186928
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The original power consumption number for C6FS is equal to
power consumption number for C6NS, which is wrong. The number
should be close to 0 but let's set as 1.
BUG=chrome-os-partner:23628
BRANCH=baytrail
TEST=Build and boot to OS on Rambi.
Change-Id: Iab6b9fa06896796f2c6061d754a321e9a6964092
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/186934
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These values are from the reference code but do not appear
to be documented elsewhere.
BUG=chrome-os-partner:23505
BRANCH=baytrail
TEST=build and boot on rambi
Change-Id: Id9eaa50a4fd5f729f4e1b20baec9390b0e717bf6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186933
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to support multiple trackpads with ACPI identification it is
necessary to declare devices that may not exist. If they happen to
share a wakeup resource then that can end up with duplicate _PRW
declarations and unexpected behavior with /proc/acpi/wakeup
BUG=chrome-os-partner:25883
BRANCH=baytrail
TEST=enable and disable TPAD in /proc/acpi/wakeup and test wake
Change-Id: Id45c6f01de8e06c689509458a5ad893277228bad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186932
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When setting up caching on nyan and big, we would set the region after DRAM to
the end of the address space as uncachable. DRAM may actually extend beyond
the end of the address space, so that may result in address aliasing or other
problems. This change adds a check to make sure there's actually space there.
BUG=None
TEST=Built for big.
BRANCH=None
Change-Id: Ic0a98550222f9dfc0aeafd67a2dd1c0c8f4ece44
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/186769
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The generic tegra124 code will use one of the PWMs to drive the backlight of
the display, but the PWM clock was enabled only for nyan. This change enables
it for big as well.
BUG=none
TEST=Built for Big
BRANCH=None
Change-Id: I5171da7c41f4b4db931563ada3e8e4ebf74ec3d9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/186767
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
FLVL is used to keep track of which thermal zones are active, but it is
not initialized upon boot / resume. An initial value of zero corresponds
to all zones being active, which causes the fan to spin at max speed
until the OS changes zones. Fix this annoyance by initializing FLVL to
the lowest temperature zone.
Also, fix a related bug where FLVL may jump to an undesired value. For
example, if FLVL=3 (zones 3 + 4 active), and zone 0 is set to off (it's
already off!), FLVL would previously become 1 (zones 1 + 2 + 3 + 4
active!). Fix this by not taking zone ON / OFF actions if our zone is
already ON / OFF.
BUG=chrome-os-partner:25766, chrome-os-partner:24775
TEST=Suspend / resume on Panther 20 times, verify that thermal zone after
resume matches expectation based upon temperature. Also, stress system
and verify thermal zones become active according to temperature
increase.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic60686aa5a67bf40c17497832b086ba09d56111a
Reviewed-on: https://chromium-review.googlesource.com/186455
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186669
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Without this patch coreboot will always use the read-only version
of ramstage, even if there is a read-write version available.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=panther
BUG=chrome-os-partner:25870
TEST=Install different RO and RW version, check in cbmem log that
coreboot's romstage and ramstage have different timestamps
in their banners.
Change-Id: I723a3d4479d59534660728d891a9f40a077b4ef0
Reviewed-on: https://chromium-review.googlesource.com/186664
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The ARM configuration files have been changed that we need more settings to run
Coreboot on qemu-v7.
Also fixed the incorrect Makefile settings that caused armv7 to try building
with armv8 cache.
BRANCH=none
BUG=none
TEST=make menuconfig # select qemu-armv7
make # pass
qemu... # successfully boots to ramstage.
Change-Id: I4040e86ad1ff6e8ebd07cfe387c3f5a0e8941800
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186080
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Hung-Te Lin <hungte@google.com>
Once SECURITY_MODE fuse is burned, JTAG is disabled by default.
To reenable JTAG, besides chip unique id and SecureJtagControl need
to be built into BCT, Jtag enable flag is also needed to be set.
BUG=None
TEST=Burn SECURITY_MODE fuse, build chip specific BCT, coreboot
comes up and jtag hooks up fine.
Change-Id: Ic6b61be2c09b15541400f9766d486a4fcef192a8
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/186031
Reviewed-by: Julius Werner <jwerner@chromium.org>
Rambi has been validated to use weaker memory ODT settings.
Enable the weaker settings.
BUG=chrome-os-partner:25420
BRANCH=baytrail
TEST=Built and booted. Suspended and resumed.
Change-Id: I71f50a69821fb292a7914d4fc1db0e903f1fe6fd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186420
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Based on latest thermal report
BUG=chrome-os-partner:24532
TEST=boot tested on panther
BRANCH=panther
Change-Id: I4b8639f926fc3cf57eb5329818b9b912bfbe222d
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186113
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Use the SPSR to extract and inject CPSR values when an exception happens and
pass that information to exception hooks.
The register structure GDB expects when using its remote protocol has a spot
for the CPSR.
BUG=None
TEST=Built and booted on link, nyan.
BRANCH=None
Change-Id: Id950fb09d72fb0f81e4eef2489c0849ce5dd8aca
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180253
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Pass -ggdb3 to the compiler when building libpayload, -ggdb so that it uses
"the most expressive format available", and 3 so that the debugging level is
set to 3, the highest value currently supported. The debugging information can
be stripped by the payload consuming the library, and will definitely be
stripped by cbfstool when installing that payload into an image.
BUG=None
TEST=Built and booted on link, nyan.
BRANCH=None
Change-Id: Ifd6c4a928fbb0b9fa9b3b2e0ea298abff31baf3b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180252
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
To support a GDB stub, it will be necessary to trap various exceptions which
will be used to implement breakpoints, single stepping, etc.
BUG=None
TEST=Built and booted on Link with hooks installed and saw that they
triggered when exceptions occurred. Built and booted on nyan.
BRANCH=None
Change-Id: Iab659365864a3055159a50b8f6e5c44290d3ba2b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179602
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Disable VC setting for HDA so hdmi audio choppy issue will be eliminated.
Change HDA initialize steps to sync with UEFI reference code.
BUG=chrome-os-partner:25651
BRANCH=Baytrail
TEST=Does not have choppy noise during video playing
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Change-Id: I45d49123d369b7d075776215e709af5801ea696d
Reviewed-on: https://chromium-review.googlesource.com/186024
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Tested-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
Without a prompt the config option will always stay 0
due to the way Kconfig works.
BUG=chrome-os-partner:25387
BRANCH=panther
TEST=Boot into dev mode with Mohammed's TV screen, see
the dev mode screen appear.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ib7d9ec82b4a4a29daddc29aa7702fc420279017d
Reviewed-on: https://chromium-review.googlesource.com/185970
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
BRANCH=panther
BUG=none
TEST=Boot systems in question to dev mode, see dev mode screen
Change-Id: I2bd92ac8dc18f660ed69b89ba74f8359278c1923
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/183546
Reviewed-by: Mohammed Habibulla <moch@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@chromium.org>
Tested-by: Mohammed Habibulla <moch@chromium.org>
Repurpose config->pwm to mean the particular PWM device (we use PWM1 on
nyan), and add code to program the PWM device.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan, regenerate bootimage, and boot.
See that the backlight comes up in the bootloader, and brightness can be
adjusted via pwm_bl driver in the kernel.
Change-Id: I2db047e5ef23c0e8fb66dd05ad6339d60918d493
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/185772
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Add some defines and structs that describe what the PWM registers look like.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: Ie10589e4cbf5292e543d205ac8a1c6b09a0f76d0
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/185771
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
The NVM routines weren't propagaing the error codes up
the stack properly. Additionally, padding at the end
wasn't being zero'd correctly as the size of the cache
metadata wasn't being taken into account. The mrc_slot_valid()
wasn't failing as one would expect because of a fence post
issue. These changes should make debugging in this area a lot
easier in the future.
BUG=chrome-os-partner:25577
BRANCH=baytrail
TEST=Was able to identify errors when erasing failed.
Change-Id: I6a93586237763facb0a672d579b9b97ec6968440
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185875
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The ich_status_poll() routine was only waiting 60ms for
a command to complete. This is fine for writes, but when
needing to perform a sector erase it can take a lot longer
as the SPI parts for baytrail operate at 1.8V. Using the
W25Q64FW as a worst case scenario increment the timeout to
400ms.
Measuring on a specific device the sector erase command was
taking on the order of 120ms.
BUG=chrome-os-partner:25577
BRANCH=baytrail
TEST=Filled MRC cache contents. Then rebooted and noted the
ability to erase properly.
Change-Id: I3f2ed930eaff86d8bd32dfee7b5f018852c7adeb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185874
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Configure pin H1 for PWM1, and enable the PWM clock.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: I2f91ebd4666bd227686c08cedf3c1aa7abbe8215
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/185770
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
It seems that someone just stuck the PM3 function for all of the potential
PWM pins. Fix this to be more specific to the particular PWM (of which
there are four).
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: Ic61a7321fbe28953b22007a1d0b522c3ca8714ad
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/185739
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
The Tegra PWM base address was missing, so add it.
BUG=none
TEST=emerge-nyan chromeos-coreboot-nyan
Change-Id: Iebf687c6644290e05ee72794cde697658ab6d7cb
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/185738
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
We'd been putting some data structures like the framebuffer and the cbmem at
the end of memory, but that may not actually be addressable as identity mapped
memory. This change clamps the addresses those structures are placed at so
they stay below 4GB.
BUG=None
TEST=Booted on nyan. Went into recovery mode and verified that there was a
recovery screen. Forced memory size to be 4GB and verified that the recovery
screen still shows up.
BRANCH=None
Change-Id: I9e6b28212c113107d4f480b3dd846dd2349b3a91
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185571
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
To find the coreboot tables, the payload has historically searched for their
signature in a predefined region of memory. This is a little clumsy on x86,
but it works because you can assume certain regions are RAM. Also, there are
areas which are set aside for the firmware by convention. On x86 there's a
forwarding entry which goes in one of those fairly small conventional areas
and which points to the CBMEM area at the end of memory.
On ARM there aren't areas like that, so we've left out the forwarding entry and
gone directly to CBMEM. RAM may not start at the beginning of the address space
or go to its end, and that means there isn't really anywhere fixed you can put
the coreboot tables. That's meant that libpayload has to be configured on a
per board basis to know where to look for CBMEM.
Now that we have boards that don't have fixed amounts of memory, the location
of the end of RAM isn't fixed even on a per board level which means even that
workaround will no longer cut it.
This change makes coreboot pass the location of the coreboot tables to
libpayload using r0, the first argument register. That means we'll be able to
find them no matter where CBMEM is, and we can get rid of the per board search
ranges.
We can extend this mechanism to x86 as well, but there may be more
complications and it's less necessary there. It would be a good thing to do
eventually though.
BUG=None
TEST=Built and booted on nyan. Changed the size of memory and saw that the
payload could still find the coreboot tables where before it couldn't. Built
for pit, snow, and big.
BRANCH=None
Change-Id: I7218afd999da1662b0db8172fd8125670ceac471
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185572
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
If an asm blob isn't marked as volatile, gcc is free to throw it out if it
doesn't think it produces any values that are actually used. To prevent that
from happening, add volatile to some asm blobs in the nyan romstage code.
BUG=None
TEST=Booted on nyan rev1.
BRANCH=None
Change-Id: I819e068e738e94ea749fcb72bba2eee080e1dfb1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185610
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Define a table detailing the charger performance states for
the rambi device and enable the charger participant in DPTF.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, start DPTF and heat up
device to see the charger current limited as expected.
Change-Id: I35a46da7f53cb95cd3d06bec9d71ef721c61e387
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185760
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that the EC supports limiting charger current we can
fill out the placeholder charger participant.
The charger performance states table is moved to the
mainboard dptf configuration so it can be tuned for the
actual charger/battery in a device.
The method to retrieve the number of performance states
is implemented based on whether or not the device is
connected to AC power. There may need to be a hook that
issues a Notify to DPTF to have it re-execute this method
if the AC power state changes, but I have not found it yet.
The method to set charger current is implemented to find
the control value in the charger performance states table
and pass that value to the embedded controller.
An init function is defined which will disable the charger
current limit.
BUG=chrome-os-partner:17279
BRANCH=baytrail
TEST=build and boot on rambi, start DPTF and heat up
device to see the charger current limited as expected.
Change-Id: I531fa5903b9ef11573c31e96b7ecfe0a8a4d3c23
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185759
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
