Cleanup PD receive error enum by including RX in name since
we will have a different enum for TX errors.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I355092e0e73a022acb4a92736374cd2289d324bf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267670
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sometimes the chipset task is slow enough that we might get messages from
the AP before chipset_in_state(CHIPSET_STATE_ON) is true. This causes us
to leave the spi off after our usual reset after every transaction
(see chrome-os-partner:31390). This would put an end to any EC communications.
Instead of relying on CHIPSET_STATE_ON we could just save the value of
"enabled" before we turn it off, then use that as a condition instead.
There shouldn't be a race condition on "enabled" because the only other place
it gets modified is in the hooks, which can't preempt spi_init
(which usually happens in the host command task).
The only problem is that in case of a sysjump enabled will be 0,
so CHIPSET_STATE_ON was left as a backup to handle that case.
This fixup was squashed from Ied3788f83fef548dff3b01bec93d0e40101ba0f7
TEST=Resume minnie from "echo mem>/sys/power/state" a few times, note ec still works
BUG=chrome-os-partner:39564, chrome-os-partner:39576
BRANCH=veyron
Change-Id: I7c33243faebfd74dc33451024c1d75080babee03
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267593
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With mec1322's EMI set to decode IO 0x800, it does not have any other
interfaces to support POST code via IO 0x80.
This change is to enable Port80 POST code support via polling method.
Limitation:
- POST Code 0xFF will be ignored.
- POST Code frequency is greater than 1 msec.
BUG=chrome-os-partner:39386
TEST=Verified Port80 POST code is captured in EC console.
Verified "port80 task" console command will disable/enable Port80 task.
Verified "port80 poll" will get the last Port80 POST code.
BRANCH=none
Change-Id: I27e53e84b5be1fd98464a44407dd58b93d8c798d
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/266783
Reviewed-by: Randall Spangler <rspangler@chromium.org>
i2c levels were not reporting correct value as programming the
controller to switch to Bit Bang mode was not enabled.
BUG=chrome-os-partner:39400
BRANCH=None
TEST=Wedge condition was simulated and unwedge was validated using
Oscilloscope
1. SDA was grounded, ran i2cxfer console command,
SCL line creates pulses when SDA gets wedged.
2.SCL was grounded to create cloack stretching, ran i2cxfer console
command and unwedge was confirmed.
Change-Id: Id96d8460820b7d19961ed94d1262112ebd146636
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/267137
Reviewed-by: Shawn N <shawnn@chromium.org>
This fixes a slight mistake where we were enabling the wrong
interrupt (EP1 instead of EP2).
I'm not sure that this is necessary, since we don't actually do
anything about these interrupts except clear them.
BUG=none
BRANCH=none
TEST=manual
To test, I instrumented the hid_tx() interrupt handler. Before
this CL, it never fired. Now it does.
Change-Id: Iaa5816ec78f70ef101d4663c08842678ddc7d2f9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267089
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Identify and ignore cable reset PD command
BUG=chrome-os-partner:39464
BRANCH=samus
TEST=connect two samus'. on one samus add code to send a cable
reset like such:
int send_cable_reset(int port)
{
int off;
CPRINTF("C%d Send cable reset\n", port);
/* 64-bit preamble */
off = pd_write_preamble(port);
/* Hard-Reset: 3x RST-1 + 1x RST-2 */
off = pd_write_sym(port, off, BMC(PD_RST1));
off = pd_write_sym(port, off, BMC(PD_SYNC1));
off = pd_write_sym(port, off, BMC(PD_RST1));
off = pd_write_sym(port, off, BMC(PD_SYNC3));
/* Ensure that we have a final edge */
off = pd_write_last_edge(port, off);
/* Transmit the packet */
if (pd_start_tx(port, pd[port].polarity, off) < 0) {
pd[port].send_error = -5;
return -5;
}
pd_tx_done(port, pd[port].polarity);
/* Keep RX monitoring on */
pd_rx_enable_monitoring(port);
return 0;
}
Without this CL, the receiving samus times out and ends
up causing equivalent of hard reset. With this CL, we receive
cable reset and drop it.
Also used twinkie to measure goodCRC delay. No measureable
change in delay on samus and zinger. Samus delay is ~70us and
zinger delay is ~65us.
Change-Id: Ic0e871c8cf96502b861f430e05ee145881fb55fa
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266981
Reviewed-by: Vincent Palatin <vpalatin@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>
lfw is a customized boot loader with max targeted code size of 4k
and data size of 2k.It supports minimal functionalities required to
support chromebooks RO/RW architecture.It is placed in the
write porected section with RO image .
Capabilities include SPI,DMA,UART with minimal debugging support.
Currently sysjump support is missing and exception handling is very basic.
BUG=chromium:37510
TEST=make buildall -j, flashing and booting on strago
BRANCH=None
Change-Id: I803998d489297dfe0745dcccbb54412035d73f78
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265904
Reviewed-by: Randall Spangler <rspangler@chromium.org>
mec1322 bootloader looks for a CRC TAG at the xFF00 boundary of the
flash before it loads the ec onto SRAM for execution. Code for EC will
be packed to occupy the last 256k of Flash. That way the binay generation
is independent of the flash size. The last 20000h is RO + lfw followed by
20000h space for RW.
BUG=chromium:37510
TEST=make -j buildall
BRANCH=None
Change-Id: Ie75bd8a40826d630b3022b5b3ecb2d6ad3aa2471
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265885
Reviewed-by: Shawn N <shawnn@chromium.org>
mec1322 I2C controller 0 has two attached ports. Modify the I2C driver so
that both ports are usable.
BUG=chrome-os-partner:38335,chrome-os-partner:38945
TEST=Manual on strago. Verify that i2cscan is functional.
BRANCH=None
Change-Id: I18d9d516984d041a38c86fd4ec1b0bfa4e885c9f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265951
Reviewed-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Currently, ECs with internal flash store the write protect state for
RO in a separate write/erase block of flash. This is wasteful on
chips where there are not many blocks of flash.
Add a new CONFIG_FLASH_PSTATE_IN_BANK option which is defined by
default. This is the old behavior, for compatibility. (And we're
calling it 'bank' because that's what the existing code does, even if
the terminology is somewhat etymologically... bankrupt.)
If that config is #undef'd, then store the write protect flag directly
inside the RO image. This uses only 4 bytes of the RO image, instead
of an entire erase block. The magic numbers for the pstate values are
chosen such that when protecting RO, bits are only transitioned away
from their erased state. Unprotecting RO once it's protected requires
reflashing RO; it's no longer possible to 'flashwp disable'. But
that's ok, because realistically, the only reason to unprotect RO is
if you're about to flash the RO firmware anyway.
BUG=chromium:476659
BRANCH=none
TEST=Without undefining CONFIG_FLASH_PSTATE_IN_BANK, make sure everything
still works on samus and samus_pd. This ensures we didn't break the
existing functionality:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable
flashinfo -> no flags
Then recompile with #undef CONFIG_FLASH_PSTATE_IN_BANK and test:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable -> fails with access denied
flashinfo -> ro_at_boot
Then reflash to verify that clears the ro_at_boot flag:
flashinfo -> no flags
Change-Id: Ie794b8cfed2a10c50b0e36dcf185884070b04666
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266095
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Previously for the mec1322 chip an ec.bin file was created in the normal way
and then it was "packed" in a post-processing stage to produce ec.spi.bin.
This change allows a chip or board build.mk file to specify the rules used to
produce ec.bin, and uses this for the mec1322 to do the packing. This means
that we can use the standard "ec.bin" name, and do not need to alter other
scripts, such as the script which creates chromeos-firmwareupdate.
BUG=None
TEST=buildall -j, flash on strago and see it still works.
BRANCH=NONE
Change-Id: I3f880d64e60d14f82cb1d21c8b3f2d4ae5e0dfef
Signed-off-by: Icarus Sparry <icarus.w.sparry@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265544
Tested-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Kevin K Wong <kevin.k.wong@intel.com>
Interrupt Source register is R/WC, so |= should not be used.
BUG=none
TEST=Verified LPC_RESET# is detected by interrupt handler via EC console.
BRANCH=none
Change-Id: Ib553c839e1311538b17a4d9fbc10c9df5b7e6b44
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265502
Reviewed-by: Shawn N <shawnn@chromium.org>
This allows switch status to be updated to EC MemMap.
BUG=none
TEST=Verified mmapinfo console command is reporting the correct info.
BRANCH=none
Change-Id: I3b6683be8b92b59dffb3227e0a72a122dcda56a2
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265493
Reviewed-by: Shawn N <shawnn@chromium.org>
The memcpy like routines for moving to and from usb packet
RAM couldn't deal with all unaligned uses, this fixes their
behavior. In particular, a previous caller might assume
that the packet RAM addresses were contiguous and attempt
to break up a call into two separate chunks (as the queue
insertion/removal code does). But this can lead to invalid
pointers passed to these memcpy routines. A much cleaner
solution is to make the packet RAM address space contiguous.
To do so the memcpy routines take packet RAM addresses
instead of AHB address space mapped addresses and
__usb_ram_start needed to change to be of type usb_uint so
that pointer arithmatic on it worked correctly on all platforms,
this also allowed the usb_sram_addr macro to be simplified.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that USB still works on Ryu and discovery-stm32f072
Change-Id: I479461f07a3203f1e6e0cf9705f512a5a43c4646
Reviewed-on: https://chromium-review.googlesource.com/264764
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Previously the TX and RX queues were being accessed from two
different locations without locking, which is wrong. This
moves the access to a single location in a deffered hook and
calls that hook from the old locations. The result is
correct, simpler, and not much slower. It also reduces time
in the USB interrupt handler by moving the memcpy from packet
to queue out to the deferred hook.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that USB streams still work on Ryu and discovery-stm32f072
Change-Id: I6ea53d7c40b42c6112e86a7886f3b888408f72b7
Reviewed-on: https://chromium-review.googlesource.com/264763
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
The ADC watchdog is about 2/3 of the ADC code size and it is not
optimized out when not used because adc_read_channel() needs to
stop/restart the watchdog if somebody is using it.
The feature is enabled by default to keep the current behavior on
STM32F0 platform, and it is turned off on samus_pd :
This is saving 448 bytes of flash (and 8 bytes of RAM).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall and check the firmware size before and after.
when CONFIG_ADC_WATCHDOG is disabled, adc_enable_watchdog() is not
compiled if there is any user the build will fail.
Change-Id: Ie2450bc2a8fd97662322fd3ce87e93c3fece6c6f
Reviewed-on: https://chromium-review.googlesource.com/265303
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>
When using the Twinkie dongle without a protocol decoder on the host,
add a simple text tracing mechanism, so the user can get the timestamped traces
of the packets on the wire (in a best effort fashion).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=On Twinkie command-line, type "tw trace on"
then plug a DingDong to Samus through Twinkie and
see the PD message traces on the console.
Change-Id: I4fa35d6783cc6279c95209c86f37e6d717de7301
Reviewed-on: https://chromium-review.googlesource.com/237222
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
We need to clear DMA status before starting another transaction.
Otherwise, we get incorrect values.
Same fix as the one Vic did in CL 240282 for STM32F1xx and STM32F3xx.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38902
TEST=On the twinkie USB console (without anything connected), do "tw res
rd rd" then "adc". We now always get "CC1_PD = 0 CC2_PD = 0" rather than
some fancy values for CC2_PD such as "CC2_PD = 29097".
Change-Id: I065b2f8f74ba39f805445bab96b45819322a7da3
Reviewed-on: https://chromium-review.googlesource.com/264981
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
In the gpio_info struct, we had a irq_handler pointer defined even
though a majority of the GPIOs did not have irq handlers associated. By
removing the irq_handler pointer out of the struct, we can save some
space with some targets saving more than others. (For example, ~260
bytes for samus_pd).
This change also brings about a new define:
GPIO_INT(name, port, pin, flags, signal)
And the existing GPIO macro has had the signal parameter removed since
they were just NULL.
GPIO(name, port, pin, flags)
In each of the gpio.inc files, all the GPIOs with irq handlers must be
defined at the top of the file. This is because their enum values from
gpio_signal are used as the index to the gpio_irq_handlers table.
BUG=chromium:471331
BRANCH=none
TEST=Flashed ec to samus and samus_pd, verified lightbar tap, lid, power
button, keyboard, charging, all still working.
TEST=Moved a GPIO_INT declaration after a GPIO declaration and watched the build
fail.
TEST=make -j BOARD=peppy tests
TEST=make -j BOARD=auron tests
TEST=make -j BOARD=link tests
Change-Id: Id6e261b0a3cd63223ca92f2e96a80c95e85cdefb
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/263973
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Trybot-Ready: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This turns on hardware controlled update of bit 5 (AUXOBF) in Keyboard
Status Read Register. Previously, this bit was in user-defined mode and
not reliable.
BUG=None
TEST=Tested that keyboard becomes functional on Braswell Ref Design.
BRANCH=None
Change-Id: I192383ebebb25a027d58da9fc1ef7f3bb3e8da66
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/263948
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Kevin K Wong <kevin.k.wong@intel.com>
MEC1322 KSO00~03 pin has an alternate JTAG function. For board that needs JTAG
function, this #define allows hardware to use a different set of KSO pins.
For example - Uses KSO04~16 instead of KSO00~KSO12.
BUG=none
TEST=Verified keyboard is functional with all keys detected
BRANCH=none
Change-Id: I1e3c1c2b6a4420cb6296b6bc921affa8c0ed5800
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/264610
Reviewed-by: Shawn N <shawnn@chromium.org>
- Changed TX BIST mode so that it transmits for 50 msec instead
of transmitting forever.
- Added console command to initiate TX BIST mode.
- Fixed an issue with circular DMA mode which was causing watchdog.
- Modified RX BIST to account for shorter TX BIST duration.
BUG=chrome-os-partner:36335
TEST=Manual on Samus to Samus, manual on Zinger to Samus
BRANCH=Samus
Signed-off-by: Scott Collyer <scollyer@chromium.org>
Change-Id: I666347de47c81b5b7a1e82c2b99345ff3ebbb7d4
Reviewed-on: https://chromium-review.googlesource.com/256194
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Trybot-Ready: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Add a USB device driver for the Synopsys DWC USB device controller.
The common USB protocol stack code still need to be de-duplicated with
the STM32 implementation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:33919
TEST=plug Cr50 to a Linux workstation and see USB descriptors using
"lsusb -v -d 18d1:5014"
Change-Id: I4a367241053de2c2d94aa06f82ea4bee51f9f89a
Reviewed-on: https://chromium-review.googlesource.com/231160
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
I2C Block reads were split into two i2c_xfer() calls. However, i2c_xfer() implementation for MEC
does not maintain state in between calls. This was causing block read failures because the
settings for the Control Register got corrupted. Fix this by calling i2c_xfer() only once. This
retrieves both string size and string. Only return the string back to the user.
BUG=None
TEST=Tested on Braswell Ref Design
BRANCH=None
Change-Id: Ife8fcb66425c6198d0dcf10f74e89c001ccac49a
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/260627
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Some platforms are unable to access the 900h-9ffh region over LPC and
must instead access memmap data through the ACPI CMD / DATA ports. To
avoid racing with data updates, disallow changes to multi-byte memmap
data while in burst mode.
Linux currently enables burst mode when accessing multi-byte data and
disables it immediately afterward, though the ACPI spec defines burst mode
in a more general way.
BUG=chrome-os-partner:38224
TEST=Manual on Samus. Undefine LPC_MEMMAP and modify asl to move memmap
data to ERAM at offset 0x20. Verify system boots cleanly and battery
status is updated immediately on plug / unplug.
BRANCH=None
Change-Id: Ib848bdb491fdfece96ad0cee7a44ba85b4a1a50b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262072
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This required changing the USB-SPI implementation slightly
so that all work is done within the deferred callback. In
particular, this allows the board specific enable and disable
functions to do things that can only be done from a task
context, like sleeping.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I3f6a01ed9d6f31a3259ba0a0f6b4e123d6d2e718
Reviewed-on: https://chromium-review.googlesource.com/260964
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
On hard reset / hibernate, RAM will be erased and panic data will
normally be lost. When software panic data saving is enabled, try to
save this data just before hard reset and restore it when we come back
up.
BUG=chrome-os-partner:37380
TEST=Manual on Samus with WP + SW sync enabled. Boot AP, then run "crash
divzero" on console. After hard reset, verify that "panicinfo" dumps
data and shows divzero exception code.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9516dd4b6db12ef35e512cc4710f9b97d7e663cb
Reviewed-on: https://chromium-review.googlesource.com/255912
Reviewed-by: Randall Spangler <rspangler@chromium.org>
mec1322 projects are running very low on flash space. We don't yet have
a loader to load either RO or RW at runtime, so remove the RO image
entirely. This is a temporary change and should be reverted once we have
a working loader.
BUG=chrome-os-partner:37510
TEST=make buildall -j
BRANCH=None
Change-Id: I8c502ec2bcabf246d5a3ea939f1a8d0c366acd9f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256381
Reviewed-by: Vic Yang <victoryang@chromium.org>
Previously the USB Stream buffer sizes were fixed at
USB_MAX_PACKET_SIZE (currently 64 bytes). But that
ended up using up too much packet RAM, a very limited
resource. This change makes them configurable and
adds asserts to insure that the sizes are valid for
the underlying hardware.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that USART forwarding on discovery works
Change-Id: Ib19c0dcfa9b16f23c1d72a5a7fc18026ab103f05
Reviewed-on: https://chromium-review.googlesource.com/255232
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Previously the USART and USB Stream drivers exposed in_stream
and out_stream interfaces, which don't allow for sharing their
queues easily. This change converts these drivers over to the
producer/consumer model and updates the two uses.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that the discovery echo functionality is unchanged.
Change-Id: I29f043ab1712373f638e1621378df98647d736cf
Reviewed-on: https://chromium-review.googlesource.com/252820
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Reads to RTC_SSR may be invalid if they occur close to the RTCCLK edge.
As suggested by the datasheet, perform consecutive identical reads to
ensure the read is valid.
BUG=chrome-os-partner:37216
TEST=Manual on Samus. Repeatedly call rtc_read in test function, verify
that RTC_SSR never incorrectly ticks up.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib26fbfab4a07263f638c580066e993675dd8c451
Reviewed-on: https://chromium-review.googlesource.com/254725
Reviewed-by: Alec Berg <alecaberg@chromium.org>
All current boards in ToT place pstate at the end of the RO section.
Remove the unused option to place it at the end of the RW section;
we'll never do that again.
BUG=none
BRANCH=none
TEST=make buildall -j
Change-Id: I0d279a4c9786bb33367a7387423481cc9b94e115
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253636
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The npcx chip and evb use a SPI flash chip to hold the EC image. They
don't need pstate, and should use the SPI flash status register
directly.
1. Remove CONFIG_FLASH_PSTATE from npcx_evb.
2. Remap WP_L GPIO to GPIO 93 (this should be the same as the write protect
line to the SPI flash chip).
3. Change the npcx flash driver so that it directly reads/writes the SPI
status register instead of mucking with pstate.
BUG=chrome-os-partner:34346
BRANCH=none
TEST=manual
Add a switch or jumper to the EVB so R1 can be closed.
Toggle the switch and see that WP_L state changes. Leave enabled.
flashinfo -> nothing is protected, WP_L is enabled (=0)
(also do this after each flashwp command to check the protection status)
flashwp enable -> RO is protected now and at boot.
reboot
flashwp enable -> RO is still protected.
flashwp disable -> RO is still protected. (because WP switch is enabled).
Toggle the switch so WP_L is disabled (=1)
flashwp disable -> Succeeds, flash is not protected
Change-Id: Ifa959bce69f8eb4724057ecaa6a6c5075783c19d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253633
Reviewed-by: Shawn N <shawnn@chromium.org>
This signs the RW firmware (with a non-secret key). The RO
firmware will verify the RW firmware and jump to it if it's good.
Note that this isn't the final solution, just the beginning.
BUG=chrome-os-partner:37071
BRANCH=none
TEST=manual
Build and install it. You'll see something like this:
--- UART initialized after reboot ---
[Reset cause: reset-pin hard]
[Image: RO, cr50_v1.1.2929-27e1b82-dirty 2015-02-24 14:36:29 wfrichar@wfrichar-glaptop]
[0.000444 Verifying RW image...]
[0.423742 RW image verified]
[0.423946 Jumping to image RW[0.428492 UART initialized after sysjump]
[Image: RW, cr50_v1.1.2929-27e1b82-dirty 2015-02-24 14:36:29 wfrichar@wfrichar-glaptop]
[0.428931 Inits done]
Console is enabled; type HELP for help.
>
> sysinfo
Reset flags: 0x00000c02 (reset-pin sysjump hard)
Copy: RW
Jumped: yes
Flags: unlocked
>
Change-Id: Icafa554baca135ff1f80cbce4dad5f980e7fc122
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253081
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Refactoring effort to unify the set of PD intialization tasks that
need to occur. Those areas include:
1. host mode as it relates to power & pull-ups/downs
2. PD tx init
3. PD mux settings
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:36481
TEST=manual,
1. compiles and functions on samus_pd
2. If sysjump w/ dongle connected than alternate mode re-entered
properly including muxing and HPD
Change-Id: I47f32acaeccbd7745e1e01a8b085b1804c4c5000
Reviewed-on: https://chromium-review.googlesource.com/249273
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
