Nicolas, On Fri, Jun 6, 2014 at 3:38 PM, Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> wrote: > On Fri, 6 Jun 2014, Doug Anderson wrote: > >> Note that handling CPU resume in a way that can be updated by RW >> firmware is non-trivial and requires some SRAM to be saved across >> suspend/resume. > > Saved by the kernel or the firmware? By the SoC / board. The problem on the original ARM Chromebook: 1. After resume, the boot CPU comes up just as if it were booting from a cold boot. All clocks are back at their default and the SDRAM controller is no longer initted. SDRAM is sitting in self refresh. 2. CPU loads boot code from SPI flash. 3. Boot code needs to be read only for security reasons. You can have RW updates for some portion of boot code, but only the part _after_ clock init (needed for SDRAM), SDRAM reinit, cache init. That's because you need those parts to (quickly) run crypto verification code. If the SoC / board can keep its internal SRAM powered across suspend resume you've got an out. Now you can have the firmware stash its "wakeup" code into a location in SRAM. At wakeup time you can jump straight there and that code can worry about everything. Now a read-write firmware update can update the wakeup code and you're all set. In this case wakeup code doesn't survive a full power cycle / reboot so you don't need any extra verification like you do if you load from persistent storage. That all still means you need to qualify a rw firmware update, but that's better than nothing. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |