...snip... > > > Fair point. It will be harder to maintain and won't be consistent. > > >> Am not sure what you mean because secure API > >> as such isn't a problem. If you mean one standard interface > >> for all the ARM SOC's then that's something won't be > >> easy to handled because it is tied up the security architecture > >> which can vary across SoCs. > > > > The latter. This is exactly the kind of pain I forsaw with this > security > > shite, and when I heard about it I was utterly dismayed at ARM Ltd > for > > coming up with such a brain-dead lack of design here. > > > > You're having to struggle with the results of that by having lots of > > SoC specific hooks all around the place to fiddle with this that and > the > > other. Your need to have something called from the early assembly > code > > is just yet more of that disease caused by ARM Ltd's lack of forsight > > on this matter. > > > > I have no solution for you on this > > I managed use some secure macro kind of code but as you said it > will be really hard to maintain. > > So we are stuck with this issue then. So, is the upshot of this that the kernel isn't going to be in a position to enable the L2/outer cache on OMAP3 (due to the need for hacky/unmaintainable code)? Hence the bootloader/uBoot had better leave it enabled... Cheers, Joe > > Regards > Santosh > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" > in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
