On Tue, Jan 17, 2012 at 10:02 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: > >> On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: >> > On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: >> > >> >> On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: >> >> > On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: >> >> > >> >> >> How about allowing platform hooks for single SOC builds. I mean having >> >> >> this code under !single_zImage or something like that. That way we don't >> >> >> impact the single zImage efforts and also allow socs to have all those >> >> >> critical, vital bits enabled for the SOC specific builds. >> >> > >> >> > Absolutely not! Because if we start doing that, people will get lazy >> >> > and no platform will ever work in a multi-SOC kernel. >> >> > >> >> > If your SOC require some fancy setup that is not shared by other >> >> > platforms then please abstract that into the bootloader, or make sure it >> >> > can be deferred later on. >> >> > >> >> There is nothing fancy here. It's an ARM security architecture feature which >> >> OMAP implements. Have given enough reason about boot-loaders issues. >> > >> > I was not convinced by those reasons. Just push harder on the bootloader >> > side. There is _no_ reason for the bootloader not to take care of this >> > very platform specific issue. You can even do it into a standalone >> > uImage that returns to u-Boot after it is done with its magic. >> > >> >> Is OMAP getting beaten up here just because it uses ARM security >> >> feature and implements it's mechanics? >> > >> > I don't care if this is OMAP, UX500 or i.MX. There is a line to be >> > drawn and this is just too bad if you are trying to cross it. >> > >> Well I was trying to get a solution for a genuine problem. >> Let's take an example. >> >> #ifdef CONFIG_ARM_ERRATA_742230 >> cmp r6, #0x22 @ only present up to r2p2 >> mrcle p15, 0, r10, c15, c0, 1 @ read diagnostic register >> orrle r10, r10, #1 << 4 @ set bit #4 >> mcrle p15, 0, r10, c15, c0, 1 @ write diagnostic register >> #endif >> >> The SoC's which doesn't have security restriction and the kernel >> is in secure mode, above errata is applied in it's right place. Before >> MMU is enabled. There are many bits like this which are patched >> in kernel. >> >> On OMAP, all these can't be set-up in kernel since kernel is >> in non-secure mode. To set such bit's we need to call some >> pre-defined security calls. > > Absolutely. Just don't do it in the early kernel boot code where it is > not convenient to do so. > Got it. 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
