On Mon, 27 Feb 2017 02:22:08 +0000 André Przywara <[email protected]> wrote:
> 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? At least we should report every taken action in the sunxi-fel verbose log (about the SMC workaround getting applied) because it greatly simplifies troubleshooting. And IMHO having any options to suppress this workaround is a bit premature until we encounter a real A64/H64/H5 chip where it fails in the wild. Another variant of the detection heuristics could just use SRAM A2 (well, not quite "SRAM", but the OpenRISC reset vector area). I'm getting the following output on my Jide Remix Mini (Allwinner H64): $ ./sunxi-fel readl 0x40004 0x00000000 $ ./sunxi-fel smc $ ./sunxi-fel readl 0x40004 0x15000000 We are either reading zero from there, or it is a hardwired OpenRISC instruction L.NOP. -- Best regards, Siarhei Siamashka -- 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.
