New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 851201 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

autotest for flash qualification

Project Member Reported by briannorris@chromium.org, Jun 9 2018

Issue description

In bugs like this:

https://issuetracker.google.com/72353950

we're currently telling partners to walk through this:

https://docs.google.com/document/d/1gFhHfOrUuDnLwqK8PGm17V4c5Wa9QjQltKu5qGAat0I/edit#

or if partners don't do it, some poor engineer gets suckered into it.

It seems like this is a prime candidate for an autotest, with servo assisting with toggling WP# at the appropriate times, and the rest happening according to some simple flashrom commands. I already automated a chunk of it myself in a tiny shell script:

#!/bin/sh

flashrom --wp-status
echo $(crossystem wpsw_cur)

cat > /tmp/layout.txt <<EOF
000000:2fffff QUAD1
200000:3fffff QUAD2
400000:5fffff QUAD3
600000:7fffff QUAD4
000000:3fffff HALF1
400000:7fffff HALF2
000000:7fffff FULL
EOF

for i in "QUAD1" "QUAD2" "QUAD3" "QUAD4" "HALF1" "HALF2" "FULL"
do
        dd if=/dev/urandom bs=1M count=8 of=/tmp/rand
        flashrom -l /tmp/layout.txt -i "$i" --ignore-fmap --write /tmp/rand
done


A proper full test would know which of these are expected PASS/FAIL, would do more diligence about the flash size, and would set a few different WP ranges.
 

Sign in to add a comment