Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Which port for armv4l?

137 views
Skip to first unread message

Adam Wysocki

unread,
Aug 10, 2016, 9:10:07 AM8/10/16
to
Hi,

I have an old Jornada 720 handheld PC with SA-1110 (StrongARM) CPU. I have
a kernel compiled for armv4l architecture (not by me) and a userland that
I don't want to use.

Instead of this userland I'd prefer to run Debian on this antique, but
I don't know which architecture to choose.

When I tried to execute binaries from armel, they immediately gave me
"Illegal instruction". When I tried to execute binaries from armhf, they
didn't even got recognized by the kernel ("Cannot execute binary file").

Does Debian support this architecture (without recompiling everything)?
Could you advise?

gof@jornada7xx:~$ uname -a
Linux jornada7xx 2.6.25-jlime #1 Wed Jul 16 15:52:07 CEST 2008 armv4l unknown

gof@jornada7xx:~$ cat /proc/cpuinfo
Processor : StrongARM-1110 rev 8 (v4l)
BogoMIPS : 137.21
Features : swp half 26bit fastmult
CPU implementer : 0x69
CPU architecture: 4
CPU variant : 0x0
CPU part : 0xb11
CPU revision : 8

Hardware : HP Jornada 720
Revision : 0000
Serial : 0000000000000000

--
Adam Wysocki
http://www.chmurka.net/

Neil Williams

unread,
Aug 10, 2016, 9:30:02 AM8/10/16
to
On Wed, 10 Aug 2016 15:02:39 +0200 (CEST)
Adam Wysocki <a...@chmurka.net> wrote:

> Hi,
>
> I have an old Jornada 720 handheld PC with SA-1110 (StrongARM) CPU. I
> have a kernel compiled for armv4l architecture (not by me) and a
> userland that I don't want to use.
>
> Instead of this userland I'd prefer to run Debian on this antique,
> but I don't know which architecture to choose.
>
> When I tried to execute binaries from armel, they immediately gave me
> "Illegal instruction". When I tried to execute binaries from armhf,
> they didn't even got recognized by the kernel ("Cannot execute binary
> file").
>
> Does Debian support this architecture (without recompiling
> everything)? Could you advise?
>
> gof@jornada7xx:~$ uname -a
> Linux jornada7xx 2.6.25-jlime #1 Wed Jul 16 15:52:07 CEST 2008 armv4l
> unknown
>
> gof@jornada7xx:~$ cat /proc/cpuinfo
> Processor : StrongARM-1110 rev 8 (v4l)

https://en.wikipedia.org/wiki/StrongARM

The last Debian release using StrongARM was 5.0 "Lenny" - using the
original 'arm' port.
https://www.debian.org/releases/lenny/

ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.2.0,
dynamically linked (uses shared libs), for GNU/Linux 2.2.0, stripped

After Lenny, 'armel' became available (and is still built, for now at
least) - it is armv4t only.

ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.4.17,
dynamically linked (uses shared libs), for GNU/Linux 2.4.17, stripped

https://wiki.debian.org/ArmEabiPort

https://wiki.debian.org/ArmPorts

> BogoMIPS : 137.21
> Features : swp half 26bit fastmult
> CPU implementer : 0x69
> CPU architecture: 4
> CPU variant : 0x0
> CPU part : 0xb11
> CPU revision : 8
>
> Hardware : HP Jornada 720
> Revision : 0000
> Serial : 0000000000000000
>
> --
> Adam Wysocki
> http://www.chmurka.net/
>


--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Wookey

unread,
Aug 10, 2016, 10:40:02 AM8/10/16
to
On 2016-08-10 14:28 +0100, Neil Williams wrote:
> On Wed, 10 Aug 2016 15:02:39 +0200 (CEST)
> Adam Wysocki <a...@chmurka.net> wrote:
>
> > Hi,
> >
> > I have an old Jornada 720 handheld PC with SA-1110 (StrongARM) CPU. I
> > have a kernel compiled for armv4l architecture (not by me) and a
> > userland that I don't want to use.
>
> The last Debian release using StrongARM was 5.0 "Lenny" - using the
> original 'arm' port.
> https://www.debian.org/releases/lenny/

