NEON and THUMBEE hwcaps

From http://www.linux-arm.org/git?p=linux-2.6-stable.git;a=commitdiff;h=05be8e304bef9
bc4324afd0ab633a7a91f534bfe

From http://www.linux-arm.org/git?p=linux-2.6-stable.git;a=commitdiff;h=22d9d9ae0e5741511a6b698df0b5605a4cf864e4

NB: We already have THUMBEE support, but we were missing the "thumbee" in hwcap_str[].

Sub-ing release for FFE.

Will require a trivial one line change to gblic's "IMPORTANT_HWCAPS".

Clean upstream cherry-picks:

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=63dd1b75dc28ea3d5d4a35afb333a47df4988105
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=eaba0a7cc76a3458b350588f59d650dc69a84db2

This bug was fixed in the package linux - 2.6.28-10.33

---------------
linux (2.6.28-10.33) jaunty; urgency=low

  [ Scott James Remnant ]

  * SAUCE: nbd: Change default partitions per device to 15
    - LP: #342563

  [ Tejun Heo ]

  * SAUCE: libata: make sure port is thawed when skipping resets
    - LP: #269652

  [ Tim Gardner ]

  * Revert "SAUCE: Auto-load esp module when device opened."
    This driver performs unsafe ISA probes (according to Alan Cox).
  * Enable CONFIG_USB_GADGET_DUMMY_HCD
    This facilitates gadget slave endpoints in virtual environments.
  * Build ehci, uhci, and ohci into the i386/amd64 kernels
    - LP: #296710

  [ Upstream Kernel Changes ]

  * Add "thumbee" to the hwcap_str array
    - LP: #343602
  * Add HWCAP_NEON to the ARM hwcap.h file
    - LP: #343602
  * x86: mtrr: don't modify RdDram/WrDram bits of fixed MTRRs
    - LP: #292619

 -- Tim Gardner <email address hidden> Mon, 16 Mar 2009 08:19:53 -0600

FFe granted.

Need to patch glibc for NEON hwcaps:
PROCINFO_CLASS const char _dl_arm_cap_flags[10][10]
#endif
#ifndef PROCINFO_DECL
= {
    "swp", "half", "thumb", "26bit", "fast-mult", "fpa", "vfp", "edsp",
    "java", "iwmmxt",
  }
#endif

in ports/sysdeps/unix/sysv/linux/arm/dl-procinfo.c
(add "thumbee" and "neon" I think, checking with people who run the new kernel)

and:

/* The following must match the kernel's <asm/procinfo.h>. */
#define HWCAP_ARM_SWP 1
#define HWCAP_ARM_HALF 2
#define HWCAP_ARM_THUMB 4
#define HWCAP_ARM_26BIT 8
#define HWCAP_ARM_FAST_MULT 16
#define HWCAP_ARM_FPA 32
#define HWCAP_ARM_VFP 64
#define HWCAP_ARM_EDSP 128
#define HWCAP_ARM_JAVA 256
#define HWCAP_ARM_IWMMXT 512

in ports/sysdeps/unix/sysv/linux/arm/sysdep.h
(needs new defines)

Then patch HWCAP_IMPORTANT as in http://bazaar.launchpad.net/~ubuntu-toolchain/ubuntu-toolchain/glibc-2.5-package/revision/201

Trick to see hwcaps from /proc/self/auxv as seen by ld.so/glibc:
% LD_SHOW_AUXV="" cat </dev/null
AT_HWCAP: swp half thumb fast-mult vfp edsp
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x8034
AT_PHENT: 32
AT_PHNUM: 9
AT_BASE: 0x40000000
AT_FLAGS: 0x0
AT_ENTRY: 0x8ba8
AT_UID: 1000
AT_EUID: 1000
AT_GID: 1000
AT_EGID: 1000
AT_SECURE: 0
AT_EXECFN: /bin/cat
AT_PLATFORM: v7l

Trick to force hwcaps on a platform:
% sudo LD_HWCAP_MASK=0x0 ldconfig
now ld.so wont find any additional hwcap selected libs in the ldconfig cache:
% ldconfig -p | grep vfp
% ldd /bin/ls | grep vfp

To force e.g. usage of thumb hwcaps:
% sudo mkdir /lib/thumb
% sudo cp /lib/libm* /lib/thumb
% sudo LD_HWCAP_MASK=0x4
% ldconfig -p | grep thumb
        libmemusage.so (libc6, hwcap: 0x0000000000000004, OS ABI: Linux 2.6.16) => /lib/thumb/libmemusage.so
        libm.so.6 (libc6, hwcap: 0x0000000000000004, OS ABI: Linux 2.6.16) => /lib/thumb/libm.so.6

Note for self: there's theoritically support for a NT_GNU_HWCAP section (.note.gnu.hwcaps ELF section), but I don't think ld/as have any support for setting it in the binaries they output; in fact looking at SSE2 hwcap-selected binaries on my i386 system and at hwcap-selected binaries on my armel system, I couldn't find any such section in the ELF files. Despite this absence, "hwcap:" flags are computed by glibc on the basis of the pathname alone (e.g. /lib/vfp/foo.so => vfp hwcap).

