Raspberry Pi alignment exceptions

Raspberry Pi is ARMv6, so it supports both alignment exceptions and emulation of old-style rotated loads. At the moment, it appears alignment exceptions are turned on:

Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0x117c968
  ( 138ff38) pc:   e7685c lr:   e76e70 sp:  138ff3c  __write_backtrace()
  ( 138ffa0) pc:   e76a14 lr:   e776c0 sp:  138ffa4  __unixlib_raise_signal()
  ( 138ffb0) pc:   e775c4 lr:   e96268 sp:  138ec68  __h_cback()

  Register dump at 0138ffb4:

    a1: 5395f223 a2:  138ec68 a3:        1 a4:        0
    v1: 5395f240 v2: 5395f223 v3: 5395f208 v4: 5395f222
    v5: 5395f1f8 v6:       1a sl:  138e210 fp:  138eca4
    ip:  138eca8 sp:  138ec68 lr:   e96268 pc:   e8ee20
    cpsr: 20000110

  00e8ee0c : .... : 00000000 : ANDEQ   R0,R0,R0
  00e8ee10 : .... : 00000000 : ANDEQ   R0,R0,R0
  00e8ee14 : .... : 00000000 : ANDEQ   R0,R0,R0
  00e8ee18 : .... : 00000000 : ANDEQ   R0,R0,R0
  00e8ee1c : .... : 00000000 : ANDEQ   R0,R0,R0
  00e8ee20 : .... : e590c000 : LDR     R12,[R0,#0]
  00e8ee24 : .0.. : e3a03001 : MOV     R3,#1
  00e8ee28 : .... : e1a01000 : MOV     R1,R0
  00e8ee2c : .4.. : e1833403 : ORR     R3,R3,R3,LSL #8

  ( 138eca4) pc:   e96210 lr:   e49574 sp:  138eca8  __addenv_to_os()
  ( 138ecc8) pc:   e494e0 lr:   e8d554 sp:  138eccc  putenv()
  ( 138ece4) pc:   1409a8 lr:   e8d554 sp:  138ece8  PR_SetEnv()
  ( 138eff0) pc:     a9d0 lr:   e954d8 sp:  138eff4  XRE_main()

That’s from Firefox, but other programs do similar things.

According to the ARMv6 databook you set bit 22 of CP15 register c1 to enable rotated load emulation. I’ve tried setting this with the routine in the ARMv7 compatibility primer (modified to set or clear bit 22), but it doesn’t seem to make any difference.

Am I missing something?

If memory serves, ARMv6 has two separate control bits, one to turn on or off misaligned access exceptions, the other to switch between the different behaviours when the exceptions are disabled (between ARMv1-ARMv5 behaviour, and ARMv7 behaviour). I don’t know if this helps, I haven’t tried changing any of them…

It turned out that it needs setting bit 22 (emulate rotated load) and clearing bit 1 (disable alignment exceptions), and that did the trick. Firefox now works!

So, a couple of further questions:

• Is it acceptable to ship with alignment emulation turned on (ie keep the ARMv1-5 behaviour). That will ease software compatibility headaches.
• What tool do ARMv7/BeagleBoard folks use to turn alignment exceptions on and off? Is there a GUI?
• Is there an alignment exception API, rather than just poking random CPU registers? There’s now more than two states:
  1. Exceptions on
  2. Exceptions off, rotated loads will fail (ARMv7 behaviour)
  3. Exceptions off, rotated loads will succeed (ARMv1-5 behaviour)

Setting state 3 won’t work on ARMv7, for example, so probably an error should be returned

• What tool do ARMv7/BeagleBoard folks use to turn alignment exceptions on and off? Is there a GUI?

There is a small utility (!AlignEx) written by (I think) Andrew Conroy of Owl-Art. It sits on the iconbar, and the Alignment exception state can be toggled by an adjust click on the icon. It shows the state by red/green ‘traffic lights’. Not at the ARMini at the moment, so I am not sure from where it was originally downloaded.

What tool do ARMv7/BeagleBoard folks use to turn alignment exceptions on and off? Is there a GUI?

I wrote two little BASIC proggies (“AlignOn” and “AlignOff”) that I keep in Library. I just need to remember that bizarre “Abort on data transfer” errors or “Task not known” (!) means that something wants this setting nudged.

BTW, what are the row of fishes?

Is it acceptable to ship with alignment emulation turned on (ie keep the ARMv1-5 behaviour). That will ease software compatibility headaches.

I really think there should be a backwards compatibility section in configure, where all the advances in the system that can break thinks can be turned on and off.
(Preferably with an option on the switcher icon to control things that can be switched on the fly.).

I think this would need to be switchable, even if just to allow Pi software developers to be sure software will also run on a beagle.

not sure from where it was originally downloaded

• AlignEx

BTW, what are the row of fishes?

An aquarium. …Sorry. Sunfish, I think.

They’re part of the evil fish conspiracy. Oops, I shouldn’t have said that, they’ll be after me now.

Otherwise known as double clicking too many times when you can’t see the iconbar (due to the RPi video bug) so have no idea anything has loaded. Sunfish is also something sensitive to alignment issues.

Anyway, is it worth an API to control alignment exceptions given the control is different on different ARMs? The ARM module would be the logical place (does it do anything these days), but it’s quite likely alignment exceptions might want to be set fairly early in the startup process. Could go in the HAL, but not really machine dependent (consider the Risc PC, which has the same HAL but has several different processor options).

What would be really nice would be some way in which applications (and possibly even modules) could indicate whether they want unaligned loads to do a rotated or unaligned load then:

• ARMv3-v5: old applications run with aborts off, new applications run with aborts on (and an abort handler fixes up the load to look like ARMv7)
• ARMv6: all applications run with aborts off, and the load behaviour is switched as necessary
• ARMv7: old applications run with aborts on (and an abort handler fixes up the load to look like ARMv1-v5), new applications run with aborts off

That way, ARMv6 and v7 applications could benefit from what is actually a useful CPU feature.

Chris Gransden made a ARMv7 compatible run file available for sunfish.

when you can’t see the iconbar (due to the RPi video bug)

I thought that was fixed: add “framebuffer_align=0×100000” to your config.txt

I thought that was fixed: add “framebuffer_align=0×100000” to your config.txt

Has been fixed for some time (9th July I think).

Chris Gransden made a ARMv7 compatible run file available for sunfish.

A zip file containing a replacement !RunImage for !Sunfish 2.05 is available here, http://www.cgransden.co.uk/sunfish.zip.

So, given deadlines etc, is there any objection to making the RPi HAL set aborts off, rotated-load behaviour (ie old software should just work)? Any new version of AlignEx and similar is free to meddle with this without needing an API, though a future API might be a useful thing.

So, given deadlines etc, is there any objection to making the RPi HAL set aborts off, rotated-load behaviour (ie old software should just work)?

If we turn aborts off, what’s going to happen when/if the ARMv7 compatibility page gets renamed to the ARMv6/v7 compatibility page? We’ll have lots of people marking things as v6/v7 compatible because they run on the Pi, without realising that they’re only working because rotated loads are enabled.

Maybe we shouldn’t rename that then :-) Are there any ARMv6 cores that don’t have rotated load support? Therefore, is there any reason for ARMv6 not to be equivalent to ARMv5 (ie ‘Iyonix OK’ will suffice)? Is there anything else that ARMv6 users might have to be aware of?