There is a recent kernel patch which can be applied to trap the missing
instructions on Strongarm so that one should be able to run current
armel (probably rather slowly). I have not actually tested it, and I
don't know if it's been mainlined (probably not).

Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc

Stefan Monnier

unread,
Aug 10, 2016, 11:10:02 AM8/10/16
to
>> > I have an old Jornada 720 handheld PC with SA-1110 (StrongARM) CPU. I
>> > have a kernel compiled for armv4l architecture (not by me) and a
>> > userland that I don't want to use.
>> The last Debian release using StrongARM was 5.0 "Lenny" - using the
>> original 'arm' port.
>> https://www.debian.org/releases/lenny/
> There is a recent kernel patch which can be applied to trap the missing
> instructions on Strongarm so that one should be able to run current
> armel (probably rather slowly). I have not actually tested it, and I
> don't know if it's been mainlined (probably not).

Reminds me that I wish there was some kind of "Debian from Source"
effort which would make it easy to install specific packages by
compiling them locally. So you'd get a slightly Gentoo-ish flavor
of Debian.

In the above situation, you could then recompile locally the few
packages whose performance matters such that they stick to armv4l
instructions and hence avoid the slow emulation trap.


Stefan

Paul Wise

unread,
Aug 10, 2016, 11:30:02 AM8/10/16
to
On Wed, Aug 10, 2016 at 11:04 PM, Stefan Monnier wrote:

> Reminds me that I wish there was some kind of "Debian from Source"
> effort which would make it easy to install specific packages by
> compiling them locally. So you'd get a slightly Gentoo-ish flavor
> of Debian.

Are you talking about something like this?

https://wiki.debian.org/HelmutGrohne/rebootstrap

> In the above situation, you could then recompile locally the few
> packages whose performance matters such that they stick to armv4l
> instructions and hence avoid the slow emulation trap.

That should be easy to do now if you have the right toolchain.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Stefan Monnier

unread,
Aug 10, 2016, 12:00:02 PM8/10/16
to
>> Reminds me that I wish there was some kind of "Debian from Source"
>> effort which would make it easy to install specific packages by
>> compiling them locally. So you'd get a slightly Gentoo-ish flavor
>> of Debian.
> Are you talking about something like this?
> https://wiki.debian.org/HelmutGrohne/rebootstrap

I was thinking more about locally compiling *some* package rather than
doing the full bootstrap, but yes, that's also part of the idea.

>> In the above situation, you could then recompile locally the few
>> packages whose performance matters such that they stick to armv4l
>> instructions and hence avoid the slow emulation trap.
> That should be easy to do now if you have the right toolchain.

Hmm... indeed I now see that "apt-get -b source <packagename>" should
build that package for me.

I guess all I'm still missing is some community of tweakers adding
facilities to set global compilation flags to use for all those
recompiled packages and things like that, so you don't have to do it by
hand for each and every package you want to recompile with your
own compilation flags.


Stefan

Paul Wise

unread,
Aug 10, 2016, 12:30:02 PM8/10/16
to
On Wed, Aug 10, 2016 at 11:55 PM, Stefan Monnier wrote:

> I guess all I'm still missing is some community of tweakers adding
> facilities to set global compilation flags to use for all those
> recompiled packages and things like that, so you don't have to do it by
> hand for each and every package you want to recompile with your
> own compilation flags.

See the dpkg-buildflags manual page. Most packages should pay
attention to it and if they don't then it is a bug.

I get the feeling you are talking about build configuration flags
rather than compiler flags though?

Stefan Monnier

unread,
Aug 10, 2016, 1:00:03 PM8/10/16
to
>> I guess all I'm still missing is some community of tweakers adding
>> facilities to set global compilation flags to use for all those
>> recompiled packages and things like that, so you don't have to do it by
>> hand for each and every package you want to recompile with your
>> own compilation flags.
> See the dpkg-buildflags manual page. Most packages should pay
> attention to it and if they don't then it is a bug.

