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. Nicolas
