While kevin is still in development default to connecting to the CCD PHY
instead of the AP PHY. This will automatically enable CCD instead of
having to rely on things working to detect the debug accessory and
switch to the proper PHY.
We also disable the TX lines to the AP and EC, in case servo is
connected. To turn them on manually, use these console commands:
rw 0x40060040 74
rw 0x400600c8 78
pinmux
gpiocfg
BUG=chrome-os-partner:50700,chrome-os-partner:52281,http://crosbug.com/p/52322
BRANCH=none
TEST=hook up suzy q to kevin. Run 'lsusb -vd 18d1:5014' and check that a
device appears.
Change-Id: Ic2802430680adc6186982022c995ee6f452b45fd
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338680
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Trybot-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
This enables the Cr50 to accept RW firmware updates over USB.
BUG=chrome-os-partner:50707, chrome-os-partner:50712
BRANCH=none
TEST=make buildall; test on Cr50
Build and run the extra/usb_updater utility. Watch the console,
and observe that the Cr50 updates and reboots into the new image
correctly.
Note that you'll have to rebuild the ec.bin image in order for
the update to take effect. Just reflashing the same image doesn't
cause the bootloader to change its selection.
All the previously existing endpoints continue to function normally.
Change-Id: I7bd22eae803c2ceeb14a767c06d3d5c9f1ac7c7a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338089
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
This adds a standalone linux utility to deliver RW firmware
updates to the Cr50 over USB.
It prepares update blocks required by the firmware upgrader, and then
fragments and transfers the blocks though the USB channel. The blocks
are reassembled on the target and passed to the upgrade module for
integrity verification and programming.
BUG=chrome-os-partner:50712
BRANCH=none
TEST=make buildall; test on Cr50 as follows:
sudo extra/usb_updater/usb_updater build/cr50/ec.bin
The Cr50 doesn't yet accept firmware updates that way,
so there's no functionality to test just yet.
Change-Id: I1c698fd0c553c936d58ff16a2acaa05ae05bc857
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338088
This re-factors the existing firmware upgrade facility, which worked as
a TPM command extension.
The same code processing upgrade blocks prepended by the truncated
SHA1 and the load address is now used by both extended TPM command and
the USB upgrader.
To accommodate USB communications using a smaller message payloads a
reassembly layer is introduced which accumulates short USB payloads
into a single block which can be passed to the firmware upgrade
routine. USB encapsulation adds one 4 byte header at the beginning of
the block to hold the total block size. The reassembly layer keeps
receiving USB messages, concatenating their payloads until the full
block is received.
A config option is added to make sure the module is not compiled when
not needed.
BUG=chrome-os-partner:50707
BRANCH=none
TEST=make buildall; test on Cr50 - with the rest of the patches
applied it is possible to upgrade firmware using the USB utility
on the host..
Change-Id: Ib30b381c4ab196ea9d352f3c6b8f46dc23ddd599
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338087
It's handy to use the usb-stream interfaces to avoid a lot of
typing. But not all the endpoints are traditional serial ports.
This just adds a new macro that lets us specify additional
parameters.
BUG=chrome-os-partner:50707
BRANCH=none
TEST=make buildall; test on Cr50
Verified that all the previous endpoints still work as before.
There are no endpoints that use the new macro yet.
Change-Id: Ia37901cbe3adc4a4650ab91db3596efa15a110de
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338086
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This adds a command to connect or disconnect, and to switch the
PHY between A or B.
BUG=chrome-os-partner:52055
BRANCH=none
TEST=make buildall; test on Cr50
Using a test board with both PHYs plugged in, try the various
commands:
usb off
usb on
usb a
usb b
The on/off option connects and disconnects, the a/b option
switches between PHYs. You can see the state change on the
console, or by running dmesg on the host.
Change-Id: I4c77e9c586ce197dc99b0b50af7396c253a1a377
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/337706
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This change adds support for forwarding the EC console through USB.
BUG=chrome-os-partner:49960
BRANCH=none
TEST=load the google-serial udev rules in extra/usb_serial/, build the
raiden.ko module, and then check that the console can be accessed from
/dev/google/Cr50/serial/Shell
Change-Id: I35e0bb39fdc8f9485a14c03eb3a4d2f024884e17
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/334132
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
CR50 will need three serial endpoints for the streaming AP and EC UART
and exporting its own console through USB. This change adds a macro to
create endpoints that can be recognized by the usb_serial driver.
BUG=chrome-os-partner:50702
BRANCH=none
TEST=Verify "/dev/google/Cr50*/serial/Blob" prints capital letters when
lower case letters are input.
Change-Id: Iddf2c957a00dc3cd5448a6a00de2cf61ef5dd84c
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336441
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds (and uses) some additional flags for gpio.inc's
PINMUX() macro, to configure specific pads as wake sources when
the SoC is sleeping.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
The sleep/deep sleep behavior is unchanged. This just replaces
hard-coded wake sources with pads configured in gpio.inc and the
chip/g/sps.c module. Tests from previous CLs still pass.
Change-Id: I6608dc959524f42fd589feb804fa06f29cfd9b9c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336838
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
This adds support for the "sleep" low-power mode. It consumes
less power than simply waiting, but doesn't require a full warm
boot to resume.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
Configure the Cr50 to sleep when idle (refer to previous commit
messages for the setup required).
On the console, use the "idle" command to test the three
different modes:
idle w - wfi, wakes instantly
idle s - sleep, wakes slowly but without rebooting
idle d - deep sleep, wakes via warm boot
You can tell the difference between wfi and sleep by observing
that the first character is lost when typing on the serial
console while in sleep (remember that it will wait at least 10
seconds after the last console input before sleeping).
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Ib2584aa44ab885f0c8369ec938ee17b935aa0898
Reviewed-on: https://chromium-review.googlesource.com/336836
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
Wait at least 10 seconds after the last console input before
invoking sleep or deep sleep.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; test on Cr50
Use the "idle d" console command to put the Cr50 into deep sleep
when idle (refer to previous commit messages for the setup
required).
Wake it up, then let it sleep again. It should go back to sleep
quickly when woken via USB, but should take much longer when
awakened by typing on the serial console.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I7a2b840565f5d82e0dbdf8a3e75061a69cb9e405
Reviewed-on: https://chromium-review.googlesource.com/336835
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
This preserves the selected idle action (wfi, sleep, deep sleep)
across soft reboots, which includes deep sleep. Hard reboots will
restore the default which is to not sleep at all.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; test on Cr50
Use the "idle d" console command to put the Cr50 into deep sleep
when idle (refer to previous commit messages for the setup
required).
Wake it up, then let it sleep again. It should go back to the
deep sleep state.
Change-Id: Iaad82b725d2b32a19205fa403dbaab9a31c35630
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336834
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This adds the SPI slave bus and TPM task to the things that
can prevent deep sleep. Even when things are quiet, we wait at
least a second
With this CL, it will wait at least one second after the last SPS
transaction before sleeping. Since most TPM-protocol commands are
built up of a number of back-to-back SPS messages, if we don't
wait we'll keep trying to sleep in the middle of active commands.
Even if everything is quiet, we wait 0.2 seconds anyway to give
the UART buffers time to drain.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; extensive tests on Cr50
Testing is a pain.
In addition to ALL the steps listed in commit
d917d3f1867e96369ff25bf6906043a5f488a6fb, loading the firmware
with the spiflash tool leaves SPS_CS_L low, so you have to drive
it high manually. The easiest way is to build and run
test/tpm_test/tpmtest.py for a few seconds then interrupt it with
Ctrl-C.
Note that because the system wakes from deep sleep when it sees
SPS_CS_L go low but it can't get ready fast enough to capture the
incoming bits, that first SPI transaction will be garbled or
lost. You'll have to either retry it, or wake the system another
way first.
Change-Id: Iae2fe5ef33869c48e98a3afecd6b98991a51a488
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336690
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is keyboard test mechanism request for "multiple key press test",
we can thru the testing to scan out kso ksi pins shortting or keyboard has
multiple key pressing, below was the testing steps:
1. Turn off internal keyboard scan function.
2. Set all scan & sense pins to input and internal push up.
3. Set start one pin to output low.
4. check other pins status if any sense low level.
5. repeat step 3~4 for all keyboard KSO/KSI pins.
6. Turn on internal keyboard scan function.
BUG=chrome-os-partner:49235
BRANCH=ToT
TEST=manual
Short any KSO or KSI pins and excute "ectool kbfactorytest", it shows failed.
if no pins short together, it shows passed.
Change-Id: Id2c4310d45e892aebc6d2c0795db22eba5a30641
Signed-off-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/332322
Reviewed-by: Shawn N <shawnn@chromium.org>
cr50 has three UARTs that it will be using. This change modifies the
uart api to specify which uart to use.
BUG=chrome-os-partner:50702
BRANCH=none
TEST=change the interrupts and CONFIG_UART_CONSOLE to see that the
different UARTs can be used.
Change-Id: I754a69159103b48bc3f2f8ab1b9c8b86cea6bea5
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/333402
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is still in testing mode, so you have to take special steps
to enable it (keep reading). But if you do the right dance, it
does go into deep sleep for USB suspend, and resumes correctly.
However, it doesn't yet wake for any other reason. That's coming next.
Normal sleep is not yet supported, either.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; extensive tests on Cr50
Testing is a pain.
First, you can't print anything in the idle task, because that
just makes it stop being idle, so the only way to detect when
it's triggered is by wiring up a GPIO and instrumenting things.
Second, you have to manually reenable USB suspend on the host
every time the Cr50 boots with
echo auto > /sys/bus/usb/devices/<BLEH>/power/control
where <BLEH> is the correct device.
Third, for reasons probably related to the mysteries of HID
devices combined with crbug.com/431886, you have to build the
firmware without CONFIG_USB_HID (and the related items in
board.h)
Finally, because it's still a work in progress, you have to type
idle d
at the serial console after every boot (or resume) to reenable
deep sleep in the idle task.
If you do all that, then you'll see that it does go into deep
sleep. Ping it again with "lsusb -v -d 18d1:5014" or
./test/usb_test/device_configuration, and it wakes up and
responds!
If you disconnect the USB while it's in deep sleep, it stays
asleep. When you plug it in again, it wakes up, but it correctly
recognizes that it shouldn't resume and does a normal reset
instead.
Change-Id: I3cc66e48ce671142a4d12edbe0eb9fdacecea0d9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336279
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
NULL padding (aka vanilla RSA) support is required by
the TPM2 test suite (referred to as TPM_ALG_NULL in the
tpm2 source).
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2 pass
Change-Id: I9848fad3b44add05a04810ecd178fbad20ae92cc
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/328830
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Some of the reset causes are found in another register when
resuming from a low-power state. We know we'll need to
distinguish among them eventually, so we might as well decode
them now.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
I forced the system into deep sleep and observed that the reset
cause is accurately recorded on resume. Doing that requires a
fair amount of hacks and manual effort, and can't happen by
accident. Future CLs will make use of this.
The current, normal behavior is completely unaffected.
Change-Id: I5a7b19dee8bff1ff1703fbbcc84cff4e374cf872
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336314
Reviewed-by: Randall Spangler <rspangler@chromium.org>
A resume from deep sleep looks a lot like a cold boot, but there
are some registers that need updating quickly. We need to disable
the settings that triggered deep sleep so that it isn't
accidentally invoked again, and we need to unfreeze any modules
or pins that were frozen during the deep sleep.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
Since we aren't yet triggering deep sleep, this doesn't do
anything noticeable, which is the point. It shouldn't have any
effect unless we are entering deep sleep and DON'T do this when
it resumes. FWIW, I have tested that too, but it's coming in a
later CL.
Change-Id: I4b32fd2e24fe089d3f659154df26d275b41b4c1b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336450
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This just adds the framework to use for implementing sleep and
deep-sleep. This provides a custom idle task, and a new "idle"
console command to control what that task should do (nothing,
yet).
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
Other than the new idle command which does nothing, there is no
visible change. This is just a stub.
Change-Id: I8a9b82ca68dd6d1e3e7275f4f6753a23a7448f1d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336420
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds USB support to Set and Get the Device Configuration.
These control transfers are standard device requests that need to
be added in order to behave properly for USB suspend/resume (and
in general). Before this CL, the Get command always failed and
the Set command had no effect internally. With this CL it works.
Note that this particular change only supports ONE configuration
for the Cr50. If/when we add additional configuration
descriptors, we'll need to update it again.
BUG=chrome-os-partner:50721
BRANCH=none
TEST=make buildall; manual tests on Cr50
This CL includes a test program. Connect the Cr50 to the build
host, and use that program to read and change the configuration.
cd test/usb_test
make
./device_configuration
./device_configuration 0
./device_configuration 1
./device_configuration 2
You may need to use sudo if your device permissions aren't sufficient.
Change-Id: Id65e70265f0760b1b374005dfcddc88e66a933f6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/335878
Reviewed-by: Scott Collyer <scollyer@chromium.org>
When a pin power-on default is input, it is necessary to configure output
level, pull up, etc. before setting the pin to output. Otherwise, the
pin may be set to an undesired logic level for a short time.
BUG=chrome-os-partner:51722
TEST=Power-up kevin, verify that CR50_RESET_L (default input, configured
as high + open drain output by default) does not go low for a short
period at boot.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ieaa08e14e6ea15a908f3ff4ee9188e14b17583cf
Reviewed-on: https://chromium-review.googlesource.com/335344
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
- Fix incorrect use of pwm functions which take a channel number.
- Set power-down register according to PWMs that are actually enabled.
BUG=chrome-os-partner:51722
TEST=Run 'pwm 1 50` on kevin and verify that LED lights up.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: If7bcc812b55d3b72f215cf41c264d34827db7e29
Reviewed-on: https://chromium-review.googlesource.com/335372
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
We clear global NAKs by writing bits in the USB_DCTL register.
However, prior to this CL we were overwriting the entire
register, not just touching individual bits.
Since we've never actually set any global NAKs, this mistake
didn't have any noticeable effects. But we should still do the
right thing in case we need it later.
BUG=chrome-os-partner:50721
BRANCH=none
TEST=make buildall; test on Cr50
No visible change; everything continues to work.
Change-Id: Ia25d95dc6211e5460132622ac005723f43b00e24
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/335190
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We were referring to unhandled USB control messages as errors,
but they aren't necessarily. Sometimes they're optional things
that aren't fatal. We should still address them, but we don't
have to freak out.
BUG=none
BRANCH=none
TEST=make buildall; test on Cr50
Change-Id: I892acec2d89b8ec95353cdc09f3e49aa78b1704d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/335200
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There were some unnecessary shifts and conditionals. This just
makes the code a little more readable.
BUG=none
BRANCH=none
TEST=make buildall; test on Cr50 hw
Change-Id: I084f191675d1b51101e9dc55c2e5a12b0b345d33
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/334870
Reviewed-by: Scott Collyer <scollyer@chromium.org>
This config option allowed us to disable the TPM protocol on the
SPI slave bus and replace it with our EC-style host command
protocol. We only used this for early testing and don't need it
anymore, so we can get rid of it completely for this SoC.
BUG=none
BRANCH=none
TEST=make buildall; test on cr50
Change-Id: I2126537e8bcc78e583cf426a3a83962c9ff1a121
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/334762
Reviewed-by: Scott Collyer <scollyer@chromium.org>
1. Always use wake-up control interrupt for keyboard KSI. This can also
wake-up EC from deep doze / sleep mode.
2. In keyboard ISR, we just clear interrupt status to prevent keyboard
interrupt can't be re-enabled.
(for example, a KSI interrupt wakes up keyboard scan task,
but keyboard_raw_read_rows() got 0.)
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=keyboard function is normally.
Change-Id: If8c292189c6133b179a63dedcb7a18abbc091312
Reviewed-on: https://chromium-review.googlesource.com/333865
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>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
During the resume sequence of S0ix EC can receive host commands early
in the resume path when LPC is still disabled in EC. Host messages
will be lost if the LPC interface with the kernel is down.
Clock control was programed to 2 which means ring oscillator is
shut down after completion of everty LPC transaction.To restart
the oscillator EC should enable a wake interrupt on LPC LFRAME number
and this mode can cause an increase in the time to
respond to the LPC transactions.
Keeping LPC always on shows minimal power impact as per datasheet
Pg.390. The impact is < 0.45mW.
BUG=chrome-os-partner:50627
TEST=Enter into S0ix and exit reliably.
BRANCH=firmware-glados-7820.B
Change-Id: I670b9b45c3a85c9bca249312a73a25dca52b313a
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/332333
Reviewed-by: Shobhit Srivastava <shobhit.srivastava@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit c03fd6e0eaa6ecd3205214f901facb9896a798b4)
Reviewed-on: https://chromium-review.googlesource.com/332791
Since npcx5m6g has larger than 128 KB code ram for FW, the original
alignment between RO & RW regions isn't suitable for new chip.
Therefore, we add 256KB alignment of them for npcx5m6g.
In order to program the flash used by npcx5m6g, we add new board array,
BOARDS_NPCX_5M6G_JTAG, in flash_ec to distinguish which flash layout
ec used. In npcx_cmds.tcl, add new script funcs such as flash_npcx5m5g
and flash_npcx5m6g to program flash with different layout.
Modified sources:
1. config_flash_layout.h: Add 256KB alignment of RO & RW regions for
npcx5m6g.
2. util/flash_ec: Add new board array, BOARDS_NPCX_5M6G_JTAG, to
distinguish which flash layout ec used.
3. openocd/npcx_cmds.tcl: Add new script funcs to program flash with
different layout.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I0ace31d96d6df2c423b66d508d30cefb0b82ed6c
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/331903
Reviewed-by: Shawn N <shawnn@chromium.org>
Add a usb endpoint and class for i2c control via USB.
Used for servo micro and servo_v4 to export USB control
through servod.
BUG=chromium:571477
BRANCH=None
TEST=updated servod is able to control gpio extender on servo_micro
Signed-off-by: Nick Sanders <nsanders@google.com>
Change-Id: Id44096f8c9e2da917c0574d28dfcbcc0adf31950
Reviewed-on: https://chromium-review.googlesource.com/329322
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
It turns out TRNG could turn idle under certain circumstances, and
needs to be restarted in that case. This code adds a check for the
idle state and necessary recovery.
BRANCH=none
BUG=b:27646393
TEST=none yet
Change-Id: Ibd0a13f40f5ce081d4211b2c0f1026468967f826
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/332573
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
CONFIG_SHI ("SPI host interface") has identical meaning to
CONFIG_HOSTCMD_SPS ("Accept EC host commands over the SPI slave"). Use
CONFIG_HOSTCMD_SPS, since it came first and is already defined in config.h.
BUG=chrome-os-partner:50819
BRANCH=None
TEST=`make buildall -j`
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I665c405ad72caa3b84e583a80c0893e4c625632a
Reviewed-on: https://chromium-review.googlesource.com/331342
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
reverse() swaps the endian-ness of a buffer of
specified length. This change moves the implementation
to a common location.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=compilation succeeds
Change-Id: If8c97f53cc199d63c1caebbd999e1c099814387e
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/331333
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
In order to support 256 KB ram version of npcx ec, we add CHIP_VARIANT
variant to distinguish which verson ec is.
In config_chip.h, we use CHIP_VARIANT to specify the size and start address
of program memory. Ecst tool also needs a chip parameter to make sure
the address range checking of entry pointer won't fail.
Modified sources:
1. config_chip.h: Use CHIP_VARIANT to specify the different hardware spec
of npcx ec.
2. config_flash_layout.h: Replace constant value with
CONFIG_PROGRAM_MEMORY_SIZE for CONFIG_RO_SIZE.
3. build.mk: Add -chip parameter for ecst tool to check entry address.
4. npcx_evb\build.mk: Add CHIP_VARIANT definition (npcx5m5g).
5. npcx_evb_arm\build.mk: Add CHIP_VARIANT definition (npcx5m5g).
6. wheatley\build.mk: Add CHIP_VARIANT definition (npcx5m5g).
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I1b8b9b9d0a59bdc01210f498ac67e4a342743b47
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/330072
Tested-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Add 1.8V IO support for some GPIOs and I2C pins. We use a array
(gpio_lvol_table) to confine which IO pins can switch to 1.8V. Before
setting it to support low voltage level, FW should set IO pin's type to
open-drain and disable internal pulling up or down.
We also add examples in gpio.inc of npcx_evb and npcx_evb_arm to indicate
how to set GPIO & I2C pins to 1.8V if user adds CONFIG_TEST_1P8V definition
in board.h.
In i2c.c driver, this version removes the internal pull-up feature of
i2c ports since the driving force is too weak. (about 30K ohm)
Modified sources:
1. gpio.c: Add 1.8V IO support for some GPIOs and I2C pins.
2. i2c.c: Remove internal pull-ups feature for i2c pins and move 1.8V
support to gpio.c.
3. register.h: Modified NPCX_LV_GPIO_CTL register & bits definitions.
4. npcx_evb\gpio.inc: Add examples of 1.8V IO.
5. npcx_evb_arm\gpio.inc: Add examples of 1.8V IO.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I73a840ae321820212e50d609dab17576117a7d64
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/330037
Reviewed-by: Shawn N <shawnn@chromium.org>
Flash writes must have starting offsets and byte lengths that are
multiples of 4 bytes. This requirement is already covered. One
additional requirement is that a batch write not cross a flash
block boundary. Added a check in flash_physical_write() to check
if this boundary would be crossed and if so to reduce the write
size so that it ends at the block boundary.
BUG=chrome-os-partner:44745
BRANCH=none
TEST=manual
Used the TPM NVMem section and executed flash writes/reads using
a console command utility that I created to test NVMem accesses.
Note that the console output only exists in the console command
related functions.
This test has the offset 12 bytes from the block boundary and
64 bytes long. The counting pattern shows that the write fills the
last 12 bytes, then moves to the next block as expected.
> nvmem wr 0xff4 0x40 3
nvmem wr: o = ff4, s = 64|0x40
start = 0xff4, end = 0x1034
block 0: block_offset = 0x40800
Call Erase(0x80800, 0x800)
block 1: block_offset = 0x41000
Call Erase(0x81000, 0x800)
Nvmem: writing 64 bytes, start = 0x80ff4
> nvmem rd 0xfe0 0x80
nvmem rd: o = fe0, s = 128|0x80
0x80fe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x80ff0: ff ff ff ff 00 01 02 03 04 05 06 07 08 09 0a 0b
0x81000: 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b
0x81010: 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b
0x81020: 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b
0x81030: 3c 3d 3e 3f ff ff ff ff ff ff ff ff ff ff ff ff
Also tested the case where a write should end exactly at
the block boundary.
> nvmem wr 0xff0 16 3
nvmem wr: o = ff0, s = 16|0x10
start = 0xff0, end = 0x1000
block 0: block_offset = 0x40800
Call Erase(0x80800, 0x800)
Nvmem: writing 16 bytes, start = 0x80ff0
>
> nvmem rd 0xfe0 0x80
nvmem rd: o = fe0, s = 128|0x80
0x80fe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x80ff0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
0x81000: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0x81010: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
Change-Id: Icbe66d3f79d84ed29ecc6207537ea0bf42781f3c
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/330175
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This function should not be part of the public GPIO API. It is only
available and used in the STM32 implementation. This moves the
prototype to a chip specific gpio.h that is used within the STM32 chip
directoy.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Manually verify GPIO functionality on discovery board
Change-Id: If9c97f8038b26815318652ca62c1132c95519fa2
Reviewed-on: https://chromium-review.googlesource.com/329968
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously a bogus rx_count value from the USB hardware could have
caused a buffer overflow while copying from the packet ram to the DMA
bounce buffer. I'm not sure if it is possible to cause the hardware
to generate a bogus rx_count, I doubt it, but this is now nicely
paranoid
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Test SPI bridge functionality on discover board
Change-Id: I080ba1c1f05c2b0a86a4c6eb89e8c1387827466e
Reviewed-on: https://chromium-review.googlesource.com/329849
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Nick Sanders <nsanders@google.com>
Previously the keyboard row and column pins could not use the GPIO
alternate function mechanism because their DEVALT bits were inverted
with respect to all of the others, making it impossible to correctly
configure them. With the refactor of the GPIO driver we can now add
the keyboard DEVALT entries to the gpio_alt_table, and use the
ALTERNATE macro and associated APIs to control the keyboard pin states.
The Wheatley RO firmware image is still 320 bytes smaller than before
the GPIO refactor.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Ran on Wheatley, manually verified keyboard functionality
Change-Id: Id04bc010834b5d95050b03ace6b0e1c5690757bf
Reviewed-on: https://chromium-review.googlesource.com/329762
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Body 5678901234567890123456789012345678901234567890123456789012345678901
Previously the GPIO driver used quite redundant encodings for its WUI
and DEVALT mapping tables. This refactor compresses those tables
significantly, while adding the ability to represent an inverted DEVALT
bit. The resulting RO firmware image for Wheatley is 384 bytes smaller.
This commit also corrects the interpretation of the func parameter to
gpio_set_alternate_function. Any non-negative func should be
interpreted as a request to switch a pin to an alternate mode.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Ran on Wheatley, manually verified basic functionality
Change-Id: I3a56a4b56d13a70a30c388e7e2c77dd7acd3838a
Reviewed-on: https://chromium-review.googlesource.com/329761
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
This adds two debugging commands to decode the PINMUX and GPIO
routings without having to look at a bunch of hex values.
They can easily be removed to save space, but they're kind of
handy for now.
BUG=chrome-os-partner:49952
BRANCH=none
TEST=make buildall, and test on Cr50
Run the "pinmux" and "gpiocfg" commands. Verify that the output
reflects the desired configs found in gpio.inc
I get this:
> pinmux
40060000: DIOM0 5 IN GPIO0_GPIO4
40060008: DIOM1 6 IN GPIO0_GPIO5
40060010: DIOM2 0 IN PU
40060028: DIOA0 70 UART0_TX
40060030: DIOA1 0 IN
40060038: DIOA2 0 IN
40060040: DIOA3 2 IN GPIO0_GPIO1
40060050: DIOA5 0 IN
40060058: DIOA6 0 IN
40060060: DIOA7 3 IN GPIO0_GPIO2
40060088: DIOA12 0 IN
400600a0: DIOB0 33 IN
400600a8: DIOB1 34 IN
400600b0: DIOB2 0 IN
400600b8: DIOB3 74 UART1_TX
400600c0: DIOB4 0 IN PD
400600c8: DIOB5 78 UART2_TX
400600d0: DIOB6 0 IN
400600d8: DIOB7 1 IN GPIO0_GPIO0
400600f8: GPIO0_GPIO0 3 DIOB7
400600fc: GPIO0_GPIO1 22 DIOA3
40060100: GPIO0_GPIO2 18 DIOA7
40060104: GPIO0_GPIO3 20 DIOA5
40060108: GPIO0_GPIO4 30 DIOM0
4006010c: GPIO0_GPIO5 29 DIOM1
40060110: GPIO0_GPIO6 28 DIOM2
40060208: UART0_RX 24 DIOA1
40060218: UART1_RX 8 DIOB2
40060228: UART2_RX 4 DIOB6
> gpiocfg
GPIO0_GPIO0: read 0 drive 1
GPIO0_GPIO1: read 0 drive 0
GPIO0_GPIO2: read 0 drive 0
GPIO0_GPIO4: read 0 drive 0
GPIO0_GPIO5: read 0 drive 0
>
Note that we skip GPIO0_GPIO3 and GPIO0_GPIO6 because they're
neither outputs nor interrupts. All the GPIOs can do that.
Change-Id: I93b881bfd93dc100096bbd005a6c31b2669eda2f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329527
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chrome-os-partner:49952
BRANCH=none
TEST=make buildall, run on Cr50 board
It's kind of hard to test GPIOs that aren't attached to anything,
but I've examined all the PINMUX controls and ARM GPIO settings,
and I *think* they're right.
Change-Id: I66ae94118f73c41193c6ca5c0af9708f6cc8a3e8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/329526
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
