On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: > >> On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas >> <catalin.marinas@xxxxxxx> wrote: >> > BTW, does the firmware make any checks on what bits it allows to be set? >> > Some of them may have security implications (and may not even be >> > documented). >> > >> > Anyway, the first step is this API provided by the secure firmware. >> > Since such API may need to be called before the MMU is initialised, >> > Linux would need to have knowledge of the platform type early on. Having >> > some platform hook (asm macro) to call early on wouldn't work with the >> > single zImage configuration. Stack space is not an issue as we already >> > have one for ARMv7 for D-cache flushing (XIP kernels would work but they >> > aren't that many). >> > >> That's true. > > That stack is ugly and _does_ break XIP (even if there aren't that many > if at all on ARMv7). Since we're already writing to RAM while setting > up the initial page table and therefore we did the necessary work to > locate it already, we could as well put a temporary stack for early > usage right below the page table. > >> >> Firmware point is actually irrelevant for OMAP since it can't be >> >> changed once it is ROMed. >> >> >> >> Patching in boot-loaders isn't an option either since every customers >> >> prefers to use there own boot-loader and then controlling this vital >> >> bits is impossible. >> >> >> >> So I re-iterate that we need to have solution to this problem. >> > >> > I don't disagree with this, a solution is needed. In the past I was for >> > having platform hooks in the early kernel code path but in the light of >> > latest kernel developments (FDT, single zImage), I no longer see this as >> > acceptable. >> > >> Thanks for acknowledging the problem. Not allowing such hooks for single >> zImage doesn't seems to be right. Nobody ships kernel build for all socs, >> and it's usage is really limited to few distro's. But that's different topic. > > No, I think this is right on topic. If nobody ships a kernel for > multiple SOCs, this is because right now this can't be done. But > distros are craving for this ability. > >> 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. Is OMAP getting beaten up here just because it uses ARM security feature and implements it's mechanics? 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
