Problems booting exynos5420 with >1 CPU
Doug Anderson
dianders at google.com
Fri Jun 6 16:03:50 PDT 2014
Nicolas,
On Fri, Jun 6, 2014 at 3:38 PM, Nicolas Pitre <nicolas.pitre at linaro.org> 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
More information about the linux-arm-kernel
mailing list