When signer code was ported and enhanced to work with binaries (in
addition to hex), a bug was introduced, where the signed image is
considered to always to be based at the bottom of the flash. In fact
the image could be anywhere in the flash, the actual address derived
from the input elf file should be used.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=verified that when enabled, RW image is signed properly
(build/cr50/RW/ec.RW.flat starts with a signature).
Change-Id: I194bd02f932529165adcbebf4bcbd9020fc261dc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311314
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
New aliases are created automatically, there is no need to include
them in registers.h manually any more.
BRANCH=none
BUG=none
TEST=built and ran cr50 successfully
Change-Id: I9c12c9a66d231723f8c986dd0c598f1e03aaca3a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311372
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Register descriptions generate by the hardware tools always use the
block index when naming the base address of the bock, but the macros
compiling addresses out of register names do not use the index if
there is just one instance of the block in the design.
The problem is addresses by aliasing these definitions in registers.h
in the chip directory. This patch automates this aliasing and ensures
that the generated file has the aliases included, no need to add them
manually to registers.h.
BRANCH=none
BUG=none
TEST=re-generated cr50_regs.h, observed proper aliases created, built
and ran cr50 with the new registers file.
Change-Id: If037e082841a1510f7cad66737fd8b775dc667ea
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311371
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Turn on LTO for GLaDOS and Kunimitsu. This saves about 5k from the
image on GLaDOS. Also, LTO is disabled for the loader since it actually
causes it to bloat in size for some reason.
BUG=chrome-os-partner:46063
BRANCH=None
TEST=Build and flash on GLaDOS with charger inserted. Verify that EC
boot is successful. sysjump to RW and verify that the jump is
successful.
TEST=make -j buildall tests
Change-Id: I9892edfc724f290acaf6cceba181c177702d63bf
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/311208
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Change ADC channels on mec1322 boards to use scaling based on ADC
reference voltage of 3.0V instead of 3.3V. Also, setup the scaling
for AMON_BMON which reads the adapter input current or battery
current in mA.
BUG=none
BRANCH=none
TEST=tested on glados. use adc console command and verify it
roughly matches twinkie voltage and current.
Change-Id: Id6ed72012ebb1c23cf98a14ee6c156ec0f5fb586
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311302
Reviewed-by: Shawn N <shawnn@chromium.org>
Most of the pd ECs have CONFIG_LTO enabled which turns on GCC
Link-Time Optimizations. Unless protected, this removes the
FMAP data from the generated EC images.
BUG=chrome-os-partner:46442
TEST=Manually tested pd programming on Kunimitsu.
flashrom -p ec:dev=1 -w ec.bin is successful
BRANCH=none
Change-Id: I3badd1b245ab7490d75331be8074a0557f7b4d4b
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/310879
Reviewed-by: Shawn N <shawnn@chromium.org>
BUG=chrome-os-partner:46056
BUG=chrome-os-partner:46063
BRANCH=None
TEST=Enabled CONFIG_REPLACE_LOADER_WITH_BSS_SLOW on GLaDOS; Build and
flash; Verify that AP and EC boot. Verify that AC notifications are sent
to the AP. Verify that I can set temperature thresholds.
TEST='sysjump rw' and repeat above tests.
TEST=make -j buildall tests
CQ-DEPEND=CL:311209
Change-Id: If2a7b0ce08b37e30362ab77eee1317c8a86b90dd
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/311344
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add HW charge ramping option and enable on glados.
Modify charge_manager to enable/disable HW charge ramping
when option is defined.
Unfortunately, the isl9237 doesn't have a way to determine
what the input current limit has settled on, so the EC will
always report the max input current for that supplier.
BUG=chrome-os-partner:47335
BRANCH=none
TEST=plug in CDP, SDP, DCP, type-C, and PD charger. Make sure
we ramp to a reasonable value for the correct suppliers.
Make sure we don't ramp for type-C and PD chargers.
Change-Id: Ib541fa0be48d8f4d261c71b853b0ee72b2adbf6b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311301
Reviewed-by: Shawn N <shawnn@chromium.org>
Add a new configuration struct tcpc_config_t that initially defines the
i2c host port and i2c slave address of all TCPCs present on the board.
This will allow us to create boards with multiple TCPCs on different i2c
ports, with arbitrary i2c slave addresses.
BUG=chromium:551078
TEST=Manual on glados. Verify PD communication / charging is still
functional on both PD ports.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9b2bde85d7f1642e8727c052e064371be7967619
Reviewed-on: https://chromium-review.googlesource.com/311000
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
BUG=chrome-os-partner:46056
BUG=chrome-os-partner:46063
BRANCH=None
TEST=Enable CONFIG_REPLACE_LOADER_WITH_BSS_SLOW on GLaDOS. Build,
flash, and verify that AP and EC boot. Plug in a charger on both ports
and use ectool to view the PD log.
TEST=make -j buildall tests
CQ-DEPEND=CL:311209
Change-Id: I54ae617e03c645d24319d83da6cc8b7d1d6528a3
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/311413
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some ECs such as the MEC1322 have a data RAM optimized region as well as
a code RAM optimized region. We discovered that we could save quite a
bit more space by reusing the a portion of the code RAM region as an
additional .bss section. However, this region resides in the code RAM
region. If on the same cycle the processor fetches an instruction and
does a load or store to this code RAM region, the data access will be
delayed by one cycle. Hence, the naming of ``.bss.slow" section.
For boards which do not define CONFIG_REUSE_LOADER_WITH_BSS_SLOW, all
objects bearing this tag will be simply appended to the existing .bss
section.
BUG=chrome-os-partner:46056
BUG=chrome-os-partner:46063
BRANCH=None
TEST=make -j buildall tests
CQ-DEPEND=CL:306173
Change-Id: I126fbeee5255732a6dd6fea1d4557fc2b2c62c96
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/311209
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The point at which we reloaded the loader was too early. When items are
placed into .bss.slow via CONFIG_REPLACE_LOADER_WITH_BSS_SLOW, other
tasks could still access their variables that may have been in that
region after we had replaced those contents with the loader. This
commit moves the reloading of the loader to as late as possible once all
tasks have done their HOOK_SYSJUMP work.
Also, fixed a bug with the .bss.slow section. If a board is not using
the config option but items are placed in that section, that part of RAM
would not be cleared out.
BUG=chrome-os-partner:46056
BRANCH=None
TEST=Enable config option on GLaDOS and add a few variables to the
.bss.slow section. 'sysjump' between RO and RW and verify that no data
bus error is encountered.
TEST=make -j buildall tests
Change-Id: I3084700b9d5c144e86e2e408b72d2e3075a67413
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/306173
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Permission registers only reset on power cycle,
so a soft reboot will fail unless a minimum power
cycle is performed.
BRANCH=none
BUG=chrome-os-partner:47289,chrome-os-partner:43025
TEST=hard / soft reboot from ec shell
Signed-off-by: nagendra modadugu <ngm@google.com>
Change-Id: I8f0f1bc80a2748b031a9b7a3715485577f2b5b3b
Reviewed-on: https://chromium-review.googlesource.com/310975
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Nagendra Modadugu <ngm@google.com>
Commit-Queue: Nagendra Modadugu <ngm@google.com>
Trybot-Ready: Nagendra Modadugu <ngm@google.com>
In fact this provides support for three FPGA images:
20151104_011218 - full crypto, no USB
20151104_041733 - tiny crypto, full USB
20151104_065845 - full crypto, full USB (only for hard-to-get boards)
We can tell these FPGA images apart at run-time by looking at
some SWDP registers:
register crypto usb full
GREG32(SWDP, BUILD_TIME) 0x2bd2 0xa305 0x10135
GREG32(SWDP, FPGA_CONFIG) 0x1 0x2 0x3
This CL includes a run-time check for the USB features so that
it's safe to build the firmware with CONFIG_USB and run it on a
non-USB FPGA image.
Here are the differences I could find in the top-level image
header files:
All three FPGA images define different (apparently arbitrary)
default values for the PMU_PWRDN_SCRATCHn registers, but other
than that, the usb and full images differ only in the BUILD_TIME
and FPGA_CONFIG register values.
I'm not sure why, but function uart_init() in file
chip/g/polling_uart.c writes to one of the PMU_PWRDN_SCRATCHn
registers, but nothing seems to read it again.
The crypto image defines these values which don't appear in the
other images:
#define PINMUX_USB0_EXT_DM_PULLUP_EN_SEL 0x4f
#define PINMUX_USB0_EXT_DP_RPU1_ENB_SEL 0x50
#define PINMUX_USB0_EXT_DP_RPU2_ENB_SEL 0x51
#define PINMUX_USB0_EXT_FS_EDGE_SEL_SEL 0x52
#define PINMUX_USB0_EXT_RX_DMI_SEL 0x53
#define PINMUX_USB0_EXT_RX_DPI_SEL 0x54
#define PINMUX_USB0_EXT_RX_RCV_SEL 0x55
#define PINMUX_USB0_EXT_SUSPENDB_SEL 0x56
#define PINMUX_USB0_EXT_TX_DMO_SEL 0x57
#define PINMUX_USB0_EXT_TX_DPO_SEL 0x58
#define PINMUX_USB0_EXT_TX_OEB_SEL 0x59
#define PINMUX_USB0_EXT_DM_PULLUP_EN_SEL_OFFSET 0x230
#define PINMUX_USB0_EXT_DM_PULLUP_EN_SEL_DEFAULT 0x0
#define PINMUX_USB0_EXT_DP_RPU1_ENB_SEL_OFFSET 0x234
#define PINMUX_USB0_EXT_DP_RPU1_ENB_SEL_DEFAULT 0x0
#define PINMUX_USB0_EXT_DP_RPU2_ENB_SEL_OFFSET 0x238
#define PINMUX_USB0_EXT_DP_RPU2_ENB_SEL_DEFAULT 0x0
#define PINMUX_USB0_EXT_FS_EDGE_SEL_SEL_OFFSET 0x23c
#define PINMUX_USB0_EXT_FS_EDGE_SEL_SEL_DEFAULT 0x0
#define PINMUX_USB0_EXT_RX_DMI_SEL_OFFSET 0x240
#define PINMUX_USB0_EXT_RX_DMI_SEL_DEFAULT 0x0
#define PINMUX_USB0_EXT_RX_DPI_SEL_OFFSET 0x244
#define PINMUX_USB0_EXT_RX_DPI_SEL_DEFAULT 0x0
#define PINMUX_USB0_EXT_RX_RCV_SEL_OFFSET 0x248
#define PINMUX_USB0_EXT_RX_RCV_SEL_DEFAULT 0x0
#define PINMUX_USB0_EXT_SUSPENDB_SEL_OFFSET 0x24c
#define PINMUX_USB0_EXT_SUSPENDB_SEL_DEFAULT 0x0
#define PINMUX_USB0_EXT_TX_DMO_SEL_OFFSET 0x250
#define PINMUX_USB0_EXT_TX_DMO_SEL_DEFAULT 0x0
#define PINMUX_USB0_EXT_TX_DPO_SEL_OFFSET 0x254
#define PINMUX_USB0_EXT_TX_DPO_SEL_DEFAULT 0x0
#define PINMUX_USB0_EXT_TX_OEB_SEL_OFFSET 0x258
#define PINMUX_USB0_EXT_TX_OEB_SEL_DEFAULT 0x0
The crypto image also differs in this:
#define PINMUX_VOLT0_TST_NEG_GLITCH_DET_SEL_OFFSET 0x25c
instead of this:
#define PINMUX_VOLT0_TST_NEG_GLITCH_DET_SEL_OFFSET 0x230
The rest of the differences between the crypto and usb versions
are in these values, which I don't think we care about. At least,
I can't find any place where they're used.
PINMUX_EXITEDGE0_DIOAn_OFFSET
PINMUX_EXITEDGE0_DIOBn_OFFSET
PINMUX_EXITEDGE0_DIOMn_OFFSET
PINMUX_EXITEDGE0_VIOn_OFFSET
PINMUX_EXITEDGE0_OFFSET
PINMUX_EXITEN0_DIOAn_OFFSET
PINMUX_EXITEN0_DIOBn_OFFSET
PINMUX_EXITEN0_DIOMn_OFFSET
PINMUX_EXITEN0_VIOn_OFFSET
PINMUX_EXITEN0_OFFSET
PINMUX_EXITINV0_DIOAn_OFFSET
PINMUX_EXITINV0_DIOBn_OFFSET
PINMUX_EXITINV0_DIOMn_OFFSET
PINMUX_EXITINV0_VIOn_OFFSET
PINMUX_EXITINV0_OFFSET
PINMUX_HOLD_OFFSET
PINMUX_SEL_COUNT
PINMUX_VOLT0_TST_NEG_GLITCH_DET_SEL
PINMUX_VOLT0_TST_POS_GLITCH_DET_SEL
PINMUX_VOLT0_TST_POS_GLITCH_DET_SEL_OFFSET
PINMUX_XO0_TESTBUSn_SEL
PINMUX_XO0_TESTBUSn_SEL_OFFSET
I used the header from the usb image to update chip/g/cr50_fpga_regdefs.h
BRANCH=none
BUG=chrome-os-partner:43791
CQ-DEPEND=CL:310978
TEST=make buildall
I also built a single Cr50 firmware and tried it on both the
crypto and usb FPGA images. Both worked as expected.
Change-Id: Ia8a064758f71f86771729437ae3e81226fd55789
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311211
A previous commit caused ToT to use a not-yet-working bootloader.
This disables that bootloader by default so that the rest of us
can continue to work. ;-)
A configuration option is added to be able to address this issue in
the future with other boards as well.
BRANCH=None
BUG=chrome-os-partner:43025, chromium:551151
TEST=make buildall -j
Also verified that both normal and customized cr50 RO images build
and work as expected.
Change-Id: Ie433b07860cb1b04c12b2609c6fa39025fc0e515
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310978
The CR50 board will have to have a very different RO image, let's make
it possible to override the default list of objects compiled by the
top level makefile with a board/chip specific list compiled in the
appropriate build.mk file.
The CR50 RO will never run on its own for long time, it will always
load an RW and go straight to it, so there is no need in running under
the OS control, using sophisticated console channel controls, etc.
The gist of the functionality is verifying the RW image to run and
setting up the hardware to allow the picked image to execute, it will
be added in the following patches. This change just provides the
plumbing and shows the 'hello world' implementation for the customized
RO image.
A better solution could be the ability to create distinct sets of make
variables for RO and RW, a tracker item was created to look into this.
BRANCH=None
BUG=chrome-os-partner:43025, chromium:551151
TEST=built and started ec.RO.hex on cr50, observed the 'hello world'
message on the console.
Change-Id: Ie67ff28bec3a9788898e99483eedb0ef77de38cd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310410
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
1. In combinational mode and clock source is 8MHz,
if timer 3 counter register always equals to 7, then timer 4 will be a
32-bit MHz free-running counter.
2. Fix TIMER_32P768K_CNT_TO_US(), each count should be 30.5175 us,
not 32.768us.
3. Fix TIMER_CNT_8M_32P768K().
4. Make sure LPC wake up interrupt is enabled before entering doze /
deep doze mode.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=1. Console commands: 'gettime', 'timerinfo', 'waitms', and 'forcetime'.
2. Enabled Hook debug, no warning message received (48hrs).
3. Tested ectool command 'version' x 2000.
Change-Id: I796d985361d3c18bc5813c58705b41923e28c5b1
Reviewed-on: https://chromium-review.googlesource.com/310039
Commit-Ready: Dino Li <dino.li@ite.com.tw>
Tested-by: Dino Li <dino.li@ite.com.tw>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Under NVDC, BGATE natively has a body diode. Hence there's a discharging
path if VSYS is lower than VBAT. This change keeps VSYS voltage when
turning off charging.
BRANCH=none
BUG=chrome-os-partner:46698
TEST=manual
make buildall -j
load on boards with isl9237 charger.
charge the battery to full, and check charging voltage and current.
Change-Id: I8a6046444dd40a3b57f034be124b9e8fe281de40
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309289
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Oops. I was losing one of the args when the USB debugging output
was enabled. And with a lot of messages I was also losing some
of the output.
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: I284606aa91a76262644cfce60913a91ccc36ae60
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310846
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This just adds a .gitignore entry so that git doesn't complain
about the executable you may have built in the extra/usb_console/
directory.
BUG=none
BRANCH=none
TEST=make buildall
This has no effect on the EC code at all. The things in the
extra/ directory are optional and unsupported.
Change-Id: Ib4915f712f9d14caf7418ef4b03aa41e8764fd36
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310840
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reduce system stack size from 4096 to 1024.
Increase code RAM size to 104K and reduce data RAM size
to 20K.
BUG=chrome-os-partner:45690
BRANCH=None
TEST=Tested on Kunimitsu
1. Flash EC, boot up, force to S5/G3, back to S0;
and powerd_dbus_suspend to S3, all work fine.
2. Use console command to dump system stack memory values,
the size used is around 350, >600 still available.
Change-Id: Ib004678cc16f10c94c333063b728a2816ed5b3c5
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/310581
Commit-Ready: Li1 Feng <li1.feng@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Tested-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
LED activity is triggered by HOOK_SECOND. Updated value of led
constants to make sure blinking interval is correct.
BUG=chrome-os-partner:47243
BRANCH=none
TEST=Verified on Kunimitsu battery LED blinks at interval expected.
Change-Id: Ibd1089f3c12b1f449d81aeee9cf430981ae214ea
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/310545
Commit-Ready: Li1 Feng <li1.feng@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
1. refer to commit 8bd44bf4, oak has similar issue:
if power good is lost and the power button still press, we need
cancel the long press timer, otherwise EC will crash.
2. Furthermore, EC will crash too if long press timer is still active
during entering S3.
3. The debounce of suspend & power_good signal can be removed on rev4
because rev4 doesn't adopt level shifter.
BRANCH=None
BUG=chrome-os-partner:46857
TEST=Manual
1. press power button during coreboot, and it can shutdown normally, or
2. run test case:
> test_that -b oak <DUT IP> firmware_FwScreenPressPower
Change-Id: I584d8beeb31b6c01289bfe4790453a4a3bd35b1c
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/309942
Reviewed-by: Rong Chang <rongchang@chromium.org>
When building EC image, in the majority of cases the RW and RO images
are built from exactly the same set of object files, and the RO set of
objects is used as a template to derive the RW set of objects.
This is not necessarily correct in all cases, let's just create an
abstract set of object files and use it to derive the sets for RO, RW
and sharedlib as appropriate.
BRANCH=None
BUG=chrome-os-partner:43025
TEST=tested as follows:
- changed the Makefile to sort all object files in a single list
(instead of sorting them by directory, with the directory list
unchanged). Built all targets, saved all .smap files. Then applied
this change and again built all targets. Compare all smap files,
there were no differences.
- modified board/samus/board.h to trigger building sharedlib
objects, verified that build/samus/sharedlib built fine.
Change-Id: Ie563aca62028cae9e16f067ba20b5e2930355cf5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310389
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This has been bothering me literally for years: once in a while there
would be tons of files in /tmp directory named tmpXXXXXX where XXXXXXX
is some random string.
Finally, it became clear that the files are generated when 'make
buildall -j' is called in the ec directory. Next step - it looks like
one of the culprits is building for board named 'chell'. Indeed, this
board uses its own version of cmd_obj_to_bin make function, which,
among other things invokes the pack_ec script to pack the image.
The script was creating temporary files and leaving them behind.
This patch makes the name pattern of the temp files better
recognizable, juts in case, and makes sure that the files are deleted
once they are not needed.
BRANCH=none
BUG=none
TEST=invoking 'make buildall -j' still succeeds but does not result in
leaving temp files behind.
Change-Id: I50c511773caa87d4e92980c4c9a36768b0c3101f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310586
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Make oak_pd a sym link to glados_pd. A few small changes
necessary to make this possible:
- glados_pd now sets the VBUS present power status bit as oak_pd
does and as is appropriate for TCPCI spec.
- oak_pd now has watchdog enabled (not sure why it was
previously disabled).
- add a flag in gpio.inc to define EC_INT pin on B5 for oak_pd
and A14 for glaods_pd (and all other boards pointing to
glados_pd). Note: this breaks oak board rev 1, where EC_INT was
on A14.
BUG=none
BRANCH=none
TEST=make -j buildall
Load on glados and make sure zinger works.
Change-Id: I28f4ee106e44e2819919f1826508fc1fc05bb2a1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310193
Drop permissions as soon as initialization
is complete. APP code is expected to run
at MEDIUM permission level.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=serial shell starts up
Change-Id: I181d55ca96eb5998ad49856af9f82afb67b03024
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/309919
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Before Oak rev4, it defines 2 wakeup source EC_WAKE(PA0), EC_PWR_BTN_L(PB5).
Due to the wakeup source limitation of STM32F0 (http://goo.gl/VQk9GV),
Oak can only use one wakeup source, because EC_PWR_BTN_L is low-active and
it is kept high always. The HW & SW should be changed after rev4:
Using PA0 as wakeup source only, instead of both (PA0 & PB5).
BRANCH=none
BUG=chrome-os-partner:46670
TEST=Manual on oak rev4 with HW rework.
Detach PD power adapter, run 'hibernate' on EC console, make sure that both
EC and PD go to hibernate, verify the following cases individually:
1. Press power button and verify that both EC and PD wake.
2. Plug PD power adapter and verfy that both EC and PD wake.
Change-Id: Ief37aa1f11a84dd358875f22fa35c484b10bc388
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/309246
Reviewed-by: Rong Chang <rongchang@chromium.org>
Some chips previously defined CONFIG_I2C and others didn't. Standardize
the usage by removing CONFIG_I2C from all config_chip files and force it
to be defined at the board level. Also, make boards define
CONFIG_I2C_MASTER and/or CONFIG_I2C_SLAVE based on the I2C interfaces
they will use - this will assist with some later cleanup.
BUG=chromium:550206
TEST=`make buildall -j`
BRANCH=None
Change-Id: I2f0970e494ea49611abc315587c7c9aa0bc2d14a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310070
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Warm reset key from servo board lets the POWER_GOOD signal
deasserted temporarily (about 1~2 seconds) since Oak rev4.
In order to detect this case, check the AP_RESET_L status,
ignore the transient state if reset key is pressing.
BUG=chrome-os-partner:46655
BRANCH=none
TEST=make buildall -j;
Press warm reset key of servo board, AP should reset normally.
Change-Id: Ib9f111d2273cde61354e72367fe74d4ee15d2291
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/307201
Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-by: Rong Chang <rongchang@chromium.org>
The default battery type of Oak is 3S, in order to compatible to
2S battery, set the minimum voltage of battery to 6V rather than 9V.
BRANCH=none
BUG=chrome-os-partner:46540
TEST=manual
1. connect 2S battery to rev4
2. check the battery info with EC command:
> battery
3. confirm the voltage of battery is match to setting of battery_info.
Change-Id: Ieb7e39817bb0cefa523f73039b68943adb50f045
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/306381
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
1. To enable INT_PRI (hardware interrupt priority level 0~3)
register, bit0@INT_CTRL = 0.
2. GIE need to be enabled before UART is initialized.
[symptom]
To define CONFIG_RWSIG / CONFIG_RSA / CONFIG_SHA256, then power on:
after RW image is verified, firmware stuck in uart_flush_output().
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=1. bit0@INT_CTRL = 0.
2. The RW image is verified and jump to image RW.
Change-Id: I393a3d5f87ea257885b872c91bfce43aecbaea8b
Reviewed-on: https://chromium-review.googlesource.com/309400
Commit-Ready: Dino Li <dino.li@ite.com.tw>
Tested-by: Dino Li <dino.li@ite.com.tw>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
[irq]
1. The chip_init_irqs() function clears all IERx and EXT_IERx registers.
[jtag]
2. Enable debug mode through SMBus.
[system]
3. remove console_force_enabled functions.
4. implement __no_hibernate, scratchpad and nvcontext functions.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=chrome-os-partner:23575
TEST=1. IERx and EXT_IERx registers are all cleared after chip_init_irqs().
2. console command "scratchpad" and "hibernate".
3. bram bank0 index 0x10 ~ 0x1F (16 bytes) for
system_get_vbnvcontext() and system_set_vbnvcontext functions.
Change-Id: If044d50c69ae80b013ab646a3a6931cec7560ec4
Reviewed-on: https://chromium-review.googlesource.com/309390
Commit-Ready: Dino Li <dino.li@ite.com.tw>
Tested-by: Dino Li <dino.li@ite.com.tw>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Create two state machines SMB_WRITE_SUSPEND and SMB_READ_SUSPEND to handle i2c
master stall bus and call i2c_xfer again. Notice we should disable i2c
interrupt since cannot read/write SDA reg to clear interrupt pending bit.
Modified drivers:
1. i2c.c: Modified to handle calling i2c_xfer twice or more.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I781f6f8227867ea9c0e265b3064f48602c0f5f07
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/309381
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Enable USB PD logging.
BUG=chrome-os-partner:45933
BRANCH=none
TEST=make -j buildall
make -j BOARD=glados tests
Load on glados and test that PDLOG events show up in dmesg
Change-Id: I61dbc5019ea3228542c2c244228bbb483cf51ead
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309881
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
I2C1 may be clocked by HSI or SCLK. I2C2 is always clocked by PCLK.
Therefore, apply different timing register values according to the
selected clock source for a port.
BUG=chrome-os-partner:46188
BRANCH=None
TEST=Manual on glados_pd. Verify slave i2c communication is functional.
Change-Id: Icd2306d25d5863b0fc3379e46885a227efb23cca
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309781
Commit-Ready: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
This patch updates the EC codebase to match the latest USB build which
now provides ability to programatically tell between different FPGA
flavors. It also changes the polarity of the 'cold bootsrap' pin, so
using the latest spiflash utility is mandatory.
Note that there has been no signer changes.
BRANCH=none
BUG=none
TEST=as follows:
- programmed the FPGA, it now reports the following when reset:
FPGA |20151029_041713@78167
- booted the new image using the latest spiflash version. Note
that the bootrom now reports the FPGA image it comes from
- disconnected the FPGA upgrade port, rebooted the device, entered
on the device console:
> spstp off
> spste
run on the workstation:
$ examples/spiraw.py -l 10 -f 800000
FT232H Future Technology Devices International, Ltd initialized at 857142 hertz
and observe on the DUT console:
Processed 10 frames
rx count 11574, tx count 5497, tx_empty 10, max rx batch 11
>
Change-Id: I66596061731d9abcf41c5f5984ac479bbc1648e8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309963
Commit-Ready: Vadim Bendebury <vbendeb@google.com>
Tested-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-by: Ewout van Bekkum <ewout@google.com>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Define CONFIG_USB_PD_LOW_POWER by default to save power on both
TCPM and TCPC side by waking PD task less often when possible.
BUG=none
BRANCH=none
TEST=test on glados and samus.
Change-Id: I04441fb8339652cf073689177175a98f28807897
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309311
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Added more improvements to power consumption when using
CONFIG_USB_PD_LOW_POWER. On the TCPC, when this option is
defined, then decrease the PD task wake interval when
we are presenting Rd, we don't have a connection, AND we
haven't dual-role toggled recently. This shouldn't affect
connection time because we will get an interrupt when VBUS
is detected.
Note: we can't use the low power task wake interval when
we are connected because we need to monitor CC line for
Rp change and we can't do this when we are presenting Rp
because we need to quickly detect loss of Rd.
BUG=chrome-os-partner:45010
BRANCH=none
TEST=tested on glados. verified we connect to a charger in
S0 and S5. and verified that in S5, we spend >99% of our
time in deepsleep (as measured by idlestats console command).
note, that when testing EC and PD must both define
CONFIG_USB_PD_LOW_POWER to get maximum power improvements.
Change-Id: I661110cc7021f6d17937688787ea4f5f4b82973d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309310
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
