Since the stm32 MCUs are programmed over the UART, we need to make
some changes to allow the interpreter to stop listening to the UART
PTY when flash_ec needs those PTYs. Otherwise, the EC-3PO interpreter
will interfere with the programming and cause the flash to fail every
time.
BUG=chromium:571170
BRANCH=None
TEST=Use flash_ec to program both veyron_jerry and samus_pd with no
interruptions.
TEST=Use flash_ec to program veyron_jerry without servod changes with
no interruptions.
CQ-DEPEND=CL:321084
CQ-DEPEND=CL:318900
Change-Id: I350fdb708d30c4ec6f18e5dc4abd621370522381
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/320629
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
flash_ec is used for both ec chips accessed over servo, and
standalone stm32 devices. It's not necessary to have a servo
conencted to update the standalone devices over usb.
This is useful for servo v4 and servo micro.
BUG=chromium:571477
TEST=Verify servo micro/discovery can be flashed without servo v2.
BRANCH=none
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: I9deee1616d93feeac4d6675bc3a4f573d4906f7b
Reviewed-on: https://chromium-review.googlesource.com/321925
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@google.com>
Reviewed-by: Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
When flashing the STM32 chip, the flash_ec script stops the processes
which occupy the EC UART in order to avoid their interference. After
flashing, it asks these process to continue.
However, when running FAFT in the lab, the EC UART may be occupied by
servod for sending some EC commands per test requirements. The
flash_ec should not stop the servod; otherwise, all the following
dut-control commands will be failed.
So this change blacklists the process servod and init.
BRANCH=none
BUG=chromium:552073
TEST=Manual
Ran a FAFT test, e.g. firmware_FAFTSetup, which occupies EC UART.
Ran another process, e.g. minicom, which also occupies EC UART.
Ran the flash_ec: flash_ec --chip stm32 --image /tmp/ec.bin
Its output:
INFO: Using ec image : /tmp/ec.bin
INFO: ec UART pty : /dev/ttyO1
INFO: Flashing chip stm32.
INFO: Using serial flasher : /usr/bin/stm32mon
INFO: Sending SIGSTOP to process 2369!
INFO: Sending SIGSTOP to process 7949!
INFO: Skip stopping servod or init: process 1.
INFO: Skip stopping servod or init: process 639.
...
INFO: Restoring servo settings...
INFO: Sending SIGCONT to process 2369!
INFO: Sending SIGCONT to process 7949!
Change-Id: I4d72b7e2caf0ca2963bb9dee51764869e829c569
Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313581
Commit-Ready: Wai-Hong Tam <waihong@chromium.org>
Tested-by: Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Currently, using flash_ec for mec1322 chips only
supports flashing from servo v2. Updated to work from
v3 as well. This is a resubmission.
BUG=chromium:554230
BRANCH=None
TEST=tested locally with beaglebone/cyan setup at my desk
Ran flash_ec --board=cyan --chip=mec1322
--image=/tmp/image.bin. Also ran with servov2.
Change-Id: Ia2a7edb577350cd4aa1c9835f24f4e3df2e508e2
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313053
Reviewed-by: Wai-Hong Tam <waihong@chromium.org>
Currently, using flash_ec for mec1322 chips only
supports flashing from servo v2. Updated to work from
v3 as well.
BUG=chromium:554230
BRANCH=None
TEST=tested locally with beaglebone/cyan setup at my desk
Ran flash_ec --board=cyan --chip=mec1322
--image=/tmp/image.bin
Change-Id: Ibc1109a60e93d1034519b31ce58c5e4d45ab505c
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312578
Add chell_pd to the STM32 list and the USBPD override list.
BUG=chrome-os-partner:46289
BRANCH=none
TEST=successfully run "flash_ec --board=chell_pd"
Change-Id: Ic4ddbe51a0586c563211fd76f20a85428e565546
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308726
Reviewed-by: Shawn N <shawnn@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>
Make sure to restore boot_mode gpio for all MCUs. Previously,
only usbpd_boot_mode was restored, but not ec_boot_mode which
is used on lucid.
BUG=none
BRANCH=none
TEST=flashed lucid (ec_boot_mode), glados_pd (usbpd_boot_mode),
and zinger (boot_mode) and verified that the boot_mode gpio was
restored to off at the end of flashing.
Change-Id: Ib6fcddcac6d00465e31a0e710bae3b8318bac659
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/301338
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Fixed bug during polling port 0x204 by BIOS.
We should set processing flag before reading command byte in ISR to prevent
EC_LPC_STATUS_FROM_HOST and EC_LPC_STATUS_PROCESSING bits are both low.
Modified drivers:
1. gpio.c: Add LRESET ISR.
2. lpc.c: Fixed bug during polling port 0x204 by BIOS.
3. flash_ec: Reset ec before flashing ec
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I8e557f2e2be41a7a9d40c03c775313b12668f283
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/291210
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
The flash_ec script is called by the lab infrastructure to flash
the EC firmware of DUT. To prevent the EC flashing tool hanged
forever (may be caused by some bugs), set a 10-minute timeout to
force it to be killed.
BRANCH=none
BUG=chromium:514810
TEST=Patched the change to servo v3. Triggered flash_ec to flash EC
on Jerry. Set the timeout to a small value to force to kill itself.
test2:
./flash_ec --board=hadoken # or samus, anything using openocd
remove the USB cable half way through (openocd hangs)
ps au | grep openocd
Change-Id: I39ad8659b41764fd0dba30a86eca301fbbc5243f
Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289247
Commit-Queue: Myles Watson <mylesgw@chromium.org>
Jerry is being used for FAFT in the lab. Remove Pinky instead.
BUG=chromium:511324
TEST=make buildall -j
BRANCH=none0
CQ-DEPEND=CL:288258
Change-Id: I03ddc74a4e72353f3408da8e374ad925baf00a35
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/288237
Reviewed-by: Wai-Hong Tam <waihong@chromium.org>
The flash_ec uses the given board name to select a proper flashing
method. It keeps a mapping from board name to chip name.
This approach is not scalable if we want this script to work on
all supported board variants, like the pinky family which has many
boards: jerry, minnie, speedy, etc.
This change adds a new argument of chip name, such that we can only
keep the mapping of major boards. Other boards not listed can use
the chip argument to select a proper flashing method.
BRANCH=none
BUG=chromium:505003
TEST=Ran the script on Beaglebone/Servo v3 connected with Jerry:
$ flash_ec --chip stm32 --image ec.bin
Change-Id: I553ee68f82a7985a37548dfb6e89b364eaffd0f1
Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/287445
Reviewed-by: Dan Shi <dshi@chromium.org>
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Remove ryu_p4p5 EC board code along the "splitted" Sensor hub board
(ryu_sh/ryu_sh_loader): It's time to get rid of oldies.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=smaug
BUG=chrome-os-partner:38333
TEST=make buildall
CQ-DEPEND=*I6df51d7b4be2be7217604da60462b8c9d0cde1d2
Change-Id: Iebc4022267afccb5057c856d624e56a850ecbd70
Reviewed-on: https://chromium-review.googlesource.com/286780
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
rename setup_openocd -> flash_openocd
refactor so that flash_npcx and flash_lm4 set OCD_CMDS and call flash_openocd
BRANCH=none
BUG=chrome-os-partner:22990
TEST=run flash_ec before and after and compare the sequence of calls to
dut-control and the command-line args to openocd
tested with ryu (non-lm4), samus, link, npcx_evb, and peppy
Change-Id: I7a05e3219d4b324bcf19a20f86b149f8e3377465
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273907
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Board jerry was removed from the list in CL 276524. The board share the same
overlay as pinky. So ideally user can call flash_ec with board set to pinky.
This applies to other veyron boards in BUG 505003 as well.
However, servo in the lab runs on ToT, and it only updates firmware of the dut
by calling flash_ec with board name retrieved from the overlay file. Also, lab
has a tool to check the servod's board and the dut's board. That is, if we
change servod to return board name pinky for servo connected to a jerry dut,
the lab script will raise a warning that the servod is running with a wrong
board.
Before we have a good design to really address the issue, I'd like to add jerry
back to flash_ec so the board can run FAFT in the lab.
BUG=chromium:505003
BRANCH=None
TEST=None
Change-Id: I155e79710f2731701af0acdfeab6089701cf52a8
Reviewed-on: https://chromium-review.googlesource.com/283494
Tested-by: Dan Shi <dshi@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Dan Shi <dshi@chromium.org>
Add npcx_evb_arm board-level driver for arm-based platform.
Add header.c: for booting from NPCX5M5G A3 Booter.
Remove lfw folder due to those functionalitie have been replaced with Booter
Modified drivers for
Patch Set 1:
1. flash.c: Implement UMA lock, tri-state and selection register lock functionalities
2. hwtimer.c: Add ITIM32 for hwtimer
3. lpc.c: Add checking for LRESET
4. system.c: Modified CODERAM_ARCH functions for NPCX5M5G A3 Booter.
5. uart.c: Add support for module 2
Patch Set 2:
6. lpc.c: Modified lpc_get_pltrst_asserted() func
Patch Set 3:
7. minimize the changes for CONFIG_CODERAM_ARCH in common layer
8. comments of Patch Set1/2
Patch Set 4:
9. Modified CONFIG_RO_MEM_OFF point to ro image and keep header as a part of ec.RO.flat.
10. Fixed RO_FRID and RW_FRID issues which caused by CONFIG_CODERAM_ARCH.
Patch Set 5:
11. Modified system.c in common folder for supporting *_STORAGE_OFF.
12. Use *_STORAGE_OFF in firmware_image.lds.S to indicate flat file layout in flash.
Patch Set 6:
13. rebase to newest version
14. system.c: Modified for the newest include/system.h
Patch Set 7:
15. Merge from version 0625
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: Ifd7c10b81b5781ccd75bb2558dc236486976e8ed
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/272034
Reviewed-by: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>
There is no need for the usb flag, remove it.
There is no need for the unprotect flag, remove it.
BRANCH=none
BUG=chrome-os-partner:22990
TEST=run flash_ec before and after
Change-Id: I201bad7f5be63a90bb8168e21baef2c6fa8d85b4
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273904
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If host running flash_ec has multiple servo's connected it must use
the USB serialname to identify the proper FTDI device to run flashrom
on correctly. CL adds serial param to flashrom call to do just that.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=none
TEST=manual, successfully write glados EC w/ multiple servo V2's
connected to the same host.
Change-Id: I35c7d170f9bb80e96f69efae634cf70893eeef63
Reviewed-on: https://chromium-review.googlesource.com/276761
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Now that we've removed boards from ToT, also delete board-specific
code used only by the removed boards.
There are still more things to remove (unused charging chips, LED
drivers, COMx support). More CLs coming.
BUG=chromium:493866
BRANCH=none
TEST=make buildall -j
Change-Id: Ie6bdeaf96e61cadd77e3f6336c73b9b54ff4eabb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/276524
Reviewed-by: Alec Berg <alecaberg@chromium.org>
hdctools adds an alias ec_boot_mode and remaps spi1_vref with onoff
control. This change switches ARM systems with STM32 EC from
spi1_vref:pp3300 to ec_boot_mode:on.
CQ-DEPEND=CL:275251
BRANCH=none
BUG=chrome-os-partner:40479
TEST=manual
cd ~/trunk/platform/ec
util/flash_ec --board oak --image oak_ec.bin
util/flash_ec --board oak_pd --image oak_pd.bin
Change-Id: I0f3a74eaa7fc937d1372cd51124c6b3d23351581
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274770
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org>
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>
