ARMv7 compatibility list

http://www.riscosopen.org/wiki/documentation/show/ARMv7%20software%20compatibility%20list

It’s a bit crap, isn’t it?

Two issues immediately stand out:

• Incompleteness. This is the first time I’ve had to use it in anger, and it’s quite alarming just how much software simply isn’t there. Where’s NewsHound, for example? How are BeagleBoard users supposed to access Usenet if apparently nobody uses RISC OS’s most common (only?) news fetcher on ARMv7?
• Outdatedness. I’ve just alerted Frank de Bruijn to the fact that whoever added AntiSpam to the table had somehow got hold of version 1.18 (nine years old!), written “Seems OK” and linked to the previous maintainer’s website, when in reality AntiSpam is up to version 1.63, fully supported and run on BeagleBoards on a regular basis. Similarly, NetSurf is listed as version 2.6, and an old version of the OpenVector suite is quoted as giving “Illegal memory access” when in fact recent versions have been supported for quite some time.

Firstly, I think a lot of author-emailing needs to be going on. If it looks like it’s still maintained or the author is not known to have left the RISC OS scene, send an email! Keep collecting those precious ARMv7 OK badges. I’ve just sent off a first blitz dealing with all the examples mentioned here. A table filled with loads and loads of “eeh, this man down the pub, ‘e told me it’s all right so far as ‘e can tell, but it’s yer own lookout, ain’t it?”, particularly when it’s not necessary, will do nothing to reassure users.

Secondly, it’s pretty plain that the table isn’t maintainable in its present state. It was set up when the Cortex-A8 port was “currently in heavy development”, and doesn’t it just look it.

The RISC OS ROM Date probably ought to be scrapped altogether – I mean, things not being compatible with operating system changes is completely different to not being compatible with new hardware (just look at what’s just happened to EasyFontPro).

The “Version” field is largely meaningless, since it just gets more and more outdated as new versions are released – a “first known supported version” would be both much more informative and much more helpful.

For unmaintained software, an alternative “tested with” is still appropriate, but now RISC OS developers are well aware of the problem and are working to fix it, we should be much more careful not to conflate the two, otherwise AntiSpam’s former problem gets replicated many times over. Developer involvement is crucial here.

I think the table ought to be completely recast, from an informal collection of scribbles made by people who started random ancient bits of software up, observed they didn’t crash within five seconds, and put “Seems OK”, to a formal database of software which is known to be working on the BeagleBoard, or at least has the promise of bugfixes should it be found to be not 100%.

I agree the list needs updating. But unless a developer has an ARMv7 machine, how are they able to say a program has been fully tested and is ok on an ARMv7? Users may run it ok, and may even do some testing, but to fully test it is a big task. Or it may be very simple to say it is ARMv7 compliant if pure BASIC!

You make some fair comments there.

If you (or anyone else) feel(s) like it, I’d suggest reworking the table as you suggest for one category with revised content. Give it a week or two for comments/changes, then roll out that format for the other categories too.

But unless a developer has an ARMv7 machine, how are they able to say a program has been fully tested and is ok on an ARMv7?

• (OK and Supported) – works OK, involvement of author(s), willingness to address further issues as they arise

Right, I’ve got a work-in-progress draft of my ideas in the Networking section.

• The ROM date has been removed.
• New status: “Not Supported”, for software where the current lack of ARMv7 compatibility is a deliberate decision. In DialUp’s case, Andrew Rawnsley told me he’ll recompile it “as and when someone can confirm [the serial block driver] is up and running.”
• The version column has been split in two:
  • “Earliest working version” is the number from which software became officially OK and Supported – this means the wiki doesn’t become gradually out of date as new software comes out
  • “Latest version tested” is for all other statuses, and is the version which was used by the person designating it as such. This is mainly unmaintained/dormant software.
  • Yes, the two columns are mutually exclusive, but I felt it was necessary to draw a stronger distinction than simply saying “version” and explaining it in the introductory text, especially now this is no longer purely a database of software testing. This could be changed back if people object.

Any thoughts?

In other news, Textile’s table markup is truly horrible.

