Hi, On Tue, Dec 7, 2010 at 11:04 AM, Russell King - ARM Linux <li...@arm.linux.org.uk> wrote: > On Tue, Dec 07, 2010 at 10:45:42AM +0000, Dave Martin wrote: >> Yes-- though I didn't elaborate on it. You need a packager that can >> understand, say, that a binary built for ARMv5 EABI can interoperate >> with ARMv7 binaries etc. >> Again, I've heard it suggested that RPM can handle this, but I haven't >> looked at it in detail myself. > > That is indeed the case - as on x86, it used to be common to build the > majority of the distribution for i386, and glibc and a few other bits > for a range of ix86 CPUs. > > rpm and yum know that i386 is compatible with i486, which is compatible > with i586 etc, so it will install an i386 package on i686 if no i486, > i586 or i686 package is available. > > It does the same for ARM with ARMv3, ARMv4 etc.
That sounds plausible. If you really want to go to town on this it gets more complicated, but there's still a lot of value in modelling the architectural development as a linear progression in this way. > >> The dynamic hwcaps approach doesn't really solve that problem: > > Has anyone investigated whether it is possible to power down things like > Neon etc meanwhile leaving the rest of the CPU running? I've not seen > anything in the ARM documentation to suggest that's the case. > > Even in MPCore based systems, the interface between the SCU and individual > processors by default doesn't have the necessary clamps built in to allow > individual CPUs to be powered off, and I'm not aware of any designs which > decided to enable this feature (as there's a performance penalty). So I'd > be really surprised if there was any support for powering down Neon > separately from the host CPU. It's not part of the architecture per se, but some SoCs do put NEON in a separate power domain and can power manage it somewhat indepedently. However, I guess we need to clarify exactly how this works for SoCs in practice. If NEON and VFP are power-managed co-dependently (for example, but no so likely(?)) this is not so useful to us ... since it's becoming common to build everything with -mfpu=vfp*. Because the kernel only uses FPEXC.EN to en/disable these extensions, NEON and VFP are somewhat tied together ... though we might be able to get more flexible by toggling the CPACR.ASEDIS control bit instead. I don't believe the kernel currently touches this (?) > > If that's the case, it's entirely pointless discussing what userspace can > or can't do - if you have Neon available and can't power it down, and it's > faster for doing something, you might as well use it so you can put the > main CPU into WFI mode or get on with some other useful work. > Indeed ... my layman's understanding is that it is worth it on some platforms, but I guess I need to clarify this with someone who understands the hardware. Cheers ---Dave _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
