The code mixes up using of full flash addresses and flash segment
addresses (full address divided by 16). The vast majority of uses in
fact requires full addresses, but all definitions are using segment
addresses.
This patch converts definitions to full addresses, which improves
overall code readability.
BRANCH=none
BUG=none
TEST=verified that the signer signed image still boots properly on
CR50.
Change-Id: I35663c14357545c08ac1824d653c29cf6c4dda4d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311313
Reviewed-by: Nagendra Modadugu <ngm@google.com>
The PCH_RTCRST signal is active high controlling the gate of a FET.
Therefore, it's default state should be low.
BUG=chrome-os-partner:47505
BRANCH=None
TEST=Built. The FET is unstuffed on both boards currently.
Change-Id: Ia0e07e67e6ea4eecf151ac8890ad98c8a337c01e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312061
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
SERIRQ bug:
PMC1/2 share the same IRQ number 1 with default setting. Enable it will
influence 8042 protocols since KBC has no data but IRQ 1 is issued by
PMC.
AC detection bug:
GPIO definitions between AC_PRESENT and ACOK mismatched. AC_PRESENT will
always
be high even we don't plug the adaptor.
Modified drivers:
1. lpc.c: Remove enabling SERIRQ for PMC1/2 and disable IRQ12 for Mouse.
2. config_flash_layout.h: Modified for adjusting RAM size.
3. gpio.inc: Modified GPIO definitions for AC issue
4. board.h: Modified for adjusting RAM size and add support for ACC
5. board.c: Add support for ACC and adjust ADC max value
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: Ib330ef4078e4b06f1c01a2a6316e468b43d7a8d9
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/311933
Reviewed-by: Randall Spangler <rspangler@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 AP and EC boot. Suspend/Resume and verify that port80
data is in the history.
TEST='sysjump rw' suspend/resume nad verify that new port80 writes are
present in the history.
TEST=make -j buildall tests.
CQ-DEPEND=CL:311209
Change-Id: Idebb3247b55465f1fbf35a33dff2f00968b8f4ce
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/311365
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This commit introduces a new CONFIG_* option. To utilise the
experimental console, simply define the following config option in the
board's board.h file.
#define CONFIG_EXPERIMENTAL_CONSOLE
This is a temporary option which allows the EC console to be work with
the EC-3PO interactive console interface. When this option is enabled,
the EC expects commands to packed in a particular format. This is for
command integrity and allows the interpreter to perform automatic
command retrying in the event that a character is dropped from the sent
command.
It also removes a lot of the console editing methods since they are now
being served by EC-3PO.
Once the EC-3PO interpreter is pulled into servod, we can enable this
feature by default and the config option can go away.
BUG=chrome-os-partner:46054
BRANCH=None
TEST=make -j buildall tests
TEST=Enable CONFIG_EXPERIMENTAL_CONSOLE on GLaDOS; Flash EC and verify
that console works via the EC-3PO interactive console interface.
TEST=Build and flash on GLaDOS and verify normal console operation on
standard EC UART.
CQ-DEPEND=CL:308615
Change-Id: I5e66eb94e31299b27ce029b7f7ce6ba0a7fb6816
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/309991
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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. Perform typing test with no jank
or other oddities.
TEST='sysjump rw' and repeat the typing test.
TEST=Hold down arrow down and issue 'reboot' command.
TEST=make -j buildall tests
CQ-DEPEND=CL:311209
Change-Id: I35911862af2a4e9feb795b2a9a2aafa97687e2f2
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/311411
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
EC-3PO is the console interpreter that will one day replace the EC console
that we have today. EC-3PO aims to migrate our rich debug console from
the EC itself to the host. This allows us to maintain our rich debug
console without impacting our EC image sizes while also allowing us to
add new features.
This commit is the 1st of three phases, the insertion phase. The main
goal of this insertion phase is to get EC-3PO in place between servo and
the EC UART, while not modifying the behaviour of the console too
much. At this point, EC-3PO is capable of the following things:
- Replicate command editing.
- Save command history.
- Performs error checking with console commands.
The command editing should be at parity with the current EC console.
With EC-3PO, one can have a much longer command history which also
persists across EC reboots. And lastly, with a cooperating EC image,
EC-3PO can perform error checking with console commands. Automatically
retrying console commands if the command was incorrectly received at the
EC end.
Currently, commands are sent to the EC in a "packed" plaintext form.
The next phase will introduce the host command packet communication.
console.py is the module that provides the console interface between the
user and the interpreter. It handles the presentation of the console
including command editing.
It also has an accompanying set of unit tests in console_unittest.py.
It currently has 1 test suite to test the various console editing
methods.
interpreter.py is the module that provides the interpretation layer
between the EC and the user. It also is responsible for the automatic
command retrying. It requires pipe connections to be made to it for
command and debug data communication.
BUG=chrome-os-partner:46054
BRANCH=None
TEST=util/ec3po/console_unittest.py
TEST=Flash GLaDOS with a modified EC build. Run console.py passing the
EC UART, verify that I can edit commands, send commands, view command
history, and receive output from the EC.
TEST=cros lint --log-level debug ./util/ec3po/console.py
TEST=cros lint --log-level debug ./util/ec3po/interpreter.py
TEST=cros lint --log-level debug ./util/ec3po/console_unittest.py
Change-Id: I38ae425836efd69044334e1ed0daf3f88a95917c
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/308615
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Wai-Hong Tam <waihong@chromium.org>
Fix bug with the new VBUS_NEVER_LOW flag in which if a BC1.2 charger
is attached on boot, we will not set the charger as a dedicated
charger and therefore not charge from it, until the charger is
disconnected and reconnected. This happens because in SNK_DISCOVERY
we will send soft reset first, and then when the charger doesn't
respond, we send hard reset. But, registering the charger as a
dedicated charger previously only happened when we send hard reset
directly after SNK_DISCOVERY state.
BUG=none
BRANCH=none
TEST=tested on glados. sysjump with bc1.2 charger plugged in and make
sure we charge from it.
Change-Id: Ida89304092a2186bcb2aa885917d706231490288
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311364
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
When SPI CS is deasserted, SPI MISO is floating, which leads to leakage.
BUG=chrome-os-partner:42104
BRANCH=None
TEST=Manual on glados. Verify S5 power drops by ~1.5mW and sysjump / EC
RW hashing continues to function.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I0ba8fcab1618f396adc32984da93e37c5ff770a4
Reviewed-on: https://chromium-review.googlesource.com/311821
Commit-Ready: Shawn N <shawnn@gmail.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Re-order logic in BC1.2 detection task so that we open the
USB switches immediately upon detecting a connection, then
debounce the connection, then reset the pericom and determine
BC1.2 charger type.
This fixes two problems:
- Problem where host could enumerate dut, detect disconnect,
and then re-enumerate.
- Problem where sometimes dut would detect a host workstation
as a proprietary charger because we weren't delaying long
enough after opening USB switches before triggering pericom
reset.
BUG=chrome-os-partner:47219
BRANCH=smaug
TEST=tested by connecting workstation to ryu (tested both
pluggin in A side first and C side first). Without this patch,
my workstation often see's disconnect and reconnect. With
this change we only get one connect.
Change-Id: I07cc3473ff32953fad3cc6d1db01b86b44969c4e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311804
Reviewed-by: Shawn N <shawnn@chromium.org>
Enable the option to reset the EC when the PD panics.
BUG=chrome-os-partner:46289
BRANCH=none
TEST=verify that if PD is in RW and reboots then the EC
will panic and print "PD crash".
Change-Id: I69ab08914aef08b5ef0eaa447c142444113c526c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311308
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Until we update the naming for our various images in the
Makefiles, let's change the bootloader message slighty, so that
instead of seeing two "RO" images:
CR50 RO, 20151104_41733@78962
Valid image found at 0x00044000, jumping
--- UART initialized after reboot ---
[Reset cause: power-on]
[Image: RO, cr50_v1.1.4008-957a842 2015-11-07 00:28:37 wfrichar@wintermute4.mtv.
corp.google.com]
[0.000897 Verifying RW image...]
we see the bootloader, and then what we've been calling the RO
image, and then the RW image:
cr50 bootloader, 20151104_41733@78962
Valid image found at 0x00044000, jumping
--- UART initialized after reboot ---
[Reset cause: power-on]
[Image: RO, cr50_v1.1.4008-957a842 2015-11-07 00:28:37 wfrichar@wintermute4.mtv.
corp.google.com]
[0.000897 Verifying RW image...]
BUG=none
BRANCH=none
TEST=make buildall, try it
No new functionality, just a different message on the console.
Change-Id: Ia8dce600c7d159416dc6dabbbf0c0cc4129a988d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311831
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We were just checking to see if the UART TX unit was idle. We
also need to be sure there aren't any bytes in the TX FIFO that
haven't been clocked out yet.
BUG=none
BRANCH=none
TEST=make buildall, manual
Before, "crash watchdog" would truncate the trace dump as it
rebooted. Now it doesn't.
Change-Id: Icff828445801ce61a0a8f296b3d3e9fb300b7efc
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311299
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When we lower the runlevel for security purposes, the standard
ARM watchdog interrupt is no longer enough to cause a full
reboot. We'll manually trigger a system reset instead. For now,
it's a soft reset. Should it be hard?
BUG=chrome-os-partner:47289
BRANCH=none
CQ-DEPEND=CL:310975
TEST=make buildall, manual
From the console, run "crash watchdog". After a second or to,
the watchdog trace dump appears and the system reboots.
Change-Id: I99fcaf19b32728563e3b051755d65267cc11156c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311298
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Add support for flash the ite ec from usb gpio port
Signed-off-by: Donald Huang <donald.huang@ite.com.tw>
BRANCH=none
BUG=none
TEST=Test OK on ITE8390CX from both GPIO PORT (C1,C2) (H5,H6)
You can run "make -j BOARD=it8380dev" to build ec.bin
and flash the ec.bin via
"sudo ./build/it8380dev/util/iteflash -w ./build/it8380dev/ec.bin"
/* ==SNAPSHOT START== */
(cr) (br-iteflash) donald@donald-nb ~/trunk/src/platform/ec $ sudo ./build/it8380dev/util/iteflash -w ./build/it8380dev/ec.bin
Waiting for the EC power-on sequence ...CHIPID 8390, CHIPVER 82, Flash size 256 kB
Done.
CHIPID 8390, CHIPVER 82, Flash size 256 kB
Erasing chip...
/100%
Writing 262144 bytes at 0x00000000
Done.
/* ==SNAPSHOT END== */
Change-Id: I422db6f7007622f8be624a534a482e24d53a061a
Reviewed-on: https://chromium-review.googlesource.com/311205
Commit-Ready: Donald Huang <donald.huang@ite.com.tw>
Tested-by: Donald Huang <donald.huang@ite.com.tw>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Donald Huang <donald.huang@ite.com.tw>
This patch completes introduction of building of proper RO and RW
images for cr50.
A few small mods were required:
- both RO and RW images have to be signed, using the same dedicated
signer, but with different keys, dev_key.pem is not needed any more.
- the RW image offset is not at the half of available flash, a chip
specific value of 16K is used instead.
The suggested new image layout is as follows:
+----------------------------------------+
| 1KB RO signature header. |
+----------------------------------------+
- -
| 15KB RO image. |
- -
+========================================+
| 1KB RW-A signature header. |
+----------------------------------------+
- -
- -
| 239K RW-A image. |
- -
- -
+========================================+
- -
| 16 KB NVRAM, shared |
- -
+========================================+
| 1KB RW-B signature header. |
+----------------------------------------+
- -
- -
| 239K RW-B image. |
- -
- -
+========================================+
BRANCH=none
BUG=chrome-os-partner:43025
TEST=The combined image (build/cr50/ec.hex) is successfully loaded and
started by the spiflash utility from the latest FPGA tarball.
Corrupting a byte in the generated image in the RW section causes
failure to verify.
Change-Id: I41a05168b0d4e9f88efa1003f261b6dd03972a24
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311422
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
With the proper RO in place, RW must be signed in the same manner, as
RO. This patch makes sure that there is room in the RW header for the
signature.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with the rest of the patches applies the RO successfully boots up
the RW.
Change-Id: I1538195e0181c23c874ddd300887cf5da8c5a867
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311421
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This code is a port of the sample loader application included in the
FPGA update. Only the pieces relevant to straight verification and
boot were ported.
The loader generates a hash, inputs to which are the image body, state
of fuses and state of flash INFO region, and the output is the value,
which will unlock the region for execution, if it is correct.
Only one image load is attempted, the image is supposed to be located
in the flash at the offset of CONFIG_RW_MEM_OFF.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with the rest of the patches applied the RO image successfully
verifies and starts up the RW image.
Change-Id: I26e1fbdaeb8b23d519c1a328526a3422231bb322
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311316
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The values are there, we just need to be able to access them from the
code to be able to calculate how much of the flash space needs to be
made accessible for the image to run.
BRANCH=none
BUG=none
TEST=used by later patches
Change-Id: I4eb59525a50177cc7cc725871c3eab2ff390667b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311319
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The signer running on the build host and the loader running on the
target must be in sync as of the structure of the signature header.
To be able to use the same definition in both programs, remove the
system includes from the .h file which needs to be shared. Rearrange
includes in image.cc to follow the coding conventions.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with the rest of the patches applied the code successfully boots,
which indicates that the signer is in fact working properly. (See
the top patch for testing details).
Change-Id: I6bc9c57ebea55ac256fcdac8338c5566f16b6371
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311420
Reviewed-by: Nagendra Modadugu <ngm@google.com>
This key is meant to be used by the RO image when verifying the RW.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with the rest of the patches in place (in particular, this key's
public counterpart used in chip/g/load/verify.c), the RW is
successfully verified by RO.
Change-Id: Iddcc21d88518e402da614d20d913aeed162b0042
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311315
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
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