Hah! Sounds like just what is needed!

So in the OP's case, it seems that installing Debian with a kernel that
emulates the missing instructions, is all it takes to get a working
system, and then you can:
- tweak /etc/dpkg/buildflags.conf to tell the
compiler to optimize for the armv4l architecture
- use "apt-get -b source <packages>" to rebuild the
performance-sensitive packages with those flags.
- then I guess you'd use dpkg to actually install those packages.

Hmm... I guess you'd still suffer from performance problems when your
locally-compiled packages get updated by "apt-get upgrade" and hence
replacing your tuned packages with the stock precompiled ones.
So I guess for the sun to shine we'd want some way to flag some packages
as "always install from source" or something like that.


Stefan

Jeffrey Walton

unread,
Aug 10, 2016, 1:10:02 PM8/10/16
to
> Hmm... I guess you'd still suffer from performance problems when your
> locally-compiled packages get updated by "apt-get upgrade" and hence
> replacing your tuned packages with the stock precompiled ones.
> So I guess for the sun to shine we'd want some way to flag some packages
> as "always install from source" or something like that.

I'm guessing (and its purely a guess), the replace-local-package
problem can be side-stepped blocking the distro's packages. Something
like https://superuser.com/questions/812253/permanently-block-distro-package-installation
.

Jeff

Wookey

unread,
Aug 10, 2016, 2:00:03 PM8/10/16
to
On 2016-08-10 12:54 -0400, Stefan Monnier wrote:
>
> So in the OP's case, it seems that installing Debian with a kernel that
> emulates the missing instructions, is all it takes to get a working
> system, and then you can:
> - tweak /etc/dpkg/buildflags.conf to tell the
> compiler to optimize for the armv4l architecture
> - use "apt-get -b source <packages>" to rebuild the
> performance-sensitive packages with those flags.
> - then I guess you'd use dpkg to actually install those packages.

In principle this would work fine. But if it worked then debian armel
would already be built this way (we didn't _want_ to drop strongARM
support). The problem is that the compiler, when outputting code for
EABI (armel), does not support armv4, (due to boring stuff about thumb
interworking, atomics and the BX instruction). It's all documented
somewhere, probably in the those links that NeilW sent.

So in practice, you need to use the 'BX emulation' kernel patch
instead. I checked with the author (Marc Zyngier) this afternoon, and
apparently it works very well, but it is indeed not upstreamed
(rejected). (And I don't have a link to hand)
signature.asc

Adam Wysocki

unread,
Aug 11, 2016, 6:30:02 AM8/11/16
to
On Wed, 10 Aug 2016, Wookey wrote:

> So in practice, you need to use the 'BX emulation' kernel patch
> instead. I checked with the author (Marc Zyngier) this afternoon, and
> apparently it works very well, but it is indeed not upstreamed
> (rejected). (And I don't have a link to hand)

Thank you for all responses!

Wookey

unread,
Aug 11, 2016, 7:20:01 AM8/11/16
to
here it is:
https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/log/?h=arm/netwinder
signature.asc

Stefan Monnier

unread,
Aug 11, 2016, 9:30:02 AM8/11/16
to
> In principle this would work fine. But if it worked then debian armel
> would already be built this way (we didn't _want_ to drop strongARM
> support). The problem is that the compiler, when outputting code for
> EABI (armel), does not support armv4, (due to boring stuff about thumb
> interworking, atomics and the BX instruction). It's all documented
> somewhere, probably in the those links that NeilW sent.

In the OP's case it might indeed be a problem. But I'm interested in
the more general case of catering to Gentoo-ish desires to compile
specific packages with particular flags/options.


Stefan

Adam Wysocki

unread,
Aug 11, 2016, 10:10:03 AM8/11/16
to
On Thu, 11 Aug 2016, Wookey wrote:

> here it is:
> https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/log/?h=arm/netwinder

I see it's still being developed... is it stable enough?

Wookey

unread,
Aug 11, 2016, 10:50:01 AM8/11/16
to
Marc said it was working well on his netwinder, even doing exotic
things like testing with qemu and kvm.

I don't suppose there are many other users as not many people care
about this any more, and it's quite new.

I plan to test it on my netwinder and balloonboard so I can upgrade
them past '8 years ago', at some point, but it's hardly the most
urgent thing I have to do :-)
signature.asc

Adam Wysocki

unread,
Aug 12, 2016, 5:00:04 AM8/12/16
to
On Thu, 11 Aug 2016, Wookey wrote:

> > > here it is:
> > > https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/log/?h=arm/netwinder
> >
> > I see it's still being developed... is it stable enough?
>
> Marc said it was working well on his netwinder, even doing exotic
> things like testing with qemu and kvm.

I see.

Maybe it's a stupid and offtopic question, but how to download it? I tried
git clone -b arm/netwinder https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
but it downloaded whole 4.8.0-rc1 kernel tree. I'd prefer to apply this
as a patch to 4.7.0...

> I plan to test it on my netwinder and balloonboard so I can upgrade
> them past '8 years ago', at some point, but it's hardly the most
> urgent thing I have to do :-)