Hi Martin,
This is the first time I’ve taken a look at the list in a while;
http://www.riscosopen.org/wiki/documentation/show/ARMv7%20software%20compatibility%20list
I’d forgotten that it’s a good place to find links to software which, if it’s free, is useful to then try out with an ‘adventurous spirit’ or, if not free, pursue via the seller’s website.
To me the problem with the page is that it is confusing to newcomers, and probably quite off-putting as it feels like nothing there can quite be trusted to work, which I think was your initial reaction too. For example, just the heading “ARMv7 software compatibility list” is going to flumox many a fresh visitor; “Does that include my Raspberry Pi ?”
Others are welcome to say if they disagree; I think that the table tries to be too ambitious and a more focussed and specific approach would be a much better advert for RISC OS. It’s too ambitious because it’s chasing a moving target. I would suggest it focus on a few targets that are not moving. Construct it keeping in mind what the people visiting the page actually want from it, rather than it being a table for developers.
I think separate tables would work better;
One for Iyonix 5.16, Iyonix 5.18; Beagleboard 5.18, ARMini 5.18, Raspberry Pi 5.20, Pandaboard 5.18 …
The update from RISC OS 5.16 to 5.18 has not been trouble free, and has highlighted that each time a major upgrade comes out, everything needs testing & checking again. I think we’d also get more input from RISC OS users, if they felt they were contributing to a table that was going to be of use longer term rather than one that becomes untrustworthy each time the OS gets updated.
Regards,
Martin.

Sounds like a crazy amount of work to separate them. Obviously if someone is volunteering, but otherwise I don’t see why we can’t just expect RPi people to use the same nauce as BB / Panda users. After all, it is targetted at enthusiast/programmer/hobbyist people.

A small disclaimer along the lines of “if it works on ARMv7, it’ll should work on Pi” is all that should be needed.

Panda probably does need its own list, due to the problems relating to squeezed files, but perhaps it is too soon to make a ruling on that.

I would suggest that, for BeagleBoard, BeagleBoard xM and ARMini at least, the “RISC OS ROM Date” no longer makes sense. It did in the early days of the RISC OS port, when bugs were being found and fixed within days. Now that the ports have achieved stability, I don’t think the date is relevant; perhaps the RISC OS version makes more sense.

However, the Raspberry Pi port may bring us back to lower stability, so maybe a date makes more sense for its ROM.

Rather than separate tables, perhaps adding a column would be better. Any software in the table should work equally well on Iyonix, BeagleBoard, BeagleBoard xM and ARMini. I think that separate tables would be unduly onerous. Even separate columns for each of those computers would have 99% of the information duplicated; I would go for one column for all 4 computers, and add something in the “Notes” column if there is any difference. There might be a case for a separate column for the Iyonix, I suppose, because of the different treatment of unaligned accesses in older software.

Perhaps there should be a column that indicates if it only works with alignment exceptions off. Personally I try and avoid using software that requires AEs to be off.

In DialUp’s case, Andrew Rawnsley told me he’ll recompile it “as and when someone can confirm [the serial block driver] is up and running.”

I’m fairly certain the serial block driver works now – I’ll give it a check tonight. However the bigger issue with DialUp is that the serial port on the BB/BB-xM only has the RX and TX lines connected, so is useless for connecting to things like modems which want extra control lines. I believe the serial ports that addon boards provide will have the full set of control lines, but in order for the boards to work the ROM might need a couple of tweaks to make sure the UART lines on the expansion header are enabled.

Panda probably does need its own list, due to the problems relating to squeezed files, but perhaps it is too soon to make a ruling on that.

Can anyone explain what the problem with squeezed files is? The OS has the ability to manually unsqueeze programs, so if the problem is a bug/incompatability in the code generated by the squeeze utility then we should fix it and get the OS to handle unsqueezing any old files.

However, the Raspberry Pi port may bring us back to lower stability, so maybe a date makes more sense for its ROM.

I don’t expect the stability problems to be as bad as they were during the early days of the OMAP port. After all, the OS should now be fully ARMv6/v7 compatible. It’s probably best to wait and see once the Pi ROM images are available.

I’ll admit that I haven’t looked at the compatability list in many months – so unless stuff gets mentioned on the forums (or on the bug tracker, if it was working), problems which are caused by OS bugs are likely to go unnoticed (by me, at least). I can see how a well-organised compatability list would be useful for the average user, but if people do discover that something isn’t working, and they aren’t certain it’s a program bug, then it might be a good idea to prompt them to mention it on the forums so that an OS developer can take a look. (And if they are certain it’s a program bug, they should obviously be prompted to contact the author)

“Does that include my Raspberry Pi ?”

It’s probably best to wait and see once the Pi ROM images are available.

