On 27/02/17 01:20, Siarhei Siamashka wrote: > On Wed, 22 Feb 2017 17:08:47 +0000 > Andre Przywara <[email protected]> wrote: > >> If an SoC has the "secure boot" fuse burned, it will enter FEL mode in >> non-secure state, so with the SCR.NS bit set. Since in this mode the >> secure/non-secure state restrictions are actually observed, we suffer >> from several restrictions: >> - No access to the SID information (both via memory mapped and "register"). >> - No access to secure SRAM (SRAM A2 on H3/A64/H5). >> - No access to the secure side of the GIC, so it can't be configured to >> be accessible from non-secure world. >> - No RMR trigger on ARMv8 cores to bring the core into AArch64. >> Those limitations make a board pretty useless for many applications. >> >> However it has been found out that a simple "smc" call will immediately >> return from monitor mode, but with the NS bit cleared, so access to all >> secure peripherals is suddenly possible. >> >> Add a sunxi-fel command called "smc" which will issue exactly this >> instruction to make those boards useful in "secure boot" FEL mode. >> >> It should be given early in the command queue to given subsequent code >> full access to the system: >> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... >> >> Signed-off-by: Andre Przywara <[email protected]> >> >> --- >> Hi, >> >> if that sounds vaguely useful (it definitedly is for me to get the Remix >> Mini PC started), I can follow the Github process if you prefer that. >> >> Cheers, >> Andre. > > Hi Andre, > > Why don't we just do this automatically without adding a new special > command? > > We are not allowed to read the SCR register for detecting this state, > right? But can we still use some other detection method? For example, > maybe try to read SID and assume that we need the SMC workaround if > it reads back as zero?
Yes, indeed I was thinking about exactly that ;-) >From actually using this feature I realized that its usage is error prone: non-secure boards crash on calling it, secure board just don't work without it. And indeed there is no architectural way of checking whether you are running secure or non-secure (as reading a secure-only register like NSACR or SCR will trap, which means crash in our case). So (trying to) read the SID is indeed the best workaround I came up with: If it's all zero, we are probably secure and need the smc. There is still a slight chance that the SID is all zero even on a non-secure board (I think this was the case for some older SoCs?), so maybe we need an option to suppress using this heuristic? Cheers, Andre -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