That's understandable :)

Wookey

unread,
Aug 12, 2016, 5:50:02 AM8/12/16
to
On 2016-08-12 10:52 +0200, Adam Wysocki wrote:
> On Thu, 11 Aug 2016, Wookey wrote:
>
> > > > here it is:
> > > > https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/log/?h=arm/netwinder
> > >
> > > I see it's still being developed... is it stable enough?
> >
> > Marc said it was working well on his netwinder, even doing exotic
> > things like testing with qemu and kvm.
>
> I see.
>
> Maybe it's a stupid and offtopic question, but how to download it? I tried
> git clone -b arm/netwinder https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
> but it downloaded whole 4.8.0-rc1 kernel tree. I'd prefer to apply this
> as a patch to 4.7.0...

You want this commit:
https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm/netwinder&id=6d833b52d0591b47ee65ef2808c459a99f1d37ec

or if you want the alternative (faster) dynamic translation option, these 2:
https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm/netwinder&id=72797818a31d37a7ec28db659afcab0a56d47968
https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm/netwinder&id=ad13b838db8f3474393298963da73c6f2095739a

I expect they work on 4.7 too, but I've not looked at all.
signature.asc

Adam Wysocki

unread,
Aug 12, 2016, 11:20:02 AM8/12/16
to
On Fri, 12 Aug 2016, Wookey wrote:

> > Maybe it's a stupid and offtopic question, but how to download it? I tried
> > git clone -b arm/netwinder https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
> > but it downloaded whole 4.8.0-rc1 kernel tree. I'd prefer to apply this
> > as a patch to 4.7.0...
>
> You want this commit:
> https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm/netwinder&id=6d833b52d0591b47ee65ef2808c459a99f1d37ec

Thanks, I downloaded it and patched 4.7 seamlessly. I have some problems
compiling the kernel, but it might be related to my old gcc (3.4.5).
Debian has packaged arm-none-eabi-gcc 4.8.4, should it work? I want to
avoid building my own toolchain...

> or if you want the alternative (faster) dynamic translation option, these 2:
> https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm/netwinder&id=72797818a31d37a7ec28db659afcab0a56d47968
> https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm/netwinder&id=ad13b838db8f3474393298963da73c6f2095739a

This code is pure magic :)

Thanks Wookey!

Wookey

unread,
Aug 12, 2016, 11:30:02 AM8/12/16
to
On 2016-08-12 16:44 +0200, Adam Wysocki wrote:
> On Fri, 12 Aug 2016, Wookey wrote:
>
> > > Maybe it's a stupid and offtopic question, but how to download it? I tried
> > > git clone -b arm/netwinder https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
> > > but it downloaded whole 4.8.0-rc1 kernel tree. I'd prefer to apply this
> > > as a patch to 4.7.0...
> >
> > You want this commit:
> > https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm/netwinder&id=6d833b52d0591b47ee65ef2808c459a99f1d37ec
>
> Thanks, I downloaded it and patched 4.7 seamlessly. I have some problems
> compiling the kernel, but it might be related to my old gcc (3.4.5).
> Debian has packaged arm-none-eabi-gcc 4.8.4, should it work? I want to
> avoid building my own toolchain...