At that point, maybe ARMv7 software compatibility list should be renamed ARMv6+ software compatibility list. We could also consider requesting an amendment to the "ARMv7 compatible" logo, if that’d be appropriate.

I’m fairly certain the serial block driver works now

Where can I find it, please, Jeffrey? I’d like to use it for something else – which will have the side effect of giving it something of a work-out.

The Internal32 driver available from here on X-Ample’s site “works”, but with the current ROM/driver it looks like it’ll only allow you to access OMAP UART 1 (via Internal32 port 1).

About the Pandaboard squeeze problem – Willi’s now sent me a description of the problem (wrong parameters being passed to OS_SynchroniseCodeAreas). Although the bug was fixed 8 years ago, it looks like the problem is that Castle didn’t follow through and create an updated version of UnsqueezeAIF that will detect and unsqueeze the bad files.

Part of the Panda problem is, I think, down to software devs like ourselves (R-Comp) and others. Since there were issues with some recent versions of Squeeze wrt the two forks of the OS, we’ve been using slightly older versions for a while in order to ensure we don’t break compatibility with RISC OS 6 etc. I’m told that this is no longer an issue, and am now using the latest build. For some apps, we’re actually dropping the squeezing altogether, but it still has merit for larger apps on USB-based systems (smaller executables will load faster).

I’ve now updated UnSqueezeAIF to cope with the buggy squeeze versions, and added it to all the ROM images, so that should put the Pandaboard problem to rest.

Let me know if you run into any problems with it – I had to tweak the patching code a bit to make it 32bit safe, so if it encounters an unusual image there’s a chance it could corrupt it and cause a crash.

I’ve now updated UnSqueezeAIF to cope with the buggy squeeze versions, and added it to all the ROM images, so that should put the Pandaboard problem to rest.

Looking good so far! SparkFS & Grapevine work correctly now. (I don’t have much setup on my Pandaboard yet!)
If anyone would like me to test specific apps, please let me know.

That was a bit more of an extended break than I’d hoped for, but having finally got over my exams and completed several projects (including the very one which led me to start this thread), I think it’s time to revisit this.

Is everybody happy with the revised layout of the Networking section? (There is potential to address nuances between different boards, but I think if any arise it could probably be easily confined to the notes column.) If so, I want to have a go at redesigning the whole table in this form, and contacting as many authors as I can find.

While we’re at it, any more votes for renaming the page “ARMv6+ software compatibility list”? Hopefully Martin Wuerthner can design a revised icon too.

happy with the revised layout of the Networking section

Looks like a useful improvement to me, in line with your initial comments.

contacting as many authors as I can find

If your AntiSpam experience is anything to go by, I agree this’d be extremely helpful. There’s also the Raspberry Pi stuff, which I know you’re well aware of. Looking at that list, there are a number of outstanding items, and you may find the Community licensing request communication to be useful. The password for the riscosrpi.coord@gmail.com can be provided if you want.

You can let us know afterwards if this is more or less work than your exams! And if you’d like to split things up so others can help, please say which way you think would be best.

There’s also the Raspberry Pi stuff, which I know you’re well aware of.

With a few exceptions, that seems to be merely the contents of the ROOL disc image. This is for third-party software.

Looking at that list, there are a number of outstanding items, and you may find the Community licensing request communication to be useful.

This is purely about establishing what runs and what doesn’t! Nothing to do with any disc image proposal and only circumstantially to do with the Pi. Not all software can reliably be run on ARMv6+ at present, and we have no adequate database of compatible software, which (as I’ve discovered) can lead to some very nasty pitfalls for unwary users.

Somebody else do all the publicity work for RISC OS on the Raspberry Pi – my scope is limited to one wiki page!

seems to be merely the contents of the ROOL disc image

Not really. I was referring to what Chris referred to as "useful things to have". If there’s some overlap with apps/authors, then it makes sense to me to ask all the questions together. But maybe I’m missing something.

While we’re at it, any more votes for renaming the page “ARMv6+ software compatibility list”?

Not all software can reliably be run on ARMv6+ at present

So in that case, does the page need additional columns to cater for both? I thought that updates to address ARMv7 compatibility are generally applicable to ARMv6 too. Anyway, never mind – whatever you do will be very helpful and I’m sure others will fill in the gaps. Cheers.

So in that case, does the page need additional columns to cater for both? I thought that updates to address ARMv7 compatibility are generally applicable to ARMv6 too.