I’m suggesting that for people wanting to test things on a Pi as if they’re on ARMv7, they turn off alignment exceptions and rotated loads (eg via a modified AlignEx). But general users of the Pi get to use the wider catalogue of old software. A snazzy exception handler could even keep a list of where alignment exceptions happened (address &1234 in FooMod) before fixing them up, and then pestering the user what software needs updating.

Are there any ARMv6 cores that don’t have rotated load support?

It was listed in final edition of the old ARM ARM, so applied to the “original” ARMv6 chips as well. The only exception would seem to be ARMv6-M, but since those chips only support Thumb anyway, it’s a moot point.

The advantage of running ARMv6 in ARMv5 mode is compatibility. The advantage of running it in ARMv7 mode is speed (for example, all uses of BASIC’s ! indirection operator perform unaligned 32-bit accesses, which can be done in a single instruction in ARMv7 land, but have to do LDM/STM and a bunch of register shuffles in ARMv5 land).

Is the ARMv7 speed improvement that significant? I assume that software would need to expect this behaviour – ie it then can’t run on ARMv5 or earlier?

Either way, it would be good to have a decision soon. This decision is the start of a long chain of dependencies for packaged software: either ARMv5 compatibility is sufficient, the change goes in the ROM, and we can get on with testing the existing packaged software; or we mandate ARMv7, at which point I need to get recompiling as much as possible that isn’t currently ARMv7 compliant (a nontrivial process), and then have people test it. Would be useful to know :)

I assume that software would need to expect this behaviour – ie it then can’t run on ARMv5 or earlier?

Correct.

This decision is the start of a long chain of dependencies for packaged software: either ARMv5 compatibility is sufficient, the change goes in the ROM, and we can get on with testing the existing packaged software; or we mandate ARMv7, at which point I need to get recompiling as much as possible that isn’t currently ARMv7 compliant (a nontrivial process), and then have people test it. Would be useful to know :)

It’s worth bearing in mind that rotated load/store behaviour isn’t the only thing that can cause compatability issues. In the past I’ve found situations where programs were doing things which weren’t 32bit safe, e.g. LDM {pc}^ from user mode. On an Iyonix this code ran fine, but on a BB it was failing.

I should probably say that for my own selfish reasons I want things to stay in ARMv7 compatible mode, as switching to ARMv5 mode for the Pi won’t help get any programs rebuilt for ARMv7 compatibility. If people want bits of software to run they should pester the author to fix it, that way it benefits users of all machines instead of just users of old machines or ones that can run in a backwards-compatible manner.

Also I do have a prototype module that can emulate the rotated load behaviour. Although it did allow some software to run, it wasn’t enough to get all of it to work, most likely due to the other 32bit compatibility issues I’ve touched on above. So I never put any effort into finishing it off. See here for a bit more info.

I’m suggesting that for people wanting to test things on a Pi as if they’re on ARMv7, they turn off alignment exceptions and rotated loads (eg via a modified AlignEx).

If someone can point me in the direction of some code to turn alignment exceptions on/off etc. for the RPi then I’m happy to look at making a new version of AlignEx if people think this would be a good thing.

If someone can point me in the direction of some code to turn alignment exceptions on/off etc. for the RPi then I’m happy to look at making a new version of AlignEx if people think this would be a good thing.

To turn alignment exceptions on/off you can use exactly the same code that you’re using on the BB.

For controlling whether rotated or unaligned loads are used, you just need to change it to set/clear bit 22 of the register. (bit 22 set = ARMv7 mode, bit 22 clear = ARMv5 mode). Just remember that bit 1 also needs to be clear in order to disable alignment exceptions.

On ARMv7 bit 22 is forced to 1, so you can probably just make AlignEx temporarily clear it and read the value back to see if rotated loads are supported or not (this is a bit easier than trying to detect whether you’re running on ARMv6 or ARMv7, as you’d need to check both the main ID register and the cache type register to do that)

Theo – You need to clear bit 22 to enable rotated loads, not set it.

I’m happy to look at making a new version of AlignEx if people think this would be a good thing.

Yes, please, but could it be a configure plug-in, defaulting to the status quo? (For the reasons Jeffrey gave above.)

Hmm, I’ll need to recheck. The above picture was taken with the code shown – bit 22 set, bit 1 clear. It appears that the default state of bit 22 depends on external inputs. (which probably means was configured during the tapeout of the BCM2835, information we don’t have), and I didn’t check it. But it’s puzzling why Firefox didn’t work in the default ARMv5 state but did when I set bit 22 to 1 (ARMv7 mode).