You mean your native gcc on the old arm machine is 3.4.5? So you are
pondering cross-building? arm-none-eabi-gcc is intended for embedded
targets. You want gcc-*-arm-linux-gnueabi

Info on installing cross-toolchains is here:
https://wiki.debian.org/CrossToolchains
(somewhat out of date as ever, but it's a good start)
This is easier in stretch as gcc-5* in in the archive.
On Jessie you need to use an external archive.

> > or if you want the alternative (faster) dynamic translation option, these 2:
> > https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm/netwinder&id=72797818a31d37a7ec28db659afcab0a56d47968
> > https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=arm/netwinder&id=ad13b838db8f3474393298963da73c6f2095739a
>
> This code is pure magic :)
>
> Thanks Wookey!
>
> --
> Adam Wysocki
> http://www.chmurka.net/
>
signature.asc

Adam Wysocki

unread,
Aug 16, 2016, 5:50:03 PM8/16/16
to
On Fri, 12 Aug 2016, Wookey wrote:

> > Thanks, I downloaded it and patched 4.7 seamlessly. I have some problems
> > compiling the kernel, but it might be related to my old gcc (3.4.5).
> > Debian has packaged arm-none-eabi-gcc 4.8.4, should it work? I want to
> > avoid building my own toolchain...
>
> You mean your native gcc on the old arm machine is 3.4.5?

Nope, I don't have a native gcc there, I grabbed some old toolchain from
the net.

> targets. You want gcc-*-arm-linux-gnueabi
>
> Info on installing cross-toolchains is here:
> https://wiki.debian.org/CrossToolchains

Thanks, I installed it:

$ arm-linux-gnueabi-gcc-4.9 --version
arm-linux-gnueabi-gcc-4.9 ( 4.9.2-10) 4.9.2

I tested it with a small test program and it generates code with BX
instruction (and other BXxx instructions, which - judging from the code -
don't seem to be emulated by patch - aren't they needed?).

$ cat test.c
int main() { return 0; }
$ arm-linux-gnueabi-gcc-4.9 -S -o test.S test.c
$ arm-linux-gnueabi-gcc-4.9 -c -o test.o test.c
$ arm-linux-gnueabi-gcc-4.9 -o test.elf test.c
$ grep bx test.S
bx lr
$ arm-linux-gnueabi-objdump -d test.o|grep 12fff1
18: e12fff1e bx lr
$ arm-linux-gnueabi-objdump -d test.elf|grep 12fff1
10280: e12fff1e bx lr
1030c: 012fff1e bxeq lr
1032c: 912fff1e bxls lr
10338: 012fff1e bxeq lr
1033c: e12fff13 bx r3
10364: 012fff1e bxeq lr
10370: 012fff1e bxeq lr
10374: e12fff13 bx r3
103a8: e12fff1e bx lr
103dc: e12fff13 bx r3
10404: e12fff1e bx lr
10458: e12fff13 bx r3
10468: e12fff1e bx lr
10474: e12fff1e bx lr
10480: e12fff1e bx lr

Shouldn't it generate code without these instructions?

Anyway, I compiled the kernel (4.7):

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig zImage

and it seems that resulting image doesn't contain BX instructions, but it
doesn't boot - the screen is blank with one horizontal line (probably
because CPU doesn't control display refreshing as it normally does) and
the serial port doesn't work - I tested with earlyprintk= and console=
kernel parameters and all I get is the jlinexec.exe (bootloader for WinCE
that loads Linux) "logo" line on the serial port...

Maybe I configured the kernel wrong, but I enabled everything that should
probably be enabled (SA1100 console, SA1100 serial port, CPU type etc)...

