The latest Cr50 FPGA release runs at 15MHz, but supports USB
operations. This CL includes changes to make that work.
Specifically:
* Enable the security features and select the correct PHY
* Adjust the turnaround time for the slower clock speed
* Handle the SET ADDRESS command specially for this SoC
* Remove all printfs from interrupt handlers (but add #ifdef code
to print debug messages later if desired).
BUG=chrome-os-partner:34893
BRANCH=none
TEST=make buildall, manual test of Cr50 USB:
1. Plug into a USB jack on a Linux host.
2. In src/platform/ec/extra/usb_console, run
make
./usb_console -p 5014 -e 1
3. Type something, hit return
4. See whatever you typed come back with swapped case
5. ^D to quit
Change-Id: I848e96d19df056a453d30d4b5537481046fe852d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308062
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
FAFT and the lab infra calls the flash_ec by giving the chip name as
an argument, instead of the board name. The script should use the
chip name to check if it is a stm32 board.
BUG=chromium:546063
BRANCH=none
TEST=Call the script: flash_ec --chip stm32 --image /tmp/ec.bin
Change-Id: I8e9a029fb6e0aca5ea0f65876f48f6f465664c1c
Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307822
Commit-Ready: Wai-Hong Tam <waihong@chromium.org>
Tested-by: Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
On TCPC startup, set an alert to notify TCPM that we have been
reset. When TCPM gets this notification, it should re-send
initial TCPC parameters. If we were in a stable contract as
a sink, make sure we don't reset connection. If not, then
reset PD protocol state machine to the default state.
This fixes a bug where if the TCPC reboots while the TCPM is
still running, then the TCPC would not get re-initialized and
therefore no PD communication would not work. This also fixes
it such that if we are in a stable contract as a sink and the
TCPC reboots, then we don't lose power.
BUG=chrome-os-partner:46676
BRANCH=none
TEST=tested on glados. reboot PD MCU with and without a charger
plugged in and verify that PD communication works after the
reboot. verify that with a charger, we don't lose power.
also tested with a hoho plugged in during reboot.
Change-Id: I84fec4577b0daf5891bd8461d3f3d925014a5ecf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307187
Reviewed-by: Shawn N <shawnn@chromium.org>
This enables support for a new FPGA image with tighter timing
constraints. Some USB functions perform better using this model.
There are also changes to the signing code.
BUG=chrome-os-partner:34893
BRANCH=none
TEST=make buildall
Change-Id: I608c2424d76b4ea566bf56fa0fed3810436216bb
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308063
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
With a new PS8740 chip revision 0xb the explicit check for 0xa
is failing. Change this to allow revisions >= 0xa to pass.
BUG=chrome-os-partner:46728
BRANCH=none
TEST=boot on chell and confirm lack of mux init errors
Change-Id: I0847bb9953920569922183ed4c83da2370ef40e4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307932
Reviewed-by: Shawn N <shawnn@chromium.org>
dumb mode is used since kunimitsu ec only have control over
the two usb-a ports' power enable/disable functionality.
BUG=none
BRANCH=none
TEST=verified with "ectool usbchargemode <port 0-based> <0=dis, 4=en>"
and check with DMM to see if +5V is toggled when enabled/disabled.
Change-Id: I122c99b4067a873313b892715078188e800b979a
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/307476
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Unless the lid is closed, the ALS is used for lightbar dimming.
Change the google colors depending on the light sensor result.
BUG=chrome-os-partner:44400
BRANCH=smaug
TEST=Check all 3 levels of brightness of the lightbar.
Check value using "adb shell ectool lightbar"
Check double tap color are not affected and is using full brightness.
Change-Id: I7b5e2890c3557f1dd3ae719f5f82ffb5fe7b24fb
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/301216
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Modify oak_pd to build a full RO and RW binary. Note
that in order to fit RO and RW into the small flash size,
this CL removes the console task and adds one-way debug
printfs to save space.
For debugging purposes, you add the console back in by
uncommenting the CONSOLE task in ec.tasklist. This will
build an RW image only that has a full console.
BUG=chrome-os-partner:41959
BRANCH=none
TEST=load on oak_pd and verify host commands from EC work
and charging with zinger works. also test that software sync
works.
Change-Id: I54f7263599684cab333c62796edf57837fe43469
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307032
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Remove NPCX_EC_FLASH_SIZE definition and replace it with CONFIG_FLASH_SIZE.
Due to inconsistence between NPCX_EC_FLASH_SIZE and CONFIG_FLASH_SIZE,
some flash commands such as flasherase will cause unexpected results.
Modified drivers:
1. config_flash_layout.h: Remove NPCX_EC_FLASH_SIZE definition.
2. flash.c: Replace NPCX_EC_FLASH_SIZE with CONFIG_FLASH_SIZE.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: Idca286eef5bb014d5c4cd689c39635e09f40ee03
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/307004
Reviewed-by: Shawn N <shawnn@chromium.org>
When we call dma_disable_all(), we should abort any current transaction
on a channel in addition to disabling the channel. Simply disabling the
channel will ignore any future requests, but a DMA operation may be
ongoing. Lastly, soft-reset the block so that it's a clean state next
time we want to use it.
BUG=None
BRANCH=None
TEST=Enable CONFIG_REPLACE_LOADER_WITH_BSS_SLOW on GLaDOS and add a few
items to the section. 'sysjump' between RO and RW a few times without
encountering a forced hard fault.
TEST=make -j buildall tests
Change-Id: Ia05702b928fbb12265b16d785b6e6dac09807582
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/306915
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
It makes much more sense to keep the stubs locally: they use this
platform's hardware, there is no need to edit two packages when a stub
is replaced with a real implementation.
CQ-DEPEND=CL:306709
BRANCH=none
BUG=chrome-os-partner:43025
TEST=the code still builds
Change-Id: I7a0e180627950cee8cc51600dfffd1a9180a3bcf
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307043
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The only boards that had a port 80 task were the ones using the MEC1322.
Since that EC now has a dedicated timer interrupt configured for port80
writes, we can remove this code that was providing the port 80 task.
Additionally, the config option CONFIG_PORT80_TASK_EN is removed.
BUG=chrome-os-partner:46062
BRANCH=None
TEST=make -j buildall tests
CQ-DEPEND=CL:305591
Change-Id: I145d989b8872240e749ef77aabe0ae76fc94d443
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/305791
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The port 80 task just polls every 1ms until disabled when the system
goes into suspend. Therefore, this commit configures a 1ms timer
interrupt that will be used for the port 80 writes instead of using an
entire task. This saves task stack space as well as context switches.
BUG=chrome-os-partner:46062
BUG=chrome-os-partner:46063
BRANCH=None
TEST=Flash GLaDOS and verify using the `port80' console comamnd that
there are bytes in the port80 history.
TEST=make -j buildall tests
Change-Id: I65b48217a638c1f6ae1ac86471f9a98e0ec4533a
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/305591
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Modify glados_pd to build a full RO and RW binary. Note
that in order to fit RO and RW into the small flash size,
this CL removes the console task and adds one-way debug
printfs to save space.
For debugging purposes, you add the console back in by
uncommenting the CONSOLE task in ec.tasklist. This will
build an RW image only that has a full console.
BUG=chrome-os-partner:41959
BRANCH=none
TEST=load on glados_pd and verify host commands from EC work
and charging with zinger works. also test that software sync
works.
Change-Id: I57895d12a1776a865aac1735aeb0aa8897f1779e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306784
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change erase block size to the correct 1kB.
BUG=chrome-os-partner:41959
BRANCH=none
TEST=with following CL, test software sync to PD MCU on
glados.
Change-Id: I6252e6344e50f00249ab105a90febd15599c936f
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307042
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add CONFIG_I2C_SLAVE_ONLY for boards that only operate as a slave
on i2c.
BUG=chrome-os-partner:41959
BRANCH=none
TEST=make BOARD=glados_pd and see 2kB flash savings
Change-Id: I30831ce48b391d985c25e266229d5c6f2312042b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306783
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow use of a synchronous debug printf instead of using the
full console task to save space. This can be turned on with
CONFIG_DEBUG_PRINTF, and will provide essentially a one-way
console for debugging. This is essentially expanding upon
the debug_printf work done for zinger.
BUG=chrome-os-partner:41959
BRANCH=none
TEST=tested with following CLs on glados_pd by verifying we
get a one-way console.
Change-Id: If028b5d873261890de5b270bbc00e06bdcaa7431
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306782
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
It needs to be possible to retrieve an arbitrary number of random
bytes, which is accomplished by this _cpri__GenerateRandom()
implementation.
Also, this patch rearranges the board initialization code to
initialize both interrupts and the TRNG.
CL-DEPEND=CL:306781
BRANCH=none
BUG=chrome-os-partner:43025
TEST=ran a couple of tests retrieving random numbers from TPM,
observed randomly looking values generated (this is not a
validation of the TRNG implementation).
Change-Id: I6314cdf5e6e96443b3fadb7f1502fc8477c41d0f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306780
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Security settings prevent flash updates by default. This allows
erase and writes to flash bank 1 (0x80000 - 0xbffff). Note that
this doesn't allow for execution of any code you might put there.
That requires additional steps which are not part of this CL.
BUG=chrome-os-partner:44745
BRANCH=none
TEST=manual
Pick an unused section of flash and use the flasherase and
flashwrite commands to test it. The flashwrite command fills a
buffer with bytes, counting up (0x00, 0x01, 0x02, 0x03, ...),
then writes that buffer to the address given.
Note that the "md" command uses the absolute address, while the
flash commands use the offset address within the flash memory.
For example:
> md 0xbb000 16
000BB000: ffffffff ffffffff ffffffff ffffffff
000BB010: ffffffff ffffffff ffffffff ffffffff
000BB020: ffffffff ffffffff ffffffff ffffffff
000BB030: ffffffff ffffffff ffffffff ffffffff
> flasherase 0x7b000 0x800
Erasing 2048 bytes at 0x7b000...
> md 0xbb000 16
000BB000: ffffffff ffffffff ffffffff ffffffff
000BB010: ffffffff ffffffff ffffffff ffffffff
000BB020: ffffffff ffffffff ffffffff ffffffff
000BB030: ffffffff ffffffff ffffffff ffffffff
> flashwrite 0x7b000 0x800
Writing 2048 bytes to 0x7b000...
> md 0xbb000 16
000BB000: 03020100 07060504 0b0a0908 0f0e0d0c
000BB010: 13121110 17161514 1b1a1918 1f1e1d1c
000BB020: 23222120 27262524 2b2a2928 2f2e2d2c
000BB030: 33323130 37363534 3b3a3938 3f3e3d3c
> md .b 0xbb000 16
000BB000: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
>
Change-Id: Ia9fb6415bcc65ab92cab8132d8cf615215804a6d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306687
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Enable JTAG functionality by SW without pulling down strap-pin nJEN0 or nJEN1
during ec POWERON or VCCRST reset occurs.
Please notice it will change pinmux to JTAG directly.
Modified drivers:
1. gpio.c: Remove JTAG0/1 alternative groups and bits from gpio_alt_table
2. jtag.c: Enable JTAG functionality
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Change-Id: I5a664adedeea1c75df37662dc1f3206e90163eeb
Reviewed-on: https://chromium-review.googlesource.com/306470
Reviewed-by: Shawn N <shawnn@chromium.org>
The TRNG operation is simple: once started it begins to fill up an
internal FIFO with random values. The consumer of these values might
have to wait if the next number is not ready yet.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with the rest of the patches in place TPM2 gets a stream of
random numbers when required
Change-Id: I877452733377ec5b179fb6df8581af570b4f3668
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306689
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When supported, the true random number generator provide to API calls,
to initialize it and to retrieve a random number.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with other patches in place TPM2 gets proper random numbers
stream.
Change-Id: I11effdf6f81ca76581a354218203620708195b2b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306688
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Double TAP must be enabled in S5, even if it has been disabled by the
AP, otherwise we would not be able to check the battery level if the AP
did not shutdown properly or does not reenable double tap on shutdown.
BRANCH=none
BUG=chrome-os-partner:46572
TEST=Check double tap is working after unit has been powered down.
Change-Id: Ic798399a3e4ae4d87c6e80eab4cf1fd680f99585
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306697
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Declare optional parameters are const structure.
These parameters, when used, are just read by the sensor driver.
BRANCH=smaug
BUG=None
TEST=compile
Change-Id: I8f2a9291e1908922831fb5e2a524bb6edd0e0f65
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306696
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the sensor is defined to be used in forced mode, ec rate was not
calculated properly: if the AP rate was rounded up, ec_rate requested by
the AP would always be 0. If the EC rate is 0, the sensor may potientally
never be queried.
Also, when the sensor was disable for a long time, the last timestamp of
collection may appear to be in the future, so collection was not
initiated. (long time more than 35 minutes, less than 71 minutes).
We still see instance where the sensor seems locked up.
accelinit would not help because the state machine was not reseted, fix
that.
BRANCH=smaug
BUG=chrome-os-partner:45627
TEST=With accelerate 3/4, check the value is now correct.
Check proximity sensor is not stuck 45 minutes after last collection.
Change-Id: Ia6805b75f67b048cb0b42c0f91a73dfaf94a254f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305823
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The stm32 (i2c slave) datasheet provides a 500 KHz timing configuration
for Fm+ when using an 8 MHz i2c clock.
BUG=chrome-os-partner:46188
BRANCH=None
TEST=Verify no i2c errors are seen on EC-->PD I2C bus.
Change-Id: I15d51a77d4739a769fdfa15bc3c1dae82f046d42
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306183
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Minimum high / low times are within 50% duty cyle bounds, except for
400KHz low time. With this in mind, simplify the duty cycle calculations
and fix off-by-one errors.
BUG=chrome-os-partner:46188
BRANCH=None
TEST=Verify i2c is still functional on Glados.
Change-Id: Ib08ebc06f334f65d2412222bb6c7a45f407b28c4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305577
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
We've been converting the FPGA headers to our headers using a
script that we've passed around via email. Let's check it in so
we don't diverge.
BUG=none
BRANCH=none
TEST=manual
Run ./util/cr50_regs on the latest FPGA header, compare the
output with chip/g/cr50_fpga_regdefs.h. They match.
Change-Id: I6b435755a047265ea91d1af4e3e753e7555d149d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306290
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
To minimize noise, instead of using recommend preset from the
documentation, use specific repetition value.
BRANCH=smaug
BUG=chrome-os-partner:45436
TEST=Check the noise is somewhat reduced, still not great.
Change-Id: I0ed3409dd907fa1e393d1eb77b6f23ff03763e53
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305588
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Before setting a new frequency, put a timestamp in the FIFO.
In case there was a long silence, the sample timestamp will be anchored
on that timestamp instead of the last timestamp the AP collected.
BRANCH=smaug
BUG=chrome-os-partner:43811
TEST=Check SingleSensorTests pass.
Change-Id: Ie40ebd9d856abdeeeccf4b636351560bb8a6305c
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305571
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Use the datasheet-specified 8MHz i2c timings, which are different from
the 48MHz timings.
BUG=chrome-os-partner:46188
BRANCH=None
TEST=Probe glados_pd i2c signals, verify that clock isn't stretched ~2us
on every bit received by slave.
Change-Id: Id6a07bc364163c2efc61c3115043f48a79027010
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305714
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
On Chell, we cannot fit all of the data in data RAM, therefore we adjust
this boundary slightly.
This should not be moved further as this represents when we are truly
out of space.
128k image:
-3k loader
-1k for shmem/panic info
-24k RAM for RO/RW
-100k for RO/RW .text and .rodata
BUG=chrome-os-partner:46058
BUG=chrome-os-partner:46063
BUG=chrome-os-partner:45690
BRANCH=None
TEST=make -j buildall tests
Change-Id: I6fbb0fd53ecb493a1821e6499276a09e93b653b9
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/305793
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The MEC1322 is optimized for 96k code RAM and 32k data RAM, therefore
the default MEC1322 boards should follow this.
On GLaDOS and Kunimitsu, we cannot fit all of the data in data RAM,
therefore we adjust this boundary slightly.
This should not be moved further as this represents when we are truly
out of space.
128k image:
-3k loader
-1k for shmem/panic info
-24k RAM for RO/RW
-100k for RO/RW .text and .rodata
BUG=chrome-os-partner:46058
BUG=chrome-os-partner:46063
BUG=chrome-os-partner:45690
BRANCH=None
TEST=make -j buildall tests
TEST=Flash GLaDOS, verify AP and EC boot.
Change-Id: Ie53ef6dc607333968bee8f296e7c21ed629e357b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/305362
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Certain ECs which cannot load both the RO and RW images into memory
simultaneously have a little firmware (LFW) loader that is loaded into
the beginning of the program memory. This loader is responsible for
loading the RO/RW images, however once we begin executing code from
main(), the loader has already completed it's purpose. We can reuse
this space by allocating portions of the .bss section here. This
currently saves us 3k for mec1322. This section is .bss.slow.
To use this feature simply define the following config option in
board.h.
#define CONFIG_REPLACE_LOADER_WITH_BSS_SLOW
In some cases, such as the mec1322, this region of RAM is optimized for
code and not data. Therefore, ideally infrequently used data should go
into this region.
BUG=chrome-os-partner:46056
BUG=chrome-os-partner:46063
BRANCH=None
TEST=Flash GLaDOS; sysjump rw; Verify that we are in rw; sysjump ro;
Verify we are back in ro.
TEST=Build GLaDOS, check output memory map for LDR_REGION and .bss.slow
section.
TEST=make -j buildall tests
Change-Id: I5b95cacc211278cf780a857b5a2ecfc1a0a28c45
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/305254
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Allow a request message over our max current if the mismatch bit
is set as per the PD spec.
BUG=chromium:542832
BRANCH=samus,ryu
TEST=load onto samus and connect to a ryu that is requesting 1A
max with mismatch bit set, and verify that we accept the request
Change-Id: I486495422c972a43927bb2ebffc64c2b9f9ac445
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305375
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
