mec1322 only has 96KB program memory, vs 256KB
flash space on lm4.We no longer have enough program
memory to load both RO and RW at boot. We'll want to
implement a small loader program that will load either
RO or RW from flash, and then jump to the loaded image.
CONFIG_FW_INCLUDE_RO is enabled to include RO image into
the build.
pack.py script is altered to load the (lfw + R)O on boot.
Software sync is not added.Distinguish between
RO/RW is yet to be added.
flash_ec is altered to support padding 0xFFs to 256k ec.bin
to match the size of the SPI flash of the board.
BUG=chromium:37510
BRANCH=None
TEST=Make -j buildall,Verified ec.bin to be 256k.
Verified RW image at offset 0h and (lfw + RO) at offset 2000h.
On boot sysjump to lfw. lfw checks in shared SRAM (currently RO)
and jumps to RO image.
Change-Id: Ib9b114e2f24a615d5e5bd8b3803be621d1e5bd17
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265807
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Icarus W Sparry <icarus.w.sparry@intel.com>
The warm_reset_l signal is an open drain output on the servo side and
its input value can be read back as on (level 0) when the AP power rails
are off on the DUT side and not pulling it up.
So the current mechanism of reading the warm_reset input value with
dut-control at the beginning, then restoring it at the end is sometimes
broken because when the AP is OFF, we are reading input == on (while we
had actually set output to "off" but we have no pull-up) and then
restoring a "hard" on (drive low on the servo side).
In this workaround, just assume we don't want to pull warm_reset after
flashing the EC and restore it to off.
A better solution might be to have a mechanism in dut-control to read
the output register rather than the input value for GPIO, so we can save
and restore them safely.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:30738
TEST=On Ryu P5 with the AP off, run ./util/flash_ec --board=ryu
then boot the AP properly with the power button.
Change-Id: I96e65c2fec5e6d604445af3fe26fce73678b1d3b
Reviewed-on: https://chromium-review.googlesource.com/265223
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Modified version of /board/fruitpie.
Attempted to capture GPIO definitions. Other changes
consisted of modifying functions to enable compilation.
No real functionality as of yet.
TEST=Serial console and I2C functions have been verified
BUG=chrome-os-partner:37078
BRANCH=samus
Change-Id: Iedfc724a058e4220176193ef0f66e5bf45eabbd9
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252426
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The switch to PID namespaces inside the chroot broke flash_ec's ability
to detect (and then kill) other processes that use the EC serial PTY
(leading to potential flashing failures). After a long discussion we
decided that users who need features like this should be forced to run
their chroot without PID namespacing (using cros_sdk --no-ns-pid). This
patch adds a hard check for this to flash_ec, so that using it in an
unsafe way becomes impossible.
In addition, this ports the more advanced SIGSTOP/SIGCONT logic to
flash_ec that was pioneered in fwgdb. With this, other processes
accessing that PTY will just freeze and become available again after
flash_ec finished.
BRANCH=none
BUG=chromium:444931
TEST=Ran on a Jerry with and without --no-ns-pid, with and without
an open EC terminal, all results as expected.
Change-Id: I45ffc3ec6cfe9c25a0b82b4d5288a41485c326c4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249835
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is to add llama board support:
- new files in board/llama folder, including battery.c and led.c
- new file power/mediatek.c, which is mostly based on power/tegra.c
- modified flash_ec for llama board
- disable tests for llama board.
BRANCH=none
BUG=none
TEST=make BOARD=llama
Change-Id: Ie1ae068c1a402f08e1449668b1be8f31105bb804
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/243510
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: lok.ben ben.mtk <ben.lok.mtk@gmail.com>
Commit-Queue: lok.ben ben.mtk <ben.lok.mtk@gmail.com>
The STM32 bootloader reacts to the first command it sees and then sticks
to that interface. On some devices, the AP is connected to I2C or UART
on the EC, and if the AP talks when we are trying to flash the EC, the
EC sticks to that interface and ignores requests from the servo board.
Fix this by holding warm_reset so that the AP is down.
BRANCH=None
BUG=None
TEST=Flash Ryu several times.
TEST=Flash Plankton to make sure it doesn't break devices without
warm_reset.
Change-Id: I860fc65ba7fdaf0cbc9a0be641148b5095de394b
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/247360
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@google.com>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Adding setup_openocd function to take care of setup of either servo v2 and or
servo v3 setup (setting up OCD_PATH and OCD_CFG variables). Have modified
flash_link, flash_lm4, and flash_npcx functions to use setup_openocd function.
BUG=chromium:412249
BRANCH=None
TEST=made sure that outputted flash_ec command lines prior/after change on host
are identical for link and peppy. Also made sure that flash_ec command
works on peppy with updated image on beaglebone. Also ran "make runtests".
Change-Id: Iacf42fae1f175d6acd08bbd16352afb8f3bd21b0
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242043
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add npcx_evb in board folder for testing
Add shared-spi arch support in common layer.
Modified drivers for
1. Fan.c: console command “pwmduty”.
2. Pwm.c: for the issue when set duty to 0.
3. System.c: for hw reset only during system reset.
4. Flash.c: Fixed access denied bug of the flash driver for host command.
5. Comments from Patch Set 1
6. Comments from Patch Set 3 (except sha256.c)
7. Add openocd and flash_ec support for npcx_evb
8. Add little FW and spi-flash upload FW in chip folder
9. Add optional make rules for PROJECT_EXTRA
10.Replace CONFIG_SHRSPI_ARCH with CONFIG_CODERAM_ARCH and remove changes
in common layer sources for shared-spi arch. (except sysjump)
11.Find the root cause of JTAG issue and use workaround method
with SUPPORT_JTAG in clock.c
12 Execute hibernate in low power RAM for better power consumption
13 Add workaround method for version console command
14 Modified coding style issues by checkpatch.pl tool
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I5e383420642de1643e2bead837a55c8c58481786
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233742
These USB type-C accessories don't have a write-protect GPIO.
Add a configure flag (CONFIG_WP_ALWAYS) to force the flash
write-protection on the dongles.
Also set the read protection (by elevating RDP to level 1),
so trying to unprotect the flash will trigger a full erase.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35088
TEST=boot Hoho,
check the flash OBR and WRPR registers:
"rw 0x4002201c" / "rw 0x40022020"
and the option bytes write-protect bits: "rw 0x1FFFF808"
dump the logical state with "flashinfo" command.
> rw 0x4002201c
read 0x40022020 = 0xffff0002
> rw 0x40022020
read 0x40022020 = 0xffff0000
> rw 0x1FFFF808
read 0x1ffff808 = 0xff00ff00
> flashinfo
Physical: 128 KB
Usable: 128 KB
Write: 2 B (ideal 2 B)
Erase: 2048 B (to 1-bits)
Protect: 4096 B
Flags: wp_gpio_asserted ro_at_boot ro_now
Protected now:
YYYYYYYY YYYYYYYY ........ ........
Change-Id: I45bbc0bce40ecc174b6b8a1ebacf4f53d2fd372d
Reviewed-on: https://chromium-review.googlesource.com/238893
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Check the flash protection at startup, if the RDP is still at level 0
(no read protection) or if the RO partition is not write protected :
- set the write protection on the first 16KB of flash (4 LSB of WRP0)
- push the RDP to level 1, so SWD/serial monitor needs to fully erase
the part before re-writing the code or the write-protection.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34935
TEST=dump the content of the option bytes.
Change-Id: I11af64365a6fbc34327b2e463eb8e2d369ffacd2
Reviewed-on: https://chromium-review.googlesource.com/238262
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This simply renames ryu to ryu_p1, and ryu_p2 to ryu. 'ryu_p1' will be
kept for a while and will be decommisioned when most developers make
switch to the new boards.
BRANCH=None
BUG=chrome-os-partner:33583
TEST=Build ryu and boot on P2 board.
Change-Id: Ief61c64c6aefdaeae76ac7b86e0ea28131810aa1
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229291
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The new build target ryu_p2 is mostly based on ryu. On ryu_p2, we have a
new EC chip with bigger flash, so make the corresponding changes:
- Pinout changes
- HW Timer: TIM5
- USB PD Tx Timer: TIM3_CH4
- USB PD Rx Timer: TIM2_CH4
- Use UART2 for EC console
- Disable UART Tx DMA as it conflicts with USB PD Tx DMA
- Use 24MHz HSE x2 = 48MHz for SYSCLK
BRANCH=None
BUG=chrome-os-partner:32660
TEST=Sanity check on a new board:
- i2cscan
- PD negotiation
- UART console
- gettime
Change-Id: I4ef6b53a928a2777721e3874032aeb0e6b2b4c92
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221404
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allows dingdong to receive initial USB PD communication (source
capabilities payload) and with some manual manipulation (see 'TEST=')
drive DPout.
CL is based heavily off hoho dongle where all files were copied from
board/hoho:
7b1e58c ectool: Add host command support to set fan RPM for each
fan separately
Files gpio.inc, board.h & board.c were modified but others should
be identical.
BRANCH=none
BUG=chrome-os-partner:31193
TEST=manual,
When attaching dingdong to samus_pd and configured via
'pd dualrole source'
I see following on samus_pd console:
C1 st9
Switch to 5000 V 900 mA (for 900/900 mA)
C1 st10
C1 st11
C1 st12
showing power constract and transition to SRC_RDY:
> pd 1 state
Port C1, Enabled - Role: SRC Polarity: CC1 State: SRC_READY
> typec 1 dp
Also if I connect in CC1 configuration and get access to dingdong
console I can
> gpioset PD_SBU_ENABLE 1
And see dingdong drive external monitor
Change-Id: I30ef6f8503a3fb015cfb8806bc36fb98f5150e40
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221913
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Seems that all previous boards used the subvariant specific name, and had an
alias from emerge-variant_subvariant to the ec subvariant folder.
BUG=chrome-os-partner:32331
BRANCH=None
TEST=cd board/pinky; make clean && make -j && ../../util/flash_ec --board=pinky
Change-Id: Ie6e0c977b6659687357a1b5aa2915cf0e40a5da7
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221904
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Minimuffin is identical to zinger, same MCU, same gpio, same
circuitry aroundt the MCU with two differences:
- Rated current is 2.25A instead of 3A
- USB PD hardware device ID needs to be different so that host
can differentiate between the two.
Due to the similarity between the two, minimuffin is defined
as a symlink to the zinger board.
BUG=none
BRANCH=samus
TEST=make BOARD=minimuffin
load onto a zinger and verify that samus reads device ID correctly
and limits input current limit to 2.25mA.
Change-Id: Ie39ec43262c7d14663eb68abff073bfeec451a24
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220689
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a command-line option to ask stm32mon to read the EC firmware image
to flash from the standard input when the filename is replaced by a "-".
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:398165 chromium:396233
TEST=use the following flashing commands:
cat build/fruitpie/ec.bin | ./util/flash_ec --board=fruitpie --image=-
./util/flash_ec --board=fruitpie
./util/flash_ec --board=fruitpie --image=build/fruitpie/ec.RO.flat
and check the content of the flash.
Change-Id: I8039ecb6910f912161a7f59c5f5e2fc80447ce7b
Reviewed-on: https://chromium-review.googlesource.com/220842
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Add setting of new GPIO, prog_en, to flash_ec to be able to program
new plankton boards. This pin must be on for boot0 and nrst to be
connected from the FTDI to the MCU.
BUG=chrome-os-partner:31633
BRANCH=none
TEST=manual,
sudo servod -c plankton.xml
util/flash_ec --board=plankton
CQ-DEPEND=CL:216160
Change-Id: I29f882856e24147a7af283c5e82298c7736b8662
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216161
Reviewed-by: Todd Broch <tbroch@chromium.org>
Passing the "--usb" argument will now utilized case-closed
debugging for flashing the EC. Currently this is only supported
for the samus LM4-based board.
BRANCH=none
BUG=none
TEST=verify that when the case-closed debugging flag is set, the
alternate openocd config file is used for samus, and an error is
thrown for all other boards
Change-Id: I0642bc2e9c2657cd8dbd83ee6e282365275d665a
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This fixes the bug that SRC_ROOT is not set. This should be the last fix
for flash_ec. DEFAULT_BOARD is intentionally left as is. For developers
who don't want to use --board option every time, they need to set
DEFAULT_BOARD in their environment variables.
BUG=chromium:397202
TEST=util/flash_ec --board=link
BRANCH=None
Change-Id: If23f73adbd37f2a79cb5176e3665562e278f46db
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210523
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
If chromeos-ec package hasn't been built, flash_ec tries to find
stm32mon in local build/ directory. However, this is broken in the last
CL when we move away from crosutils. Let's fix it.
BUG=chromium:397202
TEST=Flash samus_pd
BRANCH=None
Change-Id: I05395a727fa965032a24f51c07deaebf2d7c7e51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210419
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The script currently depends on common.sh from crosutils, which is not
installed on beaglebone and also pulls in dependency on other
repositories. Let's switch to shared shflags library and include output
formatting functions in flash_ec script. This way we are independent
from crosutils.
BUG=chromium:397202
TEST=Run the script to flash EC
BRANCH=None
Change-Id: Ib18987410eb32d773d55fb4e53133adf230167b9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209827
Reviewed-by: Dan Shi <dshi@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Board support for Planton, the Raiden testing board for type-C
functional testing.
BUG=none
BRANCH=none
TEST=make BOARD=plankton, load onto a plankton, and verify
buttons are read correctly, and connect raiden to samus and
verify that PD communication is successful
Change-Id: I40922d5627d62f7f3540ac6a307596428d40baf5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207724
servo is already aware of the sensor hub.
Using samus_pd as an example, set the proper argument to flash
an image to the sensor hub.
BUG=chrome-os-partner:30801
BRANCH=None
TEST=None
Change-Id: I0c8465d1e34d515224675957c3e8482392585a56
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209232
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The 2 boards are similar enough to test stuff on big for now, at least
until the new hardware comes.
Also added veyron to flash_ec.
Also cleaned up the style: pre-upload.py was giving errors on files
that were unmodified from big(spaces instead of tabs).
I had to ignore this though:
> ERROR: Macros with complex values should be enclosed in parenthesis
> #471: FILE: board/veyron/board.h:35:
> +#define KB_OUT_PORT_LIST GPIO_A, GPIO_B, GPIO_C
BRANCH=none
BUG=chrome-os-partner:30167
TEST=~/trunk/src/platform/ec $ make BOARD=veyron clean &&
make -j BOARD=veyron && util/flash_ec --board=veyron --ro
verify ec is alive and version is reported as veyron
Change-Id: I1f4bd562c0ab55360a2160a753ad8ad9b58f8c47
Signed-off-by: Alexandru Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207270
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Twinkie only has test points for uart connection so nominally it will
need to be programmed via DFU mode over USB micro-B connection.
This CL changes from programming via flash_stm32 function and instead
adds dfu support.
BUG=chrome-os-partner:28337
TEST=util/flash_ec --board=twinkie successfully programs twinkie f/w
Change-Id: Ia5433b569579bb879bd405e98921450764510a73
Reviewed-on: https://chromium-review.googlesource.com/204749
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
CL manages various dut-control dependencies for readying the STM32
part for programming.
Additionally deprecated the short-lived --uart_prefix argument as
user's defining this could be problematic without knowledge of
necessary modifications to h/w & s/w.
Signed-off-by: Todd Broch <tbroch@chromium.org>
CQ-DEPEND=CL:200146
BRANCH=none
BUG=chrome-os-partner:28826
TEST=manual,
util/flash_ec --board=samus_pd succeeds.
util/flash_ec --board=spring succeeds.
Change-Id: I7627c77293da187700aeddf7382dbb12e163a2ef
Reviewed-on: https://chromium-review.googlesource.com/200148
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
There are CrOS devices that have multiple embedded controllers and
therefore multiple uarts that can be used for programming.
This CL allows user to set the uart_prefix to access the alternate
uarts via the --uart_prefix argument. Default is still 'ec'.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28826
TEST=util/flash_ec --board=samus_pd --uart_prefix=usbpd
Change-Id: I9fbe8d13067b7f514447645b2587dda706445661
Reviewed-on: https://chromium-review.googlesource.com/199900
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Since we already created the firmware-nyan-5771.B branch, we can
remove this from ToT now. But for sure we are still able to
cherry-pick changes back to ToT or from ToT.
BUG=none
BRANCH=tot
TEST=make buildall
Change-Id: I637d27b9f8672c5d17b60e210a5211ab8e19b54a
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197165
When using a "non-servo" debug dongle or integrated FTDI chip to flash a STM32
microcontroller, add the option to toggle the reset of the
microcontroller if the control exists.
This was not done for the original Toad version because it cannot
control the reset line, but now Firefly, Zinger, Fruitpie debug
interfaces can do it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=./util/flash_ec --board=zinger
Change-Id: Ia21e3b3403e56b4c0797582659d9a3a0c26bb8bb
Reviewed-on: https://chromium-review.googlesource.com/197050
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