$ grep SA1100 .config
CONFIG_ARCH_SA1100=y
# CONFIG_SA1100_ASSABET is not set
# CONFIG_SA1100_CERF is not set
# CONFIG_SA1100_COLLIE is not set
# CONFIG_SA1100_H3100 is not set
# CONFIG_SA1100_H3600 is not set
# CONFIG_SA1100_BADGE4 is not set
CONFIG_SA1100_JORNADA720=y
CONFIG_SA1100_JORNADA720_SSP=y
# CONFIG_SA1100_HACKKIT is not set
# CONFIG_SA1100_LART is not set
# CONFIG_SA1100_NANOENGINE is not set
# CONFIG_SA1100_PLEB is not set
# CONFIG_SA1100_SHANNON is not set
# CONFIG_SA1100_SIMPAD is not set
CONFIG_SA1100_SSP=y
CONFIG_CPU_SA1100=y
CONFIG_PCMCIA_SA1100=m
CONFIG_SA1100_FIR=y
CONFIG_SERIAL_SA1100=y
CONFIG_SERIAL_SA1100_CONSOLE=y
CONFIG_SA1100_WATCHDOG=y
CONFIG_FB_SA1100=y
CONFIG_RTC_DRV_SA1100=y

I'll try to revise the kernel config tomorrow.

Adam Wysocki

unread,
Aug 16, 2016, 6:20:02 PM8/16/16
to
On Tue, 16 Aug 2016, Adam Wysocki wrote:

> I tested it with a small test program and it generates code with BX
> instruction (and other BXxx instructions, which - judging from the code -
> don't seem to be emulated by patch - aren't they needed?).

Also a small question about BX emulation. Maybe it's a silly question,
because I don't know much about Thumb, but I googled that the least
significant bit of the branch address determines the state (whether
execution continues in ARM state or Thumb state).

What will happen if the code tries to enter Thumb state with BX and the
patch just sets the PC to the odd address (with bit0=1)? An exception, as
PC can't be odd?

Shouldn't the patch handle addresses with bit0=1 differently?

Tixy

unread,
Aug 17, 2016, 2:30:02 AM8/17/16
to
On Wed, 2016-08-17 at 00:18 +0200, Adam Wysocki wrote:
> On Tue, 16 Aug 2016, Adam Wysocki wrote:
>
> > I tested it with a small test program and it generates code with BX
> > instruction (and other BXxx instructions, which - judging from the code -
> > don't seem to be emulated by patch - aren't they needed?).

BX is the only ARM state instruction on ARMv4 that exists for Thumb
interworking.

> Also a small question about BX emulation. Maybe it's a silly question,
> because I don't know much about Thumb, but I googled that the least
> significant bit of the branch address determines the state (whether
> execution continues in ARM state or Thumb state).
>
> What will happen if the code tries to enter Thumb state with BX and the
> patch just sets the PC to the odd address (with bit0=1)? An exception, as
> PC can't be odd?

Why would the code be trying to enter Thumb state if it isn't compiled
for Thumb? Anyway, the bit will be ignored on old architectures without
Thumb support. Indeed, even with Thumb support, BX was the only way to
switch to Thumb on ARMv4. It was ARMv5 that added support for things
like LDM and LDR to change state.

> Shouldn't the patch handle addresses with bit0=1 differently?

I haven't looked at the patch so don't see what it does, but if a system
is ARMv4 then trying to load PC with an odd number is fine, that bit
will be ignored and appear as zero if you look at PC. (Likely hardware
doesn't even exist to store bit0 of PC)

--
Tixy

Adam Wysocki

unread,
Aug 17, 2016, 5:20:02 AM8/17/16
to
On Wed, 17 Aug 2016, Tixy wrote:

> BX is the only ARM state instruction on ARMv4 that exists for Thumb
> interworking.

What about other (conditional) branch exchange instructions (BXCC, BXNE
etc.)?

> Why would the code be trying to enter Thumb state if it isn't compiled
> for Thumb?

Is it possible for a compiler to generate BX instructions without Thumb
code (for example to return from a function with bx lr, where lr will
always be even - no Thumb)?

Correct me if I'm wrong, but I thought that BX patch (to emulate BX
instruction in kernel) was supposed to allow running code with BX
instructions on a processor that lacks it, and that's why I want to use it
(to run Debian for armel on StrongARM SA-1100, which has ARMv4 core, so
without Thumb). Code in Debian for armel architecture doesn't use Thumb?

