summaryrefslogtreecommitdiff
path: root/chip/g
Commit message (Collapse)AuthorAgeFilesLines
...
* g: add ITE EC flash programming capabilityVadim Bendebury2018-11-053-0/+285
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a callback function which triggers generation of the ITE EC programming sequence by the H1. It is going to be the board's code responsibility to configure ITE SYNC mode at startup and then reset the H1. The expectation is that when booting after reset the ITE SYNC sequence would be generated before clock jitter is configured and locked. ITE SYNC is a mode when soon after EC reset for duration of at least 20 ms the I2C master generates 200 KHz clock of the SDA line and 100 KHz clock on the SCL line, locked in phase, with 10% frequency variation tolerance. To be able to generate a stable 200 KHz clock jitter has to be disabled, and the actual clock generation function needs to be written in assembler, as this allows for the most accurate clock frequency tuning. The H1 GPIO controller allows to set multiple GPIO pins to requested values in one 32 bit transaction. The C function maps I2C interface directly to the GPIOs, prepares the address of the register to use to control the GPIOs and the values to write to generate all four combinations of the two signals: 00, 01, 10, 11. Then it invokes the assembler function to actually generate the clocks, and then re-enables the clock jitter. BRANCH=cr50, cr50-mp BUG=b:75976718 TEST=with the rest of the patches applied verified that it is possible to disable and re-enable clock jitter at run time. Change-Id: Iac33c9bab68fc1ab919d960291176195a08f1791 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1263901 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* g: provide API to disable clock jitterVadim Bendebury2018-11-052-32/+61
| | | | | | | | | | | | | | | | | | | | | | | Sometimes it is necessary to disable clock jitter, this patch introduces a new chip API which would allow to do just that. Actual disable is possible only if the chip is not yet running on lowered security level. BRANCH=cr50, cr50-mp BUG=b:75976718 TEST=with the rest of the patches applied verified that it is possible to disable clock jitter during startup to be able to generate ITE SYNC sequence. Also observed expected console output, like: [0.007225 init_jittery_clock_locking_optional: run level high, \ request to enable] Change-Id: I624d781a961cdc17749de4fa80fad0f682537e01 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1305117 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* g: allow i2cm transactions of arbitrary lengthVadim Bendebury2018-10-161-131/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Programming ITE EC over CCD is a very tedious process, with a huge overhead imposed by encapsulating I2C traffic in USB packets. On top of that actual writing into the flash must happen in a single transaction passing a full flash page (256 bytes) worth of data. To accommodate this the I2C master driver needs to be modified to send I2C transactions longer than the I2C controller's FIFO capacity of 64 bytes. This patch makes necessary changes and simplifies the driver, even if making it a little less efficient: the modified driver does not use the FW block of the controller, which allowed to program up to for bytes to transmit before actually getting to transmit from or receive to the FIFO. All transfers now involve FIFO and there is always a full stop/start between a write and the following read, as opposed to a single restart issued before in case the write was 4 bytes or less. BRANCH=cr50, cr50-mp BUG=b:75976718 TEST=with the rest of the patches applied verified that it is possible to disable and re-enable clock jitter at run time. Change-Id: I589ac33faa33764458d9aee03e74af81be637908 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1263900
* chip/g: Convert usb_endpoints to C so gcc's LTO knows about itPatrick Georgi2018-10-162-107/+158
| | | | | | | | | | | | | | | | | | | | | | If we keep it assembly-only, the link time optimizer gets confused and eliminates seemingly unused functions, to then replace references to them with the "no handler" defaults in a later step. Similar approach as with vecttable: Implement the table in C so LTO knows the entire story. BUG=b:65441143 BRANCH=none TEST=usb_ep_{rx,tx,reset} and usb_iface_request look more reasonable in disassembly on cr50. Change-Id: I72103af742164c29aac38e9929d1a83d8c154b53 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://chromium-review.googlesource.com/1177711 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* cr50: Only allow SN hash to be written if board ID is not set.Louis Collard2018-10-121-1/+14
| | | | | | | | | | | | | | | This should restrict SN hash such that is can only be written at factory (before board id), with the exception of some edge cases where devices that have left factory do not have a board id set. BUG=b:111195266 TEST=tested locally on soraka BRANCH=none Change-Id: I2ae39e2db4b1a01ec5ec9855634357434f01020b Signed-off-by: Louis Collard <louiscollard@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1237696 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* g: update test RO to allow self-signed RWs.Marius Schilder2018-10-043-55/+18
| | | | | | | | | | | | | | | | | Instead of hard-coded embedded public keys, use public key from header. Also accommodate padding checks for both 3071 and 2048 signatures. BUG=none BRANCH=none TEST="make board=cr50;vhaven build/cr50/ec.hex --sku 2 --debug_rom" now successfully boots to console. Signed-off-by: mschilder@google.com Change-Id: I493d4832d4b78c734949fe980ef5c9de2d3e4fa1 Reviewed-on: https://chromium-review.googlesource.com/1256058 Commit-Ready: Marius Schilder <mschilder@chromium.org> Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* g: fix i2cm NACK processingVadim Bendebury2018-09-201-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When g i2c master controller encounters a NACK it seems to stop processing instruction set included in the INST register and leaves SCL low holding up the bus. Issuing an explicit STOP request in this situation makes sure that the controller completes the NACKed access cycle. BRANCH=cr50, cr50-mp BUG=b:112283593, b:113906660 TEST=verified that when running i2cscan the NACKed cycles complete properly, and the command could be ram multiple times. On dragonegg: > i2csc Scanning 0 master................................................. 0x60................ 0x80. 0x82. 0x84. 0x86............. 0xa0............................................... > i2csc Scanning 0 master................................................. 0x60................ 0x80. 0x82. 0x84. 0x86............. 0xa0............................................... > Change-Id: I7ffff5f32c9f57eb2672318fc8ebd9f74441445d Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1200078 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* host: Add dcrypto definitions that can be used by fuzzing targets.Allen Webb2018-09-072-0/+5
| | | | | | | | | | | | | | | | These definitions provide the necessary dcrypto functionality for fuzzing pinweaver. They can be built out as needed to support further fuzzing. BRANCH=none BUG=chromium:876582 TEST=make -j buildfuzztests && ./build/host/cr50_fuzz/cr50_fuzz.exe (with the cr50_fuzz CL) Change-Id: I36ce874efab5dbc59825d126f6079b7b6d0da9ef Signed-off-by: Allen Webb <allenwebb@google.com> Reviewed-on: https://chromium-review.googlesource.com/1180573 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: Add commands to get/set serial number bits.Louis Collard2018-09-057-27/+377
| | | | | | | | | | | | | | | | | | | | | Allocates 16 bytes of INFO1 space, in the 'board' section, and after the current Board ID data, to store the serial number data for use by zero-touch enrollment. Adds a console command to read / set this data. Adds TPM vendor commands to set initial sn data, and update it during RMA. CQ-DEPEND=CL:*657450 BUG=b:111195266 TEST=tested locally on soraka BRANCH=none Change-Id: I752aefad9654742b7719156202f29d635d2306df Signed-off-by: Louis Collard <louiscollard@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1127574 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* cr50: fix sps driver sync problemsVadim Bendebury2018-09-043-90/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TPM SPI hardware flow control mechanism allows the slave to stall the master until slave is ready to receive more data or has prepared data to return to the master. While stalling, the slave keeps sending zeros in the LSB of the bytes on the MISO line until it is ready to proceed. As implemented before this patch this presents a challenge when processing write transactions: by looking at the SPI frame header the Cr50 detects that master intends to write, removes the stall bit, and then tries to determine how many bytes are already there in the receive buffer (those extra bytes were sent while Cr50 was stalling the master), so that it can discard the extra bytes and know exactly where in the buffer the actual data will start once stalling condition is removed. To make this determination the code is looking at the controller's RX FIFO write pointer. It turns out that this pointer change is happening slower with slower SPI bus clocking, and this causes occasional errors in detecting the boundary in the receive buffer at slower SPI clock rates. Come to think of it, all this complexity is unnecessary in the first place: the master will finish transmitting of the write transaction after stall is removed and all required data bytes have been transferred and then remove the CS. At this point the Cr50 can look at the received data, which would consist of a 4 byte header, variable number of bytes sent while stalling was active, and then the rest of the SPI frame. The number of data bytes in the SPI frame is in fact included in the 4 byte header. So, all there is to do is to pass upstack these tail bytes of the received frame (the register address these bytes are written into is derived from the SPI frame header). This patch implements the new scheme and cleans up the low level driver, namely removes a now unused accessor function and ediits a few comments. BRANCH=cr50, cr50-mp BUG=b:113082214 TEST=modified Cr50 code to add a 32 bit scratch register the master could write and read. Modified Scarlet AP firmware to keep writing ever incrementing value to this register and read it back. Before this fix when clocking at 300 KHz this would fail after second or third write attempt, with the fix there is no problems for thousands of transactions on both 300 KHz and 1.5 MHz clocks. Change-Id: I845d2d18dc054e2a0ca2c8afd9f62bec37ad6ad9 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1194621 Tested-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org>
* cr50: Release EC Reset on power button release when SuzyQ detected.Nick Sanders2018-08-291-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It complements crrev.com/c/1137434 in the way EC Reset got released. Instead of time-basis, it shall be released when the power button is released. The desired sequence of actions is: 0. (optional) Have a CR50 console and EC console connected to terminals. 1. Do a shutdown. 2. Press the power button and keep it pressed. 3. Plug a SuzyQ cable. 4. CR50 console shall be connected back, but not EC console. 5. Release the power button at any proper time, so that EC can restart. To keep EC from resetting, do "ecrst true" in CR50 console right after Step 4. It will invalidate Step 5. BRANCH=cr50 BUG=b:37351386 TEST=manually on Duts, Bob (Chrombook) and Sion (chromebox). (A) hard-reset A-1. Binary Download + Hold power button => no delay in EC reset. (B) Wake from hibernation B-1. (EC console) hibernate B-2. unplug all cables B-3. hold "POWER BUTTON" + plug SuzyQ cable => no delay in EC reset. (C) Power-on reset C-1. "REFRESH" + "POWER BUTTON" + unplug power cable. C-2. unplug SuzyQ cable C-3. plug SuzyQ cable => no delay in EC reset. (D) Power-on reset D-1. "REFRESH" + "POWER BUTTON" + unplug power cable. D-2. unplug SuzyQ cable D-3. hold "POWER BUTTON" + plug SuzyQ cable. => EC reset gets held. D-4. release "POWER BUTTON" ==> EC gets reset. (E) Power-on reset + explicit "ec_rst true" E-1. "REFRESH" + "POWER BUTTON" + unplug power cable. E-2. unplug SuzyQ cable E-3. hold "POWER BUTTON" + plug SuzyQ cable. => EC reset gets held. E-4. (CR50 console) ecrst true E-5. release "POWER BUTTON" ==> EC reset still gets held. (F) Power-on reset + explicit "ec_rst false" F-1. "REFRESH" + "POWER BUTTON" + unplug power cable. F-2. unplug SuzyQ cable F-3. hold "POWER BUTTON" + plug SuzyQ cable. => EC reset gets held. F-4. (CR50 console) ecrst false => EC gets reset. F-5. release "POWER BUTTON" ==> Nothing happens. (common) Press "POWER BUTTON" again, and check CR50 doesn't have any more "POWER BUTTON" release events. Changes to be committed: modified: board/cr50/board.c modified: board/cr50/board.h modified: board/cr50/power_button.c modified: chip/g/rbox.c Change-Id: Ic39c9ce7849fa3187e1d277320adf671f857d18d Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1192691 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* rdd: use rdd_interrupt for rdd_connect/disconnectMary Ruthven2018-08-292-46/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Occasionally cc1 and cc2 might be in a valid debug range for a short time even if a debug accesssory isn't connected. The rdd hardware will debounce the signals long enough to make sure they're stable before triggering the Rdd interrupt. This change moves all rdd connect/disconnect logic to the interrupt instead of sampling the voltages in detect_rdd. In detect_rdd the samples of the cc lines falsely triggered rdd connect whenever the cc voltages happened to be in the valid debug range. We weren't waiting for Rdd to declare the voltage stable before running rdd connect. Moving the logic from rdd_detect to rdd_interrupt will ensure the signals are actually stable before we change the rdd state. BUG=b:113064204 BRANCH=cr50 TEST=manual connect suzyq reboot cr50 verify rdd is connected disconnect suzyq verify rdd is disconnected boot nami leave it up for a while make sure there aren't any false connects reconnect suzyq verify rdd is connected disconnect suzyq verify rdd is disconnected reboot cr50 verify rdd is disconnected run firmware_Cr50CCDServoCap and firmware_Cr50DeviceState Change-Id: I3eeaa39f79d2ccc3e997da291d8aae1f12103dc8 Signed-off-by: Mary Ruthven <mruthven@google.com> Reviewed-on: https://chromium-review.googlesource.com/1185967 Tested-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Mary Ruthven <mruthven@chromium.org>
* cr50: only enable rbox wakeup during sleepMary Ruthven2018-08-233-2/+33
| | | | | | | | | | | | | | | | | | | | | | | Enable rbox wakeups before entering any form of sleep. Disable them immediately on resume. Without rbox wakeups enabled during normal operation, we don't need to worry about clearing them after every rbox interrupt. In TOT we missed clearing the power button rbox wakeup. This was causing cr50 to wake up immediately after entering regular sleep. It caused a ton of pmu interrupts and prevented cr50 from staying asleep. With this change cr50 enters enters sleep and deep sleep normally. It only resumes when there's a real wakeup. BUG=none BRANCH=cr50 TEST=verify power button can still wake cr50 from sleep and deep sleep. Run firmware_Cr50DeviceState with TOT Change-Id: I56bf81c19a6e32750dc9d21be7f27188635dd662 Signed-off-by: Mary Ruthven <mruthven@google.com> Reviewed-on: https://chromium-review.googlesource.com/1180572 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: minor code style touch-up on a bitbang code.Namyoon Woo2018-08-172-55/+42
| | | | | | | | | | | | | | | | | | | | | | | | | Fix 1. removed unnecessary semicolons. Fix 2. enumerated parity types for code readibility. Fix 3. ensured the bool value is passed to gpio_set_level() as val. Fix 4. converted uart_bitbang_config() to static. Fix 2 and 3 save 56 bytes, and Fix 4 saves 72 bytes in flash. BUG=b:65253310 BRANCH=cr50 TEST=manually performed flash_ec, and checked version info at EC console. (chroot)$ ./util/flash_ec --board=scarlet --bitbang_rate 57600 --image=build/scarlet/ec.bin Changes to be committed: modified: chip/g/uart_bitbang.c modified: chip/g/uart_bitbang.h Signed-off-by: Namyoon Woo <namyoon@chromium.org> Change-Id: I6cea649b908e269d32e547987121621911301a72 Reviewed-on: https://chromium-review.googlesource.com/1179238 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: speed up bit bang EC programmingVadim Bendebury2018-08-164-264/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original bit bang programming implementation attempted to provide a fully functional alternative UART interface for the case when EC programming is required, so that proper UART parity can be ensured. Come to think of it, this is not really necessary: - EC programming over UART does not require full duplex. - when EC is being programmed, the AP is held in reset, there is no need to support AP console or TPM at that time, as a result interrupts could be disabled for somewhat longer intervals. This patch introduces the following modifications: - remove uartn interface redirections - when bitbang mode is enabled regular EC console is not available. - instead of waiting for fixed amount of cycles on every bit, wait for the deadline calculated when character transmission started on tx side or when the original start bit was detected on rx side and recalculated after each clock. - when finishing receiving a character do not exit ISR right away, spin for a duration of a character polling the rx line, in case the EC keeps transmitting. The rx buffer is allocated on the ISR stack and is limited to 20 bytes, which would probably cause an overrun if this interface were used for reading flash contents from the EC. - connect USB EC console flow directly to the bit bang driver when bit bang mode is enabled and disable interrupts from the EC UART. - do not use the GPIO wrappers for bit bang interrupt processing - it takes too long. - when starting a bit bang session set the clock timer value to zero, this allows not to worry about wraparound, which will happen in almost 3 minutes, programming session should not take this long. - for the duration of 'bit bang enabled' state servo detection interrupt is disabled, it gets re-enabled after bit bang mode is disabled and servo_detect() gets to run on 1s hook. - it is not enough to check the DIOB5 pinmux state to tell if EC UART is connected or not, as this pin could be connected in bit bang mode as well; always report EC TX UART as disconnected when bit bang mode is enabled. - for the duration of bit bang programming session suppress 'aggregate' GPIO interrupts, triggered per port when GPIO interrupt is asserted. Additional speed up could be achieved if gpio driver wrappers were replaced with direct register accesses, but even as presented this patch allows to reliably program the STM32 on Scarlet at 57600 baud, which is 6 times faster than the current state. BRANCH=cr50, cr50-mp BUG=b:62539385 TEST=with some flash_ec modifications which make sure that bit bang mode is enabled properly (fixing timing of setting boot0 and resetting the EC), Scarlet device EC can be reprogrammed at 57600 baud 100 times in a row with and without logic analyzer connected to the EC UART pins. Change-Id: I2e3520f158943323cb015fa18650a7e177f03cc3 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1171221 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: bitbang does not need to support multiple UARTs.Vadim Bendebury2018-08-153-85/+50
| | | | | | | | | | | | | | | | | | | | | | | | The ability to support multiple UART interfaces complicates bit bang EC programming implementation without bringing any real benefits - we are not going to have to bit bang more than one UART interface in real Chrome OS hardware. In preparation in introducing bit a bang speed up patch let's change the API to not require passing the UART number to bit bang functions. To keep servod happy for now, the 'bitbang' cli command is being left unchanged and as such still requires to pass the UART number, it is just ignored. BRANCH=cr50, cr50-mp BUG=b:62539385 TEST=just verified that Cr50 still builds, the real test is done in the speed up patch. Change-Id: Icd5476ad777791ca483844cbf49316ddf58f03a3 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1171220 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* cr50: delay EC boot when Rdd detects SuzyQ at boot time.Namyoon Woo2018-08-073-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EC_RST_L deassertion shall be delayed two seconds if two conditions below are satisfied. 1. Power button is pressed. 2. RDD detectes a debug cable. This is to gain some time to issue a command to prevent a broken EC from booting. BUG=b:37351386 BRANCH=cr50 TEST=manually on dut with DELAY_EC_BOOT_USEC defined as 30 sec. (1) hard-reset Binary Download + Hold power button => no delay. (2) Wake from hibernation - (ec) hibernate - unplug all cables - Hold power button + plug SuzyQ cable => no delay. (3) Power-on Reset - (ec) cutoff - unplug all cables - Hold power button + plug SuzyQ cable => delay! (4) Power-on Reset, no delay - (ec) cutoff - unplug all cables - plug SuzyQ cable => no delay. Change-Id: I29a1a97c053cdb898ac6ac8dc2409d5d164552d9 Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1137434 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* g: speed up CCD UART processingVadim Bendebury2018-07-272-26/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AP and EC consoles may generate a lot of bursty traffic, and cr50 UART console to USB processing is very slow: when characters become available, a hooks task callback is invoked, which retrieves received characters one at a time and queues them up to the appropriate USB transmit queue. This patch speeds up things as follows: - increases the seize of USB transmit queues for AP and EC console channels to 512 bytes. Experiments supported by code instrumentation has shown that even this is not enough to avoid underruns, but this is a good compromise between memory use and performance, these sizes could be revisited later, - moving bytes from UART TX FIFO to USB queue happens on the interrupt context when UART TX interrupt is asserted - as many characters as possible are read from the UART first, before queuing function is called, and the entire received batch is passed to the queuing function. It has to be mentioned here that presently batch processing is not necessarily much more efficient, because queuing function becomes more complicated when multiple objects are passed to it, this will have to be dealt with in a separate patch. There is still a lot of room for improvement: - functions used to queue up data are very generic, dedicated code could help a lot. - UART drivers should have methods for collecting all bytes available in receive FIFO in one invocation, - USB side of things (dequeuing data and passing it to the controller). BRANCH=cr50, cr50mp BUG=b:38448364, b:111701874 TEST=ran 'chargen' application on both AP and EC to flood the console channels and observed the flow of characters on the host site, it is pretty smooth with occasional hiccups, especially when TPM is active, before this patch it was impossible to have both stream up, both were garbled. - Verified that new account can be created and user logged in on restarts while chargen is running, i.e. TPM task gets enough processing bandwidth. - When EC is reset, there seem to be no lost characters on the console (it used to cause some garbled console output before this patch). The below output was collected on Coral: > reboot Rebooting! --- UART initialized after reboot --- [Reset cause: soft] [Image: RO, coral_v1.1.8363+2cc945d5a 2018-05-15 17:41:57 ... [0.003605 init buttons] [0.003826 Inits done] [0.004094 tablet mode disabled ] [0.008272 found batt:SMP] [0.022278 SW 0x01] [0.042247 hash start 0x00040000 0x00021994] [0.045823 Battery FET: reg 0x0018 mask 0x0018 disc 0x0000] [0.071136 kblight registered] [0.071544 PB init-on] [0.071818 USB charge p0 m0] [0.073670 ID/SKU ADC 4 = 1309 mV] [0.075630 ID/SKU ADC 3 = 852 mV] [0.076077 SKU ID: 71] [0.076335 Motion Sensor Count = 3] [0.083594 PD comm enabled] ... - did not test bitbang programming mode, it is in line for reworking for speeding up as well. - 15 iterations invocation of firmware_Cr50DevMode passes successfully on BoB Change-Id: I5883012896e78951908db8fe7c1c5d92ea6cda63 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1148655 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* cr50: wait for RBOX_WAKEUP_INTR to be clearedMary Ruthven2018-07-251-5/+0
| | | | | | | | | | | | | | | | | Wait for the interrupt status register to be cleared before clearing the RBOX_WAKEUP_CLEAR bit. BUG=b:111801707 BRANCH=cr50 TEST=shutdown the AP. Make sure cr50 doesn't wake up immediately after entering deep sleep. Make sure RBOX wakeups still work. Change-Id: I8f02e387f212a5071d9bad0bf977ab09fd053756 Signed-off-by: Mary Ruthven <mruthven@google.com> Reviewed-on: https://chromium-review.googlesource.com/1149320 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Revert "g: speed up CCD UART processing"Mary Ruthven2018-07-212-32/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 32b1e3add72159df481ea5e3d86b581ef07caaa3. Reason for revert: this causes the device to boot into recovery when running firmware_Cr50DevMode BUG=b:111701874 BRANCH=cr50 TEST=run firmware_Cr50DevMode --args="iterations=10" Original change's description: > g: speed up CCD UART processing > > AP and EC consoles may generate a lot of bursty traffic, and cr50 UART > console to USB processing is very slow: when characters become > available, a hooks task callback is invoked, which retrieves received > characters one at a time and queues them up to the appropriate USB > transmit queue. > > This patch speeds up things as follows: > > - increases the seize of USB transmit queues for AP and EC console > channels to 512 bytes. Experiments supported by code > instrumentation has shown that even this is not enough to avoid > underruns, but this is a good compromise between memory use and > performance, these sizes could be revisited later, > > - raises UART RX interrupt priority from level 1 to 0 > > - moving bytes from UART TX FIFO to USB queue happens on the > interrupt context when UART TX interrupt is asserted > > - as many characters as possible are read from the UART first, > before queuing function is called, and the entire received batch > is passed to the queuing function. > > It has to be mentioned here that presently batch processing is not > necessarily much more efficient, because queuing function becomes > more complicated when multiple objects are passed to it, this will > have to be dealt with in a separate patch. > > There is still a lot of room for improvement: > > - functions used to queue up data are very generic, dedicated code > could help a lot. > > - UART drivers should have methods for collecting all bytes > available in receive FIFO in one invocation, > > - USB side of things (dequeuing data and passing it to the > controller. > > BRANCH=cr50, cr50mp > BUG=b:38448364 > > TEST=ran 'chargen' application on both AP and EC to flood the console > channels and observed the flow of characters on the host site, it > is pretty smooth with occasional hiccups, especially when TPM is > active, before this patch it was impossible to have both stream > up, both were garbled. > > - Verified that new account can be created and user logged in on > restarts while chargen is running, i.e. TPM task gets enough > processing bandwidth. > > - When EC is reset, there seem to be no lost characters on the > console (it used to cause some garbled console output before this > patch). The below output was collected on Coral: > > > reboot > Rebooting! > > --- UART initialized after reboot --- > [Reset cause: soft] > [Image: RO, coral_v1.1.8363+2cc945d5a 2018-05-15 17:41:57 ... > [0.003605 init buttons] > [0.003826 Inits done] > [0.004094 tablet mode disabled > ] > [0.008272 found batt:SMP] > [0.022278 SW 0x01] > [0.042247 hash start 0x00040000 0x00021994] > [0.045823 Battery FET: reg 0x0018 mask 0x0018 disc 0x0000] > [0.071136 kblight registered] > [0.071544 PB init-on] > [0.071818 USB charge p0 m0] > [0.073670 ID/SKU ADC 4 = 1309 mV] > [0.075630 ID/SKU ADC 3 = 852 mV] > [0.076077 SKU ID: 71] > [0.076335 Motion Sensor Count = 3] > [0.083594 PD comm enabled] > ... > > - did not test bitbang programming mode, it is in line for > reworking for speeding up as well. > > Change-Id: Ic9f3972f585dd1976169965c2a2422253aeac87a > Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> > Reviewed-on: https://chromium-review.googlesource.com/1016037 > Reviewed-by: Randall Spangler <rspangler@chromium.org> > Reviewed-by: Mary Ruthven <mruthven@chromium.org> Bug: b:38448364 Change-Id: I2fbdf4509f6241070f3569d07d869ea667ad4535 Reviewed-on: https://chromium-review.googlesource.com/1145742 Commit-Ready: Mary Ruthven <mruthven@chromium.org> Tested-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* g: speed up RSA keygen by 40%Marius Schilder2018-07-161-423/+1180
| | | | | | | | | | | | | | | | | | | | Add a specialized modexp for 1024 bit operands. Available under CONFIG_DCRYPTO_RSA_SPEEDUP. Image size increase 2184 bytes. Signed-off-by: mschilder@google.com BRANCH=none TEST=new console command "genp [seed]"; record timing w/ and w/o speed-up and check that primes are identical for identical seeds. BUG=b:68167013 Change-Id: I23e2b5ab13902354debcdb42c693127e1e26262a Reviewed-on: https://chromium-review.googlesource.com/1083697 Commit-Ready: Marius Schilder <mschilder@chromium.org> Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org>
* cortex-m: Generate vector table in CPatrick Georgi2018-07-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Different versions of the linker behave differently when mixing object built with lto enabled (desirable for code size reduction) and disabled (assembler code), especially when they refer to each other symbols: The file evaluation order of the linker becomes important as it eliminates dead code at various points in time, and LTO code referring to non-LTO code or vice versa, is not visible at early runs. Sadly, just changing the order on the command line isn't sufficient: What works for gcc8 breaks gcc6 (and may behave different in even more ways on gcc4 or other versions). Therefore, implement the vector table in C, so it's compiled in LTO mode, just like the code it refers to. BUG=b:65441143 BRANCH=none TEST=with this change coral EC is functional when built with the gcc 8.1 based coreboot toolchain. Change-Id: I9b75f6558f0357e18000ff1161096c8f9c94a8ac Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://chromium-review.googlesource.com/1120333 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* Update signed_header.h with additional fields.Kor Nielsen2018-07-031-6/+30
| | | | | | | | | | | | | BRANCH=none BUG=None TEST=make buildall -J Change-Id: Ic5590bea4577c1d249cb628389fb930ef20fc9d2 Signed-off-by: Kor Nielsen <kor@google.com> Reviewed-on: https://chromium-review.googlesource.com/1115906 Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* gpio: extend flags size to accommodate GPIO_ flagsJett Rink2018-06-111-1/+1
| | | | | | | | | | | | | | | | | | | Widen the flags field from 16-bit to 32-bit to fit all of the current GPIO_flags. Also reorder fields within struct to allow arm compiler to use 16-bit instructions instead of 32-bit instructions when accessing fields (which is important for kevin board, otherwise it runs out of space) Lastly, re-tool macros to all reordering of gpio_alt_func struct fields. BRANCH=none BUG=b:109884927 TEST=builds on all boards Change-Id: I20b136c94a607c19031a88bddd255cc34cc57bbd Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1096018 Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* cr50: prepare for supporting both x25519 and p256 test keysVadim Bendebury2018-06-071-1/+8
| | | | | | | | | | | | | | | | | | | | | | | The signer script is checking the elf files for presence of test RMA keys, currently hardcoded to be x25519 keys. The algorithm (x25519 vs p256) is going to become a compile time option, the script should be prepared to determine the type of the key at run time, because the script could be used for signing images from different branches, compiled with different config options. The prod p256 key does not yet exist. BRANCH=none BUG=b:73296606 TEST=verified that prod signing images including x25519 keys is still working as expected. Change-Id: Icf48845279912ecc9ccdecec1764fcb5f85d22bd Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1079698 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* g: add documentation pointing to p256 modular reduction verification in CoqJade Philipoom2018-06-011-0/+28
| | | | | | | | | | | | | | | | Added a markdown file with some explanation and links to Coq code in a public GitHub repository. BUG=none BRANCH=cr50 TEST=none Change-Id: I4b40a94ce8686e5115b6b09825dfde0894d67a50 Signed-off-by: Jade Philipoom <jadep@google.com> Reviewed-on: https://chromium-review.googlesource.com/1080795 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* test/build.mk: Allow boards to specify test listsNicolas Boichat2018-05-281-0/+3
| | | | | | | | | | | | | | | | | Some tests cannot be built on some boards (not enough SRAM, unusual configuration, etc.). Instead of the long list of exceptions in test/build.mk that we currently use, allow each board (or chip) build.mk to set test-list-y, and only use the default list if it is unset. BRANCH=poppy BUG=b:80167548 TEST=make buildalltests -j Change-Id: I803c691f419451aad4396529302a4805cbe3f9b5 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1074572 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* cr50: pass params to vendor commands as structRandall Spangler2018-05-231-64/+53
| | | | | | | | | | | | | | | | | | | | | | | This makes it easier to add params or flags for vendor commands without changing all of the command handlers. It also reduces code size by 56 bytes. For now, existing command handlers continue to use DECLARE_VENDOR_COMMAND(). Added DECLARE_VENDOR_COMMAND_P() for handlers which take the params struct directly. The CCD command will be the first user of that, since it will have different rules for 'open' based on where the command comes from. No change to existing command behavior. BUG=b:79983505 BRANCH=cr50 TEST=gsctool -I still works Change-Id: I7ed288a9c45e381162e246b50ae88cf76e67490d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1069538 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: Refactor tracking vendor command originRandall Spangler2018-05-221-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | Added flags parameter to extension_route_command(). The caller now specifies whether the command comes from the USB interface or the AP. Moved USB-specific shuffling of response to embed result code into usb_upgrade.c, so extension_route_command() can be more generic. No change to permissions/behavior for existing commands. ccd_command_wrapper() still sends vendor commands as if they come from the AP. That's fixed in the next CL. Reduces code size by 128 bytes BUG=b:79983505 BRANCH=cr50 TEST=manual Build with DEBUG_EXTENSION defined, to turn on printing each command 'ccd lock' comes from AP and works From host, 'gscutil -I' comes from USB and fails From AP, 'gscutil -t -I' comes from AP and works Change-Id: I7136bb54073de9c5951a174c308151b1871c56f3 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1068101 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* g: speed up CCD UART processingVadim Bendebury2018-05-222-27/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AP and EC consoles may generate a lot of bursty traffic, and cr50 UART console to USB processing is very slow: when characters become available, a hooks task callback is invoked, which retrieves received characters one at a time and queues them up to the appropriate USB transmit queue. This patch speeds up things as follows: - increases the seize of USB transmit queues for AP and EC console channels to 512 bytes. Experiments supported by code instrumentation has shown that even this is not enough to avoid underruns, but this is a good compromise between memory use and performance, these sizes could be revisited later, - raises UART RX interrupt priority from level 1 to 0 - moving bytes from UART TX FIFO to USB queue happens on the interrupt context when UART TX interrupt is asserted - as many characters as possible are read from the UART first, before queuing function is called, and the entire received batch is passed to the queuing function. It has to be mentioned here that presently batch processing is not necessarily much more efficient, because queuing function becomes more complicated when multiple objects are passed to it, this will have to be dealt with in a separate patch. There is still a lot of room for improvement: - functions used to queue up data are very generic, dedicated code could help a lot. - UART drivers should have methods for collecting all bytes available in receive FIFO in one invocation, - USB side of things (dequeuing data and passing it to the controller. BRANCH=cr50, cr50mp BUG=b:38448364 TEST=ran 'chargen' application on both AP and EC to flood the console channels and observed the flow of characters on the host site, it is pretty smooth with occasional hiccups, especially when TPM is active, before this patch it was impossible to have both stream up, both were garbled. - Verified that new account can be created and user logged in on restarts while chargen is running, i.e. TPM task gets enough processing bandwidth. - When EC is reset, there seem to be no lost characters on the console (it used to cause some garbled console output before this patch). The below output was collected on Coral: > reboot Rebooting! --- UART initialized after reboot --- [Reset cause: soft] [Image: RO, coral_v1.1.8363+2cc945d5a 2018-05-15 17:41:57 ... [0.003605 init buttons] [0.003826 Inits done] [0.004094 tablet mode disabled ] [0.008272 found batt:SMP] [0.022278 SW 0x01] [0.042247 hash start 0x00040000 0x00021994] [0.045823 Battery FET: reg 0x0018 mask 0x0018 disc 0x0000] [0.071136 kblight registered] [0.071544 PB init-on] [0.071818 USB charge p0 m0] [0.073670 ID/SKU ADC 4 = 1309 mV] [0.075630 ID/SKU ADC 3 = 852 mV] [0.076077 SKU ID: 71] [0.076335 Motion Sensor Count = 3] [0.083594 PD comm enabled] ... - did not test bitbang programming mode, it is in line for reworking for speeding up as well. Change-Id: Ic9f3972f585dd1976169965c2a2422253aeac87a Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1016037 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* Shuffle const aroundPatrick Georgi2018-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | gcc 8.1 complains about duplicate const, and while some of these really are duplicate, others look like they were supposed to tighten the API contract so that variables are "const pointer to const data", but didn't have that effect. BUG=b:65441143 BRANCH=none TEST=building Chrome EC as part of upstream coreboot's build with a gcc 8.1 compiler now works (better. there are other issues left) Change-Id: I6016c5f282516471746f08d5714ea07ebdd10331 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://chromium-review.googlesource.com/1039812 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Cr50: Dcrypto: calculate appkey digests at runtime to save space.Allen Webb2018-05-171-59/+55
| | | | | | | | | | | | | | | | Before: *** 4560 bytes still available in flash **** After: *** 4696 bytes still available in flash **** BRANCH=none BUG=b:65253310 TEST=Update Cr50 with this image and verify the keys are the same. Change-Id: I1c722ced185c41f732ce0ed5236db01401f21dfc Signed-off-by: Allen Webb <allenwebb@google.com> Reviewed-on: https://chromium-review.googlesource.com/1031058 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: in dev mode allow unverified certificatesVadim Bendebury2018-05-161-0/+11
| | | | | | | | | | | | | | | | | | When running signed with dev keys and the fallback certificate is not available, proceed installing unverified root certificate. This at least allows to keep basic TPM functions like storing objects in NVMEM to keep going. Added a new return value to indicate this condition. BRANCH=cr50, cr50-mp BUG=none TEST=verified that it is possible to switch chromebook between prod and dev modes when running with a dev signed Cr50. Change-Id: I5b16d0bcbcfb25368f65075e1d2d485a69cb729f Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1054990 Reviewed-by: Nagendra Modadugu <ngm@google.com> Reviewed-by: Andrey Pronin <apronin@chromium.org>
* g: add AES CMAC according to RFC 4493Jade Philipoom2018-05-143-0/+361
| | | | | | | | | | | | | | | | | | | | AES-CMAC implementation based on extant 128-bit AES, following closely to the description in RFC 4493. Timing depends only on the length of the message, not the content or the keys. Signed-off-by: Jade Philipoom <jadep@google.com> BRANCH=cr50 BUG=b:72788497 TEST=Passed the four test vectors provided in the RFC; these tests are defined as commands in aes_cmac.c and can be run with "test_cmac 1 2 3 4" when CRYPTO_TEST_SETUP is defined. Change-Id: I96fb4f29927c11970a6a17c0fd583694aa945c91 Reviewed-on: https://chromium-review.googlesource.com/975181 Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Cr50: Added Pinweaver base implementation.Allen Webb2018-04-272-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds some of the ground work for hardware backed brute force resistance on Cr50. The feature is called Pinweaver. It will initially be used to enable PIN authentication on CrOS devices without reducing the security of the platform. A Merkle tree is used to validate encrypted metadata used to track login attempts. The metadata tracks counts of failed attempts, a timestamp of the last failed attempt, the secrets, and any associated parameters. Instead of storing the metadata on Cr50 an AES-CTR is used with an HMAC to encrypt the data so it can be stored off-chip and loaded when needed. The Merkle tree is used to track the current state of all the metadata to prevent replay attacks of previously exported copies. It is a tree of hashes whose root hash is stored on Cr50, and whose leaves are the HMACs of the encrypted metadata. BRANCH=none BUG=chromium:809730, chromium:809741, chromium:809743, chromium:809747 TEST=cd ~/src/platform/ec && V=1 make run-pinweaver -j Change-Id: Id10bb49d8ebc5a487dd90c6093bc0f51dadbd124 Signed-off-by: Allen Webb <allenwebb@google.com> Reviewed-on: https://chromium-review.googlesource.com/895395 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* g: fix signer to always use the manifestVadim Bendebury2018-04-181-16/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | Since the proper signer utility has been introduced in the chroot, there is no need in generating reduced command option set when building a self signed image. Also, the same manifest can be used for all images, self signed or signed using a fob. The manifest needs to be tweaked for the self signed images to match the test Key ID. Since the same base manifest is used for all signings, there is no need to support the "poor man's json parser" any more. Rearranged build.mk to accommodate new logic, and added some comments. BRANCH=cr50, cr50-mp BUG=b:78212718 TEST=verified that images with proper header version are created when both self signed and signed with a private key coming from the signing fob. Change-Id: I5a1f8a223098b0a6c830ef24ffe380fc0badcafa Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1017238 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* cr50: bypass signing step if cr50-codesigner is not availableVadim Bendebury2018-04-111-3/+5
| | | | | | | | | | | | | | | | | When building EC targets in the setups where the Cr50 codesigner utility is not present let's just bypass the signing step. Also removing bitrotten source code of the old codesigner. BRANCH=none BUG=chromium:830302 TEST='make buildall' succeeds even if cr50-codesigner is not available. Change-Id: Ic6c4988455bcee6c45504e1fe781f6e03636d57a Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1005401 Reviewed-by: Allen Webb <allenwebb@google.com> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* g: add Make variable for controlling blob swappingVadim Bendebury2018-04-071-0/+5
| | | | | | | | | | | | | | | | | | | The upcoming cr50-codesigner change will allow to use it for swapping arbitrary blobs in the Cr50 image before signing. Let's use this feature to replace test RMA public key with the prod one. BRANCH=cr50, cr50-mp BUG=b:73296144 TEST=with the rest of the patches in place verified that invoking make with CR50_SWAP_RMA_KEYS=1 causes swapping the RMA public key in the generated image. Change-Id: I4c9994c1a542f456b24d2066ecada9f92f1bfaf3 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/996514 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: use codesigner from chrootVadim Bendebury2018-04-051-6/+2
| | | | | | | | | | | | | | | | | Source code for Cr50 codesigner has been added to the chroot and the executable is installed as /usr/bin/cr50-codesigner when cros sdk is created/updated. Let's use the 'official' version instead of outdated local one. BRANCH=cr50,cr50-mp BUG=b:73296144 TEST=verified that properly signed Cr50 images can be built. Change-Id: Ibc68340a26011c7d5ac028bbee73cd0f2c39c291 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/996512 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* g: add caching around modulus loading.Marius Schilder2018-04-033-4/+17
| | | | | | | | | | | | | | | | Approx. 10% speedup on keygen. BRANCH=none BUG=b:68167013 Signed-off-by: mschilder@google.com TEST=buildall -j8; tcg_test passes Change-Id: Icea1628f75f5561130c3e56fee48cc6cbde046d0 Reviewed-on: https://chromium-review.googlesource.com/990937 Commit-Ready: Marius Schilder <mschilder@chromium.org> Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@google.com>
* g: use reset_count to determine system_rollback_detectedMary Ruthven2018-03-302-17/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the reset count to determine if there was a rollback in system_rollback_detected. Before system.c was checking if the inactive header was newer than active one to determine if the system rolled back. This wasn't accurate. Cr50 rollback isn't the only reason why a newer image may be rejected. The image may have been rejected because it wasn't signed correctly or it's corrupted, so we shouldn't be using the newer header as a sign that there was a rollback. The reset count is cleared when the AP boots. This means the rollback state will be lost the first deep sleep resume after the AP has booted. BUG=none BRANCH=cr50 TEST=manual flash a dbg image with version 4.0 that has two infomap bits erased. Check sysinfo to see that it doesn't think cr50 rolledback flash a dbg image with version 4.4 that has one infomap bit erased. Make sure that 4.4 image is rejected and cr50 is still running 4.0 Check sysinfo to see that it doesn't think cr50 rolledback flash a dbg image with version 4.4 that has two infomap bits erased. Make sure cr50 jumps to that image rollback to the 4.0 image Make sure sysinfo shows there was a rollback. Boot the system Make sure sysinfo shows there was a rollback. Change-Id: I85f2e001ffed9e2185a276dfa916e9b0a05ff7bf Signed-off-by: Mary Ruthven <mruthven@google.com> Reviewed-on: https://chromium-review.googlesource.com/985029 Commit-Ready: Mary Ruthven <mruthven@chromium.org> Tested-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* g: add stream sniffing for DUT spiflash content.Marius Schilder2018-03-271-0/+11
| | | | | | | | | | | | | | | | | Use the stream signing mechanism to hook outgoing spiflash content. This is (only?) used by Mn50 during chip production flows. BUG=None BRANCH=none TEST=make buildall -j8 Signed-off-by: mschilder@google.com Change-Id: Iccfee173865f587f088a31fcbc7b939823884c31 Reviewed-on: https://chromium-review.googlesource.com/981892 Commit-Ready: Marius Schilder <mschilder@chromium.org> Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* g: add missing define for UART register UART_VAL.Marius Schilder2018-03-271-0/+1
| | | | | | | | | | | | | | | Holds most recent 16 oversampled values of rx and cts inputs. Signed-off-by: mschilder@google.com TEST=buildall -j8 BUG=None BRANCH=None Change-Id: I798b8c2ba645712600d7634769f418d81dec5f79 Reviewed-on: https://chromium-review.googlesource.com/981775 Commit-Ready: Marius Schilder <mschilder@chromium.org> Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@google.com>
* g: make fw upgrade less chattyMarius Schilder2018-02-261-2/+1
| | | | | | | | | | | | | | | | | | When running w/ blocking usb console output (CONFIG_USB_CONSOLE_CRC) and the host is not polling the console, upgrade will fail. Signed-off-by: mschilder@google.com TEST=buildall -j8; gsctool update succeeds on mn50 BRANCH=none BUG=none Change-Id: I5c09694c146ba0fbf7562b86ab0fad0d578bc5ff Reviewed-on: https://chromium-review.googlesource.com/938392 Commit-Ready: Marius Schilder <mschilder@chromium.org> Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* Add rw_product_family field to signed_header.h.Jeff Andersen2018-02-261-1/+3
| | | | | | | | | | | | | | | | | This field allows multiple product families to be independently versioned and released, without risk of having one product family's image flashed to another product family's chip. BUG=b:73728151 BRANCH=none TEST=make buildall -J Change-Id: I53f5e5b1e9ac7ea19997f8d1228a568e66c43d39 Reviewed-on: https://chromium-review.googlesource.com/935759 Commit-Ready: Jeff Andersen <jeffandersen@google.com> Tested-by: Jeff Andersen <jeffandersen@google.com> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Nadim Taha <ntaha@google.com>
* g: add CONFIG_USB_CONSOLE_CRCMarius Schilder2018-02-241-0/+23
| | | | | | | | | | | | | | | | | This option will cause usb console output to block and also compute a crc32. Signed-off-by: mschilder@google.com TEST=make buildall -j BRANCH=none BUG=none Change-Id: Icf66d5ddbea52008a9c97094e7c83194caa7db79 Reviewed-on: https://chromium-review.googlesource.com/936281 Commit-Ready: Marius Schilder <mschilder@chromium.org> Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* g: optionally check board_id match at upgrade timeMarius Schilder2018-02-231-0/+17
| | | | | | | | | | | | | | | | | | CONFIG_IGNORE_G_UPDATE_CHECKS currently drops all upgrade checks. Now with CONFIG_BOARD_ID_SUPPORT only check for board_id match. CR50_DEV still retains full no check behavior. TEST=buildall -j8 BRANCH=none BUG=none Change-Id: I0d085a26c814cd0f35450f0a0db06fe8525ab896 Reviewed-on: https://chromium-review.googlesource.com/933589 Commit-Ready: Marius Schilder <mschilder@chromium.org> Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: use single __packed definitionVadim Bendebury2018-02-221-0/+1
| | | | | | | | | | | | | | | | | | | Various parts of Cr50 code and Cr50 related utilities duplicate definition of __packed available in include/common.h. Let's use the same definition everywhere. BRANCH=cr50, cr50-mp BUG=none TEST=make buildall succeeds verified that linker generated map files for Cr50 RW are the same before and after this change. built and used gsctoo and rma_reset Change-Id: Ib91f9bbad1f6822b347f32b393630f592df80d60 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/931929 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: remove set capabilities from powerbtnMary Ruthven2018-02-202-40/+0
| | | | | | | | | | | | | | | | | | | | Cr50 cannot override the state of the power button. It was possible with dev cr50 chips, but the capability was removed in prod chips. Change the console command, so it is only used to get the state of the power button. Remove all of the commands used to override the power button. BUG=b:73557298 BRANCH=none TEST=none Change-Id: I99cb5e8a18dd972fba460c434364702f06a26305 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/926964 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org>
* cr50: fix DEBUG_DRIVE commentBrian Norris2018-02-161-1/+1
| | | | | | | | | | | | | | This is the DEBUG_DRIVE register, not the DEBUG_BLOCK_OUTPUT. Copy/paste error? BRANCH=none BUG=none TEST=none Change-Id: Ic915b8675559d6f43d153f3a309becc621416dbe Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/924698 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
View Lorry Controller Status