mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2025-12-27 18:25:05 +00:00
cddf8a545c
Any of the EC's temp sensors can have up to two independent thresholds
attached to them. When the temperature crosses the threshold (rising or
falling), a EC_HOST_EVENT_THERMAL_THRESHOLD event is sent to the AP. It's up
to the AP to read the sensor values and figure out why the event was sent.
The thresholds are set and enabled with ACPI writes to three registers in
the EC interface space: EC_ACPI_MEM_TEMP_ID, EC_ACPI_MEM_TEMP_THRESHOLD, and
EC_ACPI_MEM_TEMP_COMMIT. Refer to the comments in ec_commands.h for details
on their use.
ACPI does not provide any means to read the threshold settings (the AP will
just have to remember), but there is an EC console command "dptftemp", that
can be used to examine the current settings.
BUG=chrome-os-partner:23970
BRANCH=none
TEST=manual
On the EC console, check the current threshold settings and temperatures:
> dptftemp
sensor thresh0 thresh1
0 --- --- PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
3 --- --- I2C-Charger-Object
4 --- --- I2C-CPU-Die
5 --- --- I2C-CPU-Object
6 --- --- I2C-Left C-Die
7 --- --- I2C-Left C-Object
8 --- --- I2C-Right C-Die
9 --- --- I2C-Right C-Object
10 --- --- I2C-Right D-Die
11 --- --- I2C-Right D-Object
12 --- --- I2C-Left D-Die
13 --- --- I2C-Left D-Object
>
> temps
PECI : 318 K = 45 C
ECInternal : 306 K = 33 C
I2C-Charger-Die : 309 K = 36 C
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 309 K = 36 C
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 306 K = 33 C
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 307 K = 34 C
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 307 K = 34 C
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C
I2C-Left D-Object : Not calibrated
>
In this case, the PECI temp is 318 K, so let's set a threshold at 322 K. On
the AP:
[ "$#" -eq "2" ] || return;
iotools io_write8 0x66 0x81
iotools io_write8 0x62 $1
iotools io_write8 0x62 $2
}
Back on the EC console, we see that the threshold has been set:
[768.176648 DPTF sensor 0, threshold 49 C, index 1, enabled]
> dptftemp
sensor thresh0 thresh1
0 --- 322 PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Now do something on the AP to increase the temperature (webgl aquarium,
etc). When the temp goes above 322 K, the EC console reports it and sends a
host event, and the "dptftemp" command indicates the over-temp condition:
[815.367442 DPTF over threshold [0][1]
[815.367878 event set 0x00000100]
[815.368069 sci 0x00000100]
[815.368619 event clear 0x00000100]
> dptftemp
sensor thresh0 thresh1
0 --- 322* PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Log out and wait for the temp to drop. You'll see that trigger a host event
as well:
[854.375713 DPTF under threshold [0][1]
[854.376147 event set 0x00000100]
[[854.376396 event clear 0x00000100]
> dptftemp
sensor thresh0 thresh1
0 --- 322 PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Change-Id: I6bb34c615f37477ccf37163caaa94737baed8dae
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179962
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In the most general case, the flash layout looks something like this: +---------------------+ | Reserved for EC use | +---------------------+ +---------------------+ | Vblock B | +---------------------+ | RW firmware B | +---------------------+ +---------------------+ | Vblock A | +---------------------+ | RW firmware A | +---------------------+ +---------------------+ | FMAP | +---------------------+ | Public root key | +---------------------+ | Read-only firmware | +---------------------+ BIOS firmware (and kernel) put the vblock info at the start of each image where it's easy to find. The Blizzard EC expects the firmware vector table to come first, so we have to put the vblock at the end. This means we have to know where to look for it, but that's built into the FMAP and the RO firmware anyway, so that's not an issue. The RO firmware doesn't need a vblock of course, but it does need some reserved space for vboot-related things. Using SHA256/RSA4096, the vblock is 2468 bytes (0x9a4), while the public root key is 1064 bytes (0x428) and the current FMAP is 644 bytes (0x284). If we reserve 4K at the top of each FW image, that should give us plenty of room for vboot-related stuff.