This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]