Yes… which is why I was proposing to rename it the “ARMv6+ software compatibility list” as the term “ARMv6+” encompasses both the ARMv6 architecture, as used in the Raspberry Pi, and implicitly (by means of the “+”) also any higher-numbered architectures such as ARMv7, whereas its current name of “ARMv7 compatibility list” gives the misleading impression that its contents are not also applicable to ARMv6.

Good grief.

Meanwhile, over in the land of constructive debate…

Why do we even have an “Astronomy” section? Considering the target audience of the Pi it might be best to rename this as “Education” and add some more apps to it, if anyone has any they’re able to test.

AFAIAA the current Infozip download does not yet incorporate the recompiled zip and unzip binaries linked. Unfortunately there’s a missing third one, unzipsfx, which is prepended to the start of self-extracting archives, preventing me from making a full new release. Can anyone supply this? (I’m also not at all sure as to the integrity of the SlidingHeap module, but hopefully since it’s assembler it won’t have too many problems.)

What’s this “Seems to work” next to DataPower 3? Sadly R-Comp’s website is next to useless and miles out of date, so it looks as if I’m going to have to email them about all their software. Where’s Fireworkz on there, for example?

Ghostscript 1.05 was ported by the same person who designed the ARMv7 OK logo, and said logo appears next to its download link, and yet it’s marked as “Seems OK”. WTF?

“Emulation” should really be updated to take account of Chris Gransden’s work.

That “Games” section looks a bit bare. I can personally vouch for my own 90s-tastic platformer, so I’ll be adding that shortly.

Spr2Png should have a link to Martin Wuerthner’s fixed executable.

Thump 1.51 states on its homepage that it is “BeagleBoard compliant” – more misuse of “Seems OK”.

Why the hell does DigitalCD have two entries with different version numbers?

What is this freakishness going by the name of “MessageTrans”? Are you saying MessageTrans isn’t compatible yet? We’re all stuffed, then.

I’m coming closer and closer to the conclusion that a lot of stuff in this table ought to be removed altogether, to reduce the noise-to-signal ratio.

And I can see that one thing I ought to be prioritising is getting my own house in order…

Should we have a new category for ‘common dependencies’ i.e. things (mainly modules) which are designed to be used by more than one application? If one of those doesn’t work, it can break more than one dependent application.

Why do we even have an “Astronomy” section?

Because the page is maintained by the community and someone felt that was an appropriate heading to use?

Considering the target audience of the Pi it might be best to rename this as “Education” and add some more apps to it, if anyone has any they’re able to test.

Agreed.

Ghostscript 1.05 was ported by the same person who designed the ARMv7 OK logo, and said logo appears next to its download link, and yet it’s marked as “Seems OK”. WTF?

Sounds like someone updated one bit and missed another.

Why the hell does DigitalCD have two entries with different version numbers?

More careless editing by someone.

Are you saying MessageTrans isn’t compatible yet?

I’ve no idea why this is even in the table.

I’m coming closer and closer to the conclusion that a lot of stuff in this table ought to be removed altogether, to reduce the noise-to-signal ratio.

In my view, simpler is better; we don’t want to baffle normal users because that defeats the point.

Should we have a new category for ‘common dependencies’

A good idea for adding later, I’d say. Stick with getting the main list in order first.

The only comment I have on renaming the page to be “ARMv6+ software compatibility list” is that it implies that software listed there will also be ARMv8, ARMv9, etc. compatible. Which it most likely will not :)

Calling it the “ARMv6/v7 software compatibility list” may therefore be a better choice (Even though it’s still a long time until ARMv8 chips become available).

Re:

Considering the target audience of the Pi…

and

I’m coming closer and closer to the conclusion that a lot of stuff in this table ought to be removed altogether, to reduce the noise-to-signal ratio.

It depends on what the list is for.

I don’t think the target audience of any hardware should be relevant, if it is a software compatibility list as stated. It should be as close to comprehensive as possible. Also, I don’t think splitting the compatibility list into separate sections is a good idea. One continuous list of software in alphabetical order would make things easier to look up. (I did a lot of scrolling up and down to hunt down the apps Martin mentioned.)

If we want to have a “recommended software” list (which I think is a good idea), then it should be a separate thing, concise and split into sections for different types of software.

As for whether the compatibility list is ARMv6+ vs. ARMv7, what about software that uses ARMv7 features like NEON?