> > The right way to do this is with HWCAPS bits to identify whether the
> > hardware can run v7 binaries and for dpkg to refuse to install stuff
> > that won't run.
> >
> > This is how it works on x86:
> > http://developers.sun.com/solaris/articles/hwcap_modification.html
> > with HWCAPS for cmov
> On 17 April 2012 18:36, Wookey wrote:
> > debian armel is currently
> > built for v4t but is likely to move forward to v5 at some point.
>
> -1 as we have and others have products that are arm4vt and that ship
> with Debian as its standard system. How big is the speed advantage for
> v5 users w
> Steve McIntyre wrote:
> > They'll be upwardly-compatible (i.e. they'll work on v7), but not in
> > reverse. armhf is explicitly defined to be ARMv7+, using VFPv3-D16 (no
> > Neon). That's standardised across distros too.
> >
> > There's a chance that some of the armhf binaries might run on v6, b
> If you identify the v7 instructions that are not in v6, you can use
> something like the attached, which I wrote to count the percentage of
> MaverickCrunch instructions in the binaries in a Debian package.
I can tell you the answer now.
If you're building in ARM mode there's approximately zero
> BTW my gcc man page has an armv6t2 -march= target, so I suspect there
> are some ARMv6 CPUs with Thumb-2.
You still can't run ARMv7 Thumb-2 code an an ARMv6t2 core. The same way you
can't run ARMv7 ARM code on an ARMv6 core. THe only ARMv6t2 implementation I
know of is the arm1156 (which I
> With actual RPi hardware still being 6 to 8 weeks out, would a Freescale
> i.MX535 Quick Start board allow such benchmarking? I presume an armel
> install of Debian and compiling certain packages with VFP2 optimizations
> would be pretty straight forward. Is armhf in such a state that it would b
> dumb question from (still) a linux-noob:
>
> i've had debian installed on my thecus n2100 (think it's been squeeze
> yet) - but had to rip out the disks as i urgently needed them
> somewhere else, of course without having created an image before :( so
> now - new disks put in - the thecus-tool d
> there is a strange FTBFS only on Armel platform [1].
>
> ==
> Rn.h:217:23: error: 'R2' does not name a type
> ..
> Why does it happens, and only on Armel?
Probably a conflict with the definition of R2 int sys/ucontext.h.
Paul
--
To UNSUBSCRIBE
> > b) The SWP instruction is gone. It may fault, it may get fixed up by
> > the kernel (slowly), but it shouldn't be used anymore (it's not
> > compatible with mutli-core designs, Load/store exclusive should be
> > used instead).
>
> swp is currently replaced with ldrex/strex in the run time libr
> > > So is there a way to ask gcc "What the hell are your defaults right
> > > now?".
> >
> > I don't consider that a well formed question[1]. You should be asking
> > what the compiler is *doing* right now. The answer is in a preprocessor
> > macro.
>
> How about "What is the default target o
> On Fri, Sep 02, 2011 at 10:06:55PM +0100, Paul Brook wrote:
> > Right. That's almost certainly a bug. My guess would be cargo-cult
> > copying or an old hack to workaround borkenness elsewhere.
>
> OK, so simply removing the explicit CFLAGS settings in the Makefile,
> On Fri, Sep 02, 2011 at 03:10:50AM +0100, Paul Brook wrote:
> > Your understanding is incorrect. Thumb interworking is always enabled
> > when generating armv5 or later code, plus it is enabled by default for
> > all EABI based targets. Both of which are true for armhf.
&
> My understanding of the gcc defaults on armhf is that thumb-interworking
> is not enabled by default.
Your understanding is incorrect. Thumb interworking is always enabled when
generating armv5 or later code, plus it is enabled by default for all EABI
based targets. Both of which are true fo
> On Wed, Aug 31, 2011 at 01:49:49PM +0100, Paul Brook wrote:
> > Interworking is a madatory of the ARM EABI. As mentioned above,
> > interworking is basically free on armv5 and later architectures. It
> > should never be disabled.
>
> Wel the gcc in armhf has
> > Is that true? For ARMv7, interworking is essentially free and Thumb code
> > would likely be faster due to its smaller memory footprint. So I would
> > have thought that not only should Thumb code be catered for, but
> > actively encouraged. Or am I missing something?
>
> We only use thumb2 in
> > > char buf[8];
> > > void *v = &buf[1];
> > > unsigned int *p = (unsigned int *)v;
> >
> > This does not (reliably) do what you expect. The compiler need not align
> > buf.
>
> Printing the value of p should clarify this.
>
> And, as we can see above, the "simple" accesses
> >> There is still going to be a small cost even in hardware fixup so this
> >> is very much worth solving despite it's "becoming invisible" because the
> >> chips are hiding / solving it already.
> >
> > But I believe that h/w feature is turned off in Linux by default. You
> > have to add noalig
> Amother solution would be to emulate the thumb instructions linux uses by
> catching the illegal instruction signal in kernel space alla FPA emulators.
The problem isn't Thumb instructions per se, it's the ARM mode bx instruction.
This is used by all code, even if you don't actively use Thumb
> On Thu, Dec 30, 2010 at 7:29 PM, Paul Brook wrote:
> >> you have to bear in mind that "future porting" *used* to be very
> >> uncommon an occurrence (as if doing it 14 times is "uncommon")
> >>
> >> but with the massive explosion in
> you have to bear in mind that "future porting" *used* to be very
> uncommon an occurrence (as if doing it 14 times is "uncommon")
>
> but with the massive explosion in compiler options for ARM processors
> alone, the process of "porting" now becomes a massive headache.
Really? AFAIK the only
> FWIW, my box is a "Raidsonic NAS IB-4220-B" (machtype 2038, FA526 CPU,
IIRC these are not strongarm based. They're a cheap NAS chipset from a
Tiwanese manufacturer who is still knocking out custom cores that only
implement ARMv4. I assume that being prehistoric and effectively incompatible
wi
> I believe that the v4-support in the toolchain was eventually done,
> but I'm not sure if it's mainlined, and we definately haven't changed
> the default Debian build. Can someone who knows/recalls the details
> tell us what the cost of building armel for v4 would be, and if it is
> actually poss
> In essence, I would like to express my objection in having the same triplet
> for both softfp and hard ABIs. I know upstream (ARM) objects, but IMHO they
> just haven't done the extensive compiling I have and didn't consider the
> problems (I doubt anyone else has built ~8000 packages for a hardf
> > excellent question, to which you should be receiving the response by
> > now. the summary is this: i do not believe it is off-topic to have
> > specific hardware and specific software totally excluded from testing
> > at the sprint, on the basis that the only available toolchain,
> > libraries
> > I think that is not difficult,through I have not done it .
>
> i have, and there are quite a few hoops to jump through. the first
> is getting the GPL source code out of toshiba. this is absolutely
> essential.
And if they're using closed source kernel modules for critical subsystems such
> You will need to cross-build MINIX. For which you need
> cross-toolchains. According to the doc below these need to output COFF
> for OS independence. Is that still true for MINIX3?
I strongly advise making any new port EABI/ELF based. The COFF toolchain
support is largely unmaintained, and is
> > On ARM one could have armelv5, armelv6, armelv7, armelv7neon, .., all
> > subarchs armel and crossinstallable. Before someone jumps "what about a
> > ARMv6 with NEON but no VFP", obviously some discretion must be used when
> > selecting subarchs to be supported.
>
> I don't think NEON without
> > One way to check how well softfp performs would be to run povray in
> > Ubuntu versus in Debian; this will mix noise in the results, but I
> > don't expect the minor sourceful differences to make the biggest
> > impact, but rather the toolchain opts would. (You're speaking of a
> > 3-fold
> > Do the math, there are 6 more vmov instructions (all between rX and sX
> > registers) in the softfp versions. Ok, if one gives a stall of 20 cycles,
> > how many cycles do we lose in sinf() alone?
> So, what exactly did you want to prove?
Mainly that your analysis of the code was almost enti
> > > > Do the math, there are 6 more vmov instructions (all between rX and
> > > > sX registers) in the softfp versions. Ok, if one gives a stall of 20
> > > > cycles, how many cycles do we lose in sinf() alone?
> > >
> > > Depends how the function is called. Worst case we loose 17 cycles, best
>
> As Konstantinos explained, this is something of the order of 6 moves
> around from integer to float and back again for a relatively simple
> function like sinf() which takes one floating point argument and
> returns one. vmov rN, sN has a penalty of around 20 cycles. Nothing is
> being done here,
> > In libm.so, I took sinf() -a very often used function, absolutely
> > necessary for any trig stuff- and tried to actually find the differences
> > using
> >
> > objdump:
> >...
> >
> > Do the math, there are 6 more vmov instructions (all between rX and sX
> > registers) in the softfp versions.
> In libm.so, I took sinf() -a very often used function, absolutely necessary
> for any trig stuff- and tried to actually find the differences using
> objdump:
>...
> Do the math, there are 6 more vmov instructions (all between rX and sX
> registers) in the softfp versions. Ok, if one gives a stall
> On Thursday 15 July 2010 21:11:50 Paul Brook wrote:
> > Choice of ISA is independent of the ABI. Generally speaking ARM code is
> >
> > still faster. This is another instance of where you want multiple
> > builds of the same package within the same port, so us
> > Switching to the hard-float ABI certainly does give some benefit. While
> > 20% isn't a trivial difference, it's important to keep this in context.
> > This is on top of what I'd guess is a 10x (i.e. 1000%) speedup achieved
> > without breaking the ABI and requiring a whole new port.
>
> How
> > What you're describing here is multiarch.
>
> Multiarch still isn't there, even after at least 5 years when I saw the
> first presentation. It may have been hard on x86/x86_64 or ppc/ppc64 where
> there were only 2 variants, here we have what? 5? 10? I seriously think
> it's not worth it.
No.
> Lets take a step back on the naming.
>
> Let's say for example that we decide to use the fact that ThumbEE is a
> required component on the ARMv7-A profile.
>
> My qualm with Thumb code on ARM is that it requires all libraries and
> executables to be compiled with a compatible ABI in the first
> On Thursday 15 July 2010 19:48:43 Aurelien Jarno wrote:
> > Note that the new alternative to hwcap is called "multiarch" in the GNU
> > libc (something totally different than "multiarch" in Debian). It allows
> > to provide different versions of a given symbol using an IFUNC symbol
> > type. This
> > Enabling use of VFP does not require use of the hard-float ABI. Please
> > don't confuse the two.
>
> The whole point of the port is that we get rid of the softfloat ABI in
> order to use the VFP unit without playing around moving
> registers around. This sort of came about from Konstantinos'
> On Thu, Jul 15, 2010 at 03:47:33PM +0100, Paul Brook wrote:
> > > armel can also use vfp instructions, so I personally find it
> > > confusing.
> > Yes, however fixing this this does not require a new port. It only
> > requires providing alternative packages
> On 7/15/10, Loïc Minier wrote:
> > armel can also use vfp instructions, so I personally find it confusing.
>
> No it can't. Any binary that contains a vfp instruction will die with
> SIGILL on any armv4t chip that has no vfp cpu, so cannot be used in
> Debian armel.
Yes, however fixing this
> On Wed, Jul 14, 2010 at 05:11:16PM -0500, Matt Sealey wrote:
> > It's ARM's architecture and theirs to license, not Marvell's or
> > Qualcomm's.
> >
> > Qualcomm won't be so particularly annoyed as they get a big reference
> > in ARM's manuals (Qualcomm Scorpion is referenced).
> >
> > In the e
> Genesi have recommended 'cortex' as Debian architecture name and
> 'arm-hardfloat-linux-gnueabi' as triplet. This has been in fact
> approved and endorsed -and actually encouraged- by ARM itself, they
> really liked the idea of having a debian-cortex port.
I suspect the other architecture licens
> On 12/07/10 14:34, Paul Brook wrote:
> > Anything that relies on the target triplet is going to break as soon
> > as you move outside a pure Debian system. i.e. any patches relying on
> > a particular target triplet are inherently Debian specific, and IMO
> > shou
> On 09/07/10 19:16, Hector Oron wrote:
> >arm-hardfloat-linux-gnueabi
>
> This would be the path of least resistance. You can do this without
> breaking much, and without annoying anybody upstream. You might need to
> do a few hacks to various packages that want to know which ABI is in
> use
> The tricky-bit here is that instruction-set extensions (VFP3, thumb2,
> NEON) and instruction set versions (v4, v5, v6a, v7) can also be
> incompatible in the sense that they won't run on hardware without
> those features. But I really think we should try to deal with that by
> correctly decorati
> > The tricky-bit here is that instruction-set extensions (VFP3, thumb2,
> > NEON) and instruction set versions (v4, v5, v6a, v7) can also be
> > incompatible in the sense that they won't run on hardware without
> > those features. But I really think we should try to deal with that by
> > correctl
> This just makes it even more important that any hypothetical FPU-based
> Debian variant thinks very, very carefully about the ABI it uses. There
> is a standard EABI variant for passing parameters in FPU registers ---
> but is it sufficiently common to be useful in a cross-platform OS? Are
> ther
> > I would be a bit scared that this has a chance of getting out of date,
> > or be confusing because other ports might be v7 as well, or also
> > because this only reflects a subset of the ports' requirement (VFP
> > level for instance isn't reflected, such as vfpv2, vfpv3).
>
> ARMv7 (w
> On 7/9/10, Martin Guy wrote:
> >Any mistake by users trying to mix the regular armel packages and
> >
> > the hardfloat ABI ones would just fail immediately.
>
> Erm my mistake. *Should* fail immediately but don't.
> I just ran some tests on Maverick hardfloat in a Debian armel
> environ
> The set of incompatible ABI options (as opposed to instruction set
> options) we have is:
> OABI/EABI
> big-endian/little-endian
You missed one. This should be LE/BE32/BE8.
BE32 and BE8 are only compatible at the object file level, not at the
application/shared library level.
For those followi
A couple of inaccuracies:
> These are configured by the gcc flags: -mfloat-abi={soft,softfp,hard}.
> Softfp is the default in pretty much every distro out there (incl. Ubuntu,
> Debian, etc). Only some OpenEmbedded builds have enabled hardfp, but these
> are too specialized.
Debian is pure soft-f
> I try to install Brother MFC 7820N as a network scanner on a QNAP
> TS-109 device using Linux kernel 2.6.26-2-orion5x. Two driver packages
> are provided by Brother Industries (brscan2-0.2.5-1.i386.deb and
> brscan2-0.2.5-1.amd64.deb), but unfortunately none for the armel
> architecture. The driv
> Namely, if there was ALWAYS a way (which could not be turned off) to
> extract a kernel's configuration (in a format which could be plunked into
> /usr/src/linux and used to build new modules) from the running kernel,
> things would be much simpler.
The config is generally fairly easy to figu
> I've also been thinking about getting a SheevaPlug or its newly announced
> successor GuruPlug and using the internal SD card as mass storage. Does SD
> have less problems that USB sticks when used instead of a harddisk, or
> would I run into the same issues?
In my experience SD cards have even
On Monday 08 February 2010, Martin Guy wrote:
> On 2/8/10, Karsten König wrote:
> > OT: Are there plans to raise this to ARMv5 or even higher after Squeeze?
> > Or are the benefits not worth dropping the older devices?
>
> I hope not. armv4t is pretty widespread in single-board computers,
> whil
On Wednesday 27 January 2010, Bastian Blank wrote:
> On Wed, Jan 27, 2010 at 10:47:55PM +0200, Riku Voipio wrote:
> > There is a major problem with gcc 4.4 and armel - the ABI of va_list
> > changed (for c++ libraries). We need to decide one of the following:
>
> What exactly have changed? The ABI
> I have been messing with Debian on my Sheevaplug, but today picked up what
> I thought would be a piece 'o cake. It is a 7" netbook, 800x480 lcd, 3 usb
> ports ethernet and wireless. Looks like 2 GB flash disk, with Windows CE
> installed on it. Problem is, it asks for a password when trying t
> char f[4];
> ...
> any idea why gcc would lay out the memory differently for armel than for
> i386? i haven't tried it on the old arm architecture.
The alignment of "f" is entirely arbitrary.
It could be effected by any number of things, including but not limited to
where other variables happ
>Now it seems that the irrlicht library depends on those symbols
>provided by libgcc_s.so.1 (and does not define them locally contrary to
>what was seen by Aurélien in libvorbis in #462318) and of course
>dpkg-shlibdeps complains because they can't be found in the symbols file.
>...
> So should I r
On Wednesday 29 October 2008, Martin Guy wrote:
> On 10/29/08, Paul Brook <[EMAIL PROTECTED]> wrote:
> > The correct macro is __VFP_FP__
>
> If __MAVERICK__ is defined, __VFP_FP__ isn't, but the word order is the
> same. Thay may not matter much to most folks, but i
> > > gsf thinks only vfp enabled arm uses natural endian doubles. However,
> > > eabi does that as well. As anyone using vfp is also using eabi,
> > > the correct change is to switch the define.
> > >
> > > -#if defined(__arm__) && !defined(__vfp__) && (G_BYTE_ORDER ==
> > > G_LITTLE_ENDIAN)
> >
> I have the following configuration: a thecus n2100 with two disks
> configured as raid1 (actually there are three partitions on each disk: a
> non-mirrored swap partition
Rookie mistake. If either drive goes down you suddenly loose swap, and the
whole machine is foobared. linux will do load ba
> > I now have a functional patch for EABI on v4 processors. I can push it
> > out if you're interested.
>
> I'm exceedingly interested, largely on behalf of people who are using
> balloon2 (and thus strongarm) in current production hardware, and
> would like to be able to use eabi.
>
> I can also
> The disadvantage is that it requires armv4t processors, excluding
> older ARMv4-based systems (CATS, NetWinder, Balloon 2). The simplest
> way to circumvent this would be to patch the kernel to emulate the
> missing BX instruction.
I now have a functional patch for EABI on v4 processors. I can p
> Second, does anyone know of an ARM system that has one of the
> following ethernet chips on the PCI bus:
>Intel EEPro100
>PCI NE2000 clones
>AMD PCnet/PCI
>RealTek RTL8129/8139
FWIW Qemu emulates the above devices, some of which give significantly better
performance than the
> > (#if defined __arm__)
> > byte swapping occurs in a private copy of gmp which doesn't appear to be
> > used.
>
> Well spotted!
> Fortunately, for the Debian build, -lgmp3 takes priority, but that
> will cause breakage on other ARM EABI builds without libgmp3, and
> means inserting defined(__ARM
rm_final_prescan_insn. use_return_insn
should probably also be hardwired to zero.
> > I gather from some comments Paul Brook made a while back that the
> > above code is only part of the solution and that something similar is
> > needed for library code too (or something like that).
> Does anyone really win by having us bulk out and slow down the whole
> distro a ilttle with thumb capability so as to be able to compile just
> one or two programs in thumb mode?
I think Thumb mode is important. Especially now that there is Thumb-2 and CPUs
that only support Thumb mode[1].
The
On Tuesday 13 June 2006 12:14, Catalin Marinas wrote:
> On Tue, 2006-06-13 at 10:41 +0100, Phil Blundell wrote:
> > On Mon, 2006-06-12 at 23:54 +0200, Martin Guy wrote:
> > > Is there any reason not to make ldm the default for armv4 and above,
> > > since it seems to win most, among the various opt
> > Is there any reason not to make ldm the default for armv4 and above,
> > since it seems to win most, among the various options?
>
> Two reasons: because it requires the return address to be on the stack
> (which often requires adding another instruction to get it there), and
> because LDM is qu
> Is there any reason not to make ldm the default for armv4 and above,
> since it seems to win most, among the various options?
Because ldm (or ldr) require going via memory.
gcc will already use ldm/ldr in a function return if the function prologue if
the function prologue pushed the return add
On Monday 12 June 2006 22:27, Martin Guy wrote:
> 2006/6/12, Paul Brook <[EMAIL PROTECTED]>:
> > > Am I right in thinking that using just bare LDM means that the distro
> > > will work on v4 and above, but Thumb interworking will only be usable
> > > with AR
On Monday 12 June 2006 18:13, Martin Guy wrote:
> > > Mind u, even on v4t they will probably lose out worse in code size by
> > > having 2 extra instructions in every function than they would ever
> > > gain by interworking with thumb...
> > > so i guess LDM it is. That *does* exist and work on v4[
On Monday 12 June 2006 17:51, Martin Guy wrote:
> 2006/6/12, Martin Guy <[EMAIL PROTECTED]>:
> > recompiling their biggest apps using Thumb until they get within their
> > permitted code size. This is important for v4t because it is currently
> > one of the bulk-market flavours
>
> Mind u, even on
On Monday 12 June 2006 15:19, Catalin Marinas wrote:
> On Mon, 2006-06-12 at 14:16 +0100, Paul Brook wrote:
> > > Martin pointed me to the AemEabiPort wiki page that suggests that the
> > > function return is "tst lr, #1; moveq pc, lr; bx lr" and this wou
> Martin pointed me to the AemEabiPort wiki page that suggests that the
> function return is "tst lr, #1; moveq pc, lr; bx lr" and this would
> work on ARMv4t as well.
>
> However, if the reason for this is to work on StrongARM (which doesn't
> support Thumb, AFAIK) you could ban the Thumb use on A
77 matches
Mail list logo
