Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc

[Steve Munroe]

Brian Grayson <Brian.Grayson@freescale.com> wrote on 12/28/2005 03:34:17 
PM:

> On Tue, Dec 27, 2005 at 11:39:40PM -0700, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-12-28 at 00:11 -0600, Steve Munroe wrote:
> > > I don't have this kind info for the various flavours of PPC32 
processor. I
> > > happily defer to those who have this knowledge to decide.
> > 
> > We should discuss that with the freescale folks.
> ...

>   A few years ago, the e500 ABI specified mechanisms for both
> toolchains and code to obtain information about what APUs are
> expected:
> 
>   - the .PPC.EMB.apuinfo section in an object file or
>     executable specifies what version of which APUs is required
>     by the object.
> 
>   - the __get_apu_revision() function provides a mechanism for
>     userland to identify what APUs are available on the current
>     silicon, and/or emulatable by the current OS.
> 
>   Note that this was not meant to be an e500-only feature, but
> rather something that could be used on many cores going forward.
> 
>   I believe apuinfo section support is in most embedded PPC
> toolchains nowadays (it's in binutils, for example), but I am
> not sure if all OSs support __get_apu_revision() yet.  We did
> not specify an AUX_VECTOR type to specify APUinfo, but one
> could be added.
>
Note that glibc does not support the BOOKe ABI. Also __get_apu_revision() 
is processor specific so not likely to be included in mainline glibc. 
Embedded toolchains may be handling this a local mode or a separate 
utilities library.
> 
>   It sounds like AT_HWCAP and apuinfo are two different
> solutions to the same problem, with different strengths etc.
> The APUinfo section provides finer-grain control (which
> revision of which APU, with support for up to 2^16 APUs each
> with up to 2^16 revisions), whereas HWCAP, with its limited
> bits, can only support the coarse yes/no control.
> 
It sounds like to the PowerPC PVR. And I agree that it is different from 
AT_HWCAP. The AT_PLATFORM would be derived from the PVR but again at lower 
detail (a single string matching one of the -mcpu=<cpu_type> values.

Our kernel emulates the mfspr rx,PVR instruction for user state so 
applications can get the PVR directly (at least with newer kernels).

Alternatively we could ask for a new Aux Vector entry (i.e) AT_PROCVER 
that contains the PVR/APUinfo. I am not sure what the process is to add 
new AT_* type beyond talking to the kernel folks. Eventual it should be 
documented in the ELF ABI.

Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center