> > Shouldn't the patch handle addresses with bit0=1 differently?
>
> I haven't looked at the patch so don't see what it does,

It just copies contents of the register specified in the last nibble of
the instruction to PC.

int reg = instr & 0xf;
regs->ARM_pc = regs->uregs[reg];

Tixy

unread,
Aug 17, 2016, 7:10:01 AM8/17/16
to
On Wed, 2016-08-17 at 11:19 +0200, Adam Wysocki wrote:
> On Wed, 17 Aug 2016, Tixy wrote:
>
> > BX is the only ARM state instruction on ARMv4 that exists for Thumb
> > interworking.
>
> What about other (conditional) branch exchange instructions (BXCC, BXNE
> etc.)?

That's a BX instruction with condition checks, I was treating that as
the same instruction (all older ARM instructions supported conditional
execution, it's the top 4 bits of the instruction encoding).

>
> > Why would the code be trying to enter Thumb state if it isn't compiled
> > for Thumb?
>
> Is it possible for a compiler to generate BX instructions without Thumb
> code (for example to return from a function with bx lr, where lr will
> always be even - no Thumb)?

I believe so. If my memory serves me "BX reg" was recommended over "MOV
PC,reg" so binaries built for ARM4T would likely use it even when they
are built for ARM code rather than Thumb. (It makes sense as it means
that code can be interwork happily with binaries built using Thumb
instructions)

> Correct me if I'm wrong, but I thought that BX patch (to emulate BX
> instruction in kernel) was supposed to allow running code with BX
> instructions on a processor that lacks it, and that's why I want to use it
> (to run Debian for armel on StrongARM SA-1100, which has ARMv4 core, so
> without Thumb). Code in Debian for armel architecture doesn't use Thumb?

Correct. I run armel on ARMv5 devices that doesn't have Thumb (Marvel
Kirkwood SoCs) though it does have support for BX (which was added to
ARMv5 as a mandatory instruction even if Thumb is not supported).

> > > Shouldn't the patch handle addresses with bit0=1 differently?
> >
> > I haven't looked at the patch so don't see what it does,

I have looked now.

> It just copies contents of the register specified in the last nibble of
> the instruction to PC.
>
> int reg = instr & 0xf;
> regs->ARM_pc = regs->uregs[reg];

Yes, and when the exception returns, the register values will be
restored from that 'regs' structure. This will use an LDM (load
multiple) instruction and the fact that PC has bit zero set or not won't
matter on ARM4 devices (even ARM4T devices). And anyway, if the binary
is compiled for ARM code not Thumb it won't be calling BX to load a
value with bit 0 set anyway, because on ARM4T CPUs that would switch to
Thumb mode and things would go horribly wrong if the binaries in the
system were build for ARM not Thumb.

--
Tixy

Adam Wysocki

unread,
Aug 17, 2016, 8:40:03 AM8/17/16
to
On Wed, 17 Aug 2016, Tixy wrote:

> > What about other (conditional) branch exchange instructions (BXCC, BXNE
> > etc.)?
>
> That's a BX instruction with condition checks, I was treating that as
> the same instruction (all older ARM instructions supported conditional
> execution, it's the top 4 bits of the instruction encoding).

So first 4 bits are examined before actual decoding of the instruction and
if the condition is not met, then the instruction is ignored and no
exception is raised? Smart...

I see that the patch catches instructions with all conditions and all
registers (x1 2F FF 1x)... now it makes sense.

> Correct. I run armel on ARMv5 devices that doesn't have Thumb (Marvel
> Kirkwood SoCs) though it does have support for BX (which was added to
> ARMv5 as a mandatory instruction even if Thumb is not supported).

I see...