That's why there's no need to patch the ELF parser to pickup NEON binaries for the above changes.

(While with Sun ld, there is a .SUNW_cap section created by as.)

The proposed changes "worked" on my babbage board in that the resulting libc6 and libc6-vfp packages would still work as before, I could run and reboot the system just fine.

"LD_HWCAP_MASK=0x1040 ldconfig" passes (NEON + VFP), but doesn't change anything as obviously I don't have NEON libs.

I created /lib/neon and copied /lib/vfp/libm.so* to it and ran the above ldconfig; then I got:
% ldconfig -p | grep libm.so
        libm.so.6 (libc6, hwcap: 0x0000000000001000, OS ABI: Linux 2.6.16) => /lib/neon/libm.so.6
        libm.so.6 (libc6, hwcap: 0x0000000000000040, OS ABI: Linux 2.6.16) => /lib/vfp/libm.so.6
        libm.so.6 (libc6, OS ABI: Linux 2.6.16) => /lib/libm.so.6
        libm.so (libc6, OS ABI: Linux 2.6.16) => /usr/lib/libm.so

vim uses libm; I don't know how the selection is performed:
% ldd /usr/bin/vim | grep libm
        libm.so.6 => /lib/vfp/libm.so.6 (0x402e6000)

ideally, neon would imply vfp and turn on this hwcap; I don't know how to achieve this with the current hwcap system. The best is probably to let neon version conflict with vfp versions, but it's suboptimal.

Dave, could you test this glibc against a NEON enabled kernel and hardware?

Thanks,

This bug was fixed in the package glibc - 2.9-4ubuntu5

---------------
glibc (2.9-4ubuntu5) jaunty; urgency=low

  * This upload allows NEON hwcap usage; FFE LP: #343602.
  * New patch, arm/local-hwcap-updates, add support for some recent ARM hwcaps
    additions.
  * Update patch arm/local-no-hwcap to also flag HWCAP_ARM_NEON as an
    important hwcap; this adds /lib/neon, /usr/lib/neon etc. to the ldconfig
    and ld.so search pathes.

 -- Loic Minier <email address hidden> Tue, 31 Mar 2009 20:28:41 +0200

I've tested the modified libc from http://people.ubuntu.com/~lool/glibc-neon/, on kernels both with and without the CONFIG_NEON enabled.

The libc hwcap setup for NEON appears to work fine.

I put some dummy libraries in /lib and /lib/neon and wrote a simple test program:
  * using a kernel with CONFIG_NEON disabled, the library from /lib is used
  * using a kernel with CONFIG_NEON enabled, the library from /lib/neon is used (as expected).

Regarding the comment above that NEON should imply VFP, I should clarify this a bit:
  * The presence of NEON support on hardware does not necessarily mean that VFP is there (although in practice we expect that it almost always will be)
  * If VFP and NEON are both present, this does imply some extra NEON floating-point functionality, which is not available if NEON is present but VFP is absent.

So if the kernel reports HWCAP_NEON, ld.so should not automatically assume that HWCAP_VFP is present (this matches the current ld.so behaviour, so it's OK).

However, code which uses NEON floating-point functionality (probably most real NEON code) can only be guaranteed to run reliably if HWCAP_NEON and HWCAP_VFP are both reported by the kernel. glibc support this for combinations of hwcaps as /lib/vfp/neon, /lib/neon/vfp (for example), which should achieve the desired result.

Here's the output of ldconfig -p (where I've put copies of libc.so.6 in /lib/neon /lib/neon/vfp and /lib/vfp/neon (there's already one in /lib/vfp, from libc6-vfp):
        libc.so.6 (libc6, hwcap: 0x0000000000001040, OS ABI: Linux 2.6.16) => /lib/neon/vfp/libc.so.6
        libc.so.6 (libc6, hwcap: 0x0000000000001040, OS ABI: Linux 2.6.16) => /lib/vfp/neon/libc.so.6
        libc.so.6 (libc6, hwcap: 0x0000000000001000, OS ABI: Linux 2.6.16) => /lib/neon/libc.so.6
        libc.so.6 (libc6, hwcap: 0x0000000000000040, OS ABI: Linux 2.6.16) => /lib/vfp/libc.so.6
        libc.so.6 (libc6, OS ABI: Linux 2.6.16) => /lib/libc.so.6

(I think that neon/vfp and vfp/neon are interchangeable, but there may be additional subtleties. When actually running an executable, I get /lib/neon/vfp/libc.so.6 linked in, but I don't currently know whether there is a real rule at work or it is just by coincidence that this library is chosen instead of /lib/vfp/neon/libc.so.6. Probably we should choose just one of these directory combinations and stick to it:

I vote for neon/vfp (since architecturally the extra functionality is really an extension to NEON rather than an extension to VFP).

In summary, it looks like everything now works as needed to support libraries with these different hwcap combinations.