mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2026-01-10 09:31:51 +00:00
9f40f11fe8
It worked on Link because the fan number and the fan channel were both 0. Samus has two fans, connected to different GPIOs. In the EC's ACPI interface block, register 0x04 is used to get and set the fan's target duty cycle, as a percentage value. Writing a 0 to this register will set the target duty cycle to 0, writing a 100 (0x64) will set it to 100%. Writing any other value will return the fan control to the EC, rather than driving it manually from the host. Likewise, reading from this register returns the current fan target duty cycle, as a percentage. If the EC is controlling the fan automatically, the returned value will be 0xFF. BUG=chrome-os-partner:23972 BRANCH=samus TEST=manual You can monitor the fan state from the EC console with the "faninfo" command. From the host side, test this interface from a root shell. Read fan duty: iotools io_write8 0x66 0x80 iotools io_write8 0x62 4 iotools io_read8 0x62 Set fan duty to 100%: iotools io_write8 0x66 0x81 iotools io_write8 0x62 4 iotools io_write8 0x62 100 Set fan duty to 50%: iotools io_write8 0x66 0x81 iotools io_write8 0x62 4 iotools io_write8 0x62 50 Set fan duty to 0%: iotools io_write8 0x66 0x81 iotools io_write8 0x62 4 iotools io_write8 0x62 0 Set fan control back to automatic: iotools io_write8 0x66 0x81 iotools io_write8 0x62 4 iotools io_write8 0x62 -1 Change-Id: I3a133b0b16e2a5e1ce04b16cb2bf035a04a83daf Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179373 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.