> Yes, and when the exception returns, the register values will be
> restored from that 'regs' structure. This will use an LDM (load
> multiple) instruction and the fact that PC has bit zero set or not won't
> matter on ARM4 devices (even ARM4T devices). And anyway, if the binary
> is compiled for ARM code not Thumb it won't be calling BX to load a
> value with bit 0 set anyway, because on ARM4T CPUs that would switch to
> Thumb mode and things would go horribly wrong if the binaries in the
> system were build for ARM not Thumb.

So the only difference preventing armel from running on StrongARM (without
the kernel patch) is the lack of BX instruction? What is the gain of losing
this backward compatibility?

You wrote that:

> I believe so. If my memory serves me "BX reg" was recommended over "MOV
> PC,reg" so binaries built for ARM4T would likely use it even when they
> are built for ARM code rather than Thumb. (It makes sense as it means
> that code can be interwork happily with binaries built using Thumb
> instructions)

I don't see why using MOV PC,reg would prevent interworking with binaries
built using Thumb, as this code executes in ARM state anyway... it could
use BX only to switch to Thumb (and when it doesn't use Thumb at all, it
would never use it)...

Anyway, now I have some more problems with the machine (I wanted to try
the new kernel, but after driving to work today with Jornada in my
backpack it suddenly stopped booting even WinCE - it booted yesterday
evening), so I'll have to try to fix that first...

Thank you!

Tixy

unread,
Aug 17, 2016, 10:50:02 AM8/17/16
to
On Wed, 2016-08-17 at 14:34 +0200, Adam Wysocki wrote:
[...]
> I don't see why using MOV PC,reg would prevent interworking with binaries
> built using Thumb, as this code executes in ARM state anyway... it could
> use BX only to switch to Thumb (and when it doesn't use Thumb at all, it
> would never use it)...

If ARM code is called from Thumb code, it must return using something
like BX LR. Mov PC, LR won't return to Thumb mode. E.g.


/* Thumb code... */
BLX func


/* ARM code... */
BL func
...

func:
...
BX LR

The above 'func' can be called OK from both the ARM and Thumb state. If
it returned with MOV PC, LR instead, then when called from Thumb it
wouldn't work (for ARMv6 and earlier that is - ARMv7 changed behaviour
of MOV and similar).

Of course, ARM4T has original Thumb not Thumb-2, so doesn't have BLX.
Instead, it would have some trampoline code which uses BX. (It's been
almost 20 years since I worked on ARM4T systems, and memory is a bit
fuzzy as to details, though I do remember that it was a complete pain in
the arse. :-)

--
Tixy

peter green

unread,
Aug 17, 2016, 5:20:02 PM8/17/16
to
On 17/08/16 10:19, Adam Wysocki wrote:
>
> Is it possible for a compiler to generate BX instructions without Thumb
> code (for example to return from a function with bx lr, where lr will
> always be even - no Thumb)?
>
> Correct me if I'm wrong, but I thought that BX patch (to emulate BX
> instruction in kernel) was supposed to allow running code with BX
> instructions on a processor that lacks it, and that's why I want to use it
> (to run Debian for armel on StrongARM SA-1100, which has ARMv4 core, so
> without Thumb). Code in Debian for armel architecture doesn't use Thumb?
>
Unless explicitly told otherwise the compilers in Debian armel build arm mode code. I don't think there is anything forbidding packagers from chosing thumb mode for their code but they would have to go out of their way to make that choice and i'm not aware of anyone doing so.

However the compiler doesn't know whether you will be mixing the arm code it built with thumb code built with another compiler invocation. So it uses BX for function calls and returns.

Adam Wysocki

unread,
Aug 18, 2016, 3:30:02 AM8/18/16
to
On Wed, 17 Aug 2016, peter green wrote:

> However the compiler doesn't know whether you will be mixing the arm code it
> built with thumb code built with another compiler invocation. So it uses BX
> for function calls and returns.

Hmm, so it uses BX LR just in case LR has bit 0 set (to return to Thumb
code)?
0 new messages