Rebuilding Software for BeagleBoard

Hello, I have been working with Andrew Sellors, the author of !RDPClient for RISC OS. We have been trying to update !RDPClient to run on the Beagle Board.

Andrew has sent me some questions regarding updating software to run on the OMAP release of RISC OS Open. Could someone with more experience than myself please answer his questions.

1) Specific to the Beagleboard, are there any ARM asembler changes needed for applications to support the A8 Cortex processor over that of the Iyonix for example?

2) What’s wrong with this assembler code?

MOV     ip, lr

STR     a1, [a2, #0]
SWI     SWI_Wimp_GetWindowState + XOS_Bit
MOVVC   a1, #0

MOVS    pc, ip

a1 (r0) contains the window handle

a2 (r1) points to a memory buffer

Calling this from C causes an abort on instruction fetch error on the Beagleboard but works OK on other machines. Calling the same SWI using the _kernel_swi() function works fine on the Beagleboard.

3) Are there any changes to SWI calls in the latest RISC OS OPEN version which are incompatible with older versions of RISC OS (such as returning data in buffers with more information than previously and so requiring a larger memory allocation)? My application is getting an:

• unrecoverable error in run time system: free failed

error when running on the Beagleboard where as it works fine on other 32bit machines.

Many Thanks, Rob.

1) Specific to the Beagleboard, are there any ARM asembler changes needed for applications to support the A8 Cortex processor over that of the Iyonix for example?

The main thing is that LDR, STR, LDM and STM to/from addresses which aren’t word aligned should be avoided. Similarly, LDRH/STRH to/from addresses which aren’t halfword-aligned should also be avoided. For the full details of what’s changed, see this post. But basically the behaviour of the unaligned load/store is now different to what it used to be, which causes problems because for a long time both Norcroft and GCC produced code which relied on the “old” behaviour. This is why builds now have alignment exceptions turned on by default – it’s much better for code to fail immediately than to silently fail later on, or to corrupt all the files on your disc without your knowledge.

I think that’s the only change you need to worry about – but be aware that there’s also code like this in the kernel that I’ve had to fix because it failed in unexpected ways on ARMv7. It’ll take a bit of digging for me to find an explanation in the ARM ARM for why the original code would worked on ARMv5 but failed on ARMv7.

2) What’s wrong with this assembler code?

Assuming the code runs in user mode, it will almost certainly be the MOVS pc, ip. In theory the code shouldn’t even work on an Iyonix, because for processors running in 32bit mode, and running in user mode, it has unpredictable behaviour (It attempts to restore the PSR from the mode-specific SPSR register. But in user mode, there is no SPSR register). I can’t be bothered digging through the CVS logs to find out, but I’m fairly certain I’ve fixed identical bugs in RISC OS - so it looks like the unpredictable behaviour has changed from benign in ARMv5 to malevolent in ARMv7.

3) Are there any changes to SWI calls in the latest RISC OS OPEN version which are incompatible with older versions of RISC OS (such as returning data in buffers with more information than previously and so requiring a larger memory allocation)?

Not that I’m aware of. However, make sure that your compiler isn’t producing code that uses unaligned loads/stores. For Norcroft, you need to use the memaccess option, like so: ’-memaccess -L22-S22-L41’. This is the default setting for new copies of Norcroft (ROOL will presumably be able to tell us which version number), but obviously needs specifying manually for older ones.

If you’re using GCC, the best advice is to switch to the latest version (4.1.1 release 2). If you’re still using GCC 3.x then you might run into problems – I haven’t seen any immediate documentation for an option to prevent the use of unaligned loads/stores.

Right… now for me to write this all up on a nice wiki page so I don’t have to keep typing it out again every few weeks ;)

Many Thanks Jeffrey. I’ll pass this information along to Andrew.

3) Are there any changes to SWI calls in the latest RISC OS OPEN version which are incompatible with older versions of RISC OS (such as returning data in buffers with more information than previously and so requiring a larger memory allocation)?

This is absolutely not what ROOL would do with a RISC OS SWI. All changes we make to APIs such as SWIs will be backwards-compatible. We’re not in the habit of making arbitrary changes of that sort which simply cause problems for developers. If an API needs to change, we will try to make that happen by adding to it rather than changing previously documented behaviour.

Having said that, there is a limit to just how backwards we want to be compatible which is a subject I’m sure could be debated for a long time. For example, some SWIs became unusable on the IYONIX because they simply didn’t work in a 32-bit contect (e.g. OS_ReadLine). Rather than simply hacking around at the SWI’s documented behaviour, a new OS_ReadLine32 SWI call was introduced which should be used in preference.

Thus, a caller can do (in pseudo code):

err = swix(OS_ReadLine32, ...);
if (err.errNum == UnknownSWIError)
  err = swix(OS_ReadLine, ...);

Wiki page is here. At the moment it’s linked to from the main Cortex-A8 page and from the software compatibility page, but I guess it would be nice if we could eventually find somewhere for it within the PRM (along with somewhere to cover 26bit vs. 32bit compatibility issues).

Steve: Can you fill in the version number of Norcroft that started using the correct -memaccess option? Cheers.

Also, if anyone with sufficient technical knowledge could give the page a readthrough and point out/correct any mistakes (and add any missing incompatibilities) then that would be appreciated :)

Jeffrey – it is cc 5.68 which changes the default behaviour for code generation to be ARMv7 safe.

Cheers!

I’ve done some updates, and given it a news entry on riscos.info.

The important thing about old versions of GCC is that even if they could be persuaded to generate the correct code, its UnixLib and possibly other bits (including the native compiler itself) would not have the fixes. Apart from that, there are many fixes in UnixLib from the 3.4 series which means we strongly urge upgrading in any case.

I’ve just done another couple of updates myself. In particular, the addition of “MOV pc, lr” (which was the cause of that problem I linked to earlier), and of “LDM reg!,{..reg..}” (which is now entirely unpredictable, instead of just resulting in an unpredictable value of reg).

As far as I know that’s all the problems there are which need to be covered.

While we’re at it, can we please disable the ability to read from low memory on BeagleBoard (if it’s not already disabled), ideally the lower 32K, but this might not be immediately possible – bottom 1K is a good start.

I still urgently want this done for RISC OS in general, but at least if we’re looking at code for BB anyway, this means we can look at fixing naughty low-memory accessing programs at the same time.

I think that increasing protection of, or entirely removing, the first page of RAM is definitely on the todo list somewhere. But you may have to wait for ROOL (or someone new) to do it, since at the moment it’s a lower priority for me than getting the OMAP3 stuff semi-finished.

There are only a handful of variables in the first 4K of RAM which the kernel exposes to the rest of the OS, so if we were to relocate the page to a different address then I think most of the battle would just be in getting the kernel to behave itself (i.e. finding all the bits that load the value 0 into a register instead of using the ZeroPage constant).

are there active projects that are being rebuilt for ARMv7 compatibility?

I just tried the latest !Netsurf but can’t get it to work on the beagleboard using the latest SVN ROM build. My beagleboard is slowly becoming my main RISC OS workhorse and I would love to see more apps becoming compatible with this new platform.

!Netsurf stopped working for me too. Maybe something broke when the resolver module was rebuilt for Armv7?

apparently the squash module in the weekly CVS package for the OMAP is the old one. replacing it with the newer squash module fixed my !Netsurf errors.

Thanks. Looks like the IOMD and OMAP builds need separate versions.

What on earth does NetSurf use Squash for? JM-B was quite adamant that nothing in the binary was compressed due to licence issues…

nothing in the binary is compressed. Apparently something GUI related that it tries to open is.

What on earth does NetSurf use Squash for?

Theme files.

JM-B was quite adamant that nothing in the binary was compressed due to licence issues…

Do not confuse Squash (a module which is part of the OS) with squeeze (an application, which is not part of the OS)

I’m running a OMAP ROM build from the CVS source as it was at 9am today, still seems the Squash module is the old one, can some kind soul please point me in the direction of the new Squash module, so I can run NetSurf again.

Thanks.

Hi Rob, An intermediate solution is to get the module from CVS. Copy it to the beagleboard and double click it there.

Hi Jan, I tried using this module, but still get the same problem. Is that the correct one?

you need the version before that one. somehow the changes made to the last version broke it on the OMAP

Aha! Got it! If anyone else needs it, you can get it Here

Cheers Jan!

Thanks. Looks like the IOMD and OMAP builds need separate versions.

The new version of the module was intended to the compatible with all architecture versions, but obviously that isn’t the case :(

I’ve let ROOL know what the problem is (a missing BIC that was clearing the bottom to bits of an address being fed to an LDM), so hopefully in a day or two we’ll have a version that works properly on all machines.

Has anyone had any success with RiscPKG on the OMAP? I can’t seem to get it to work on my beagleboard.