Error booting latest downloadable Beagle ROM

Yeah, any recent development build is built with GCC4, but the latest release version, 2.1, is built with GCC3 (as available from the NetSurf site).

Using the latest development build i kept getting an assertion failure at line 536 in ucstables.c. Tracked it down to utf8_to_enc in utf8.c and commented out lines 260 & 270. Maybe the iconv module is causing the problem?

Firstly, utf8_to_enc() is simply a wrapper around utf8_convert() so clearly can’t be broken. Secondly, lines 260 and 270 don’t implicate Iconv at all—the first is a call to strncasecmp, the second is a close brace. Therefore, I think you’re looking at old sources. Please try with SVN HEAD. If that doesn’t work, please email¹ me a unified diff of your changes and I’ll take a look.

1. jmb@netsurf-browser.org

Assuming the builds don’t fail, I’ll upload the latest autobuilds tonight. This should (for Beagle at least) have the unaligned load exceptions enabled.

Since updating to the latest build, all the programs I have that use unixlib no longer run.

That’s either a good thing or a bad thing :) (Actually, it’s probably a bad thing if all the software that’s been compiled with GCC 4 so far isn’t actually compatible)

I’ll download a copy of the ROM image and make sure it’s not a problem with that (and send the GCC team a quick report on what’s wrong with unixlib if it turns out that’s the problem).

In the meantime, you can use the following BASIC program to turn alignment exceptions off and (hopefully) allow you to run any software that you need to run: (Although there’s obviously no guarantee the software will run correctly, unless it’s using unaligned loads/stores properly)

DIM code% 256
P%=code%
[ OPT 0
SWI "OS_EnterOS" 
MRC CP15,0,R0,C1,C0,0
BIC R0,R0,#2
MCR CP15,0,R0,C1,C0,0
MSR CPSR_c,#&10
MOV R0,R0
MOV PC,R14
]
CALL code%

A second program with the BIC replaced with ORR should allow you to turn alignment exceptions back on again.

ROM image looks fine – looks like it’s a problem with unixlib (in GCC 4.1.1 release 1b). If I turn alignment exceptions off then everything seems to work OK (GCC was able to compile the example C programs, and the resulting binaries matched those produced by my Iyonix), so it’s probably OK to continue using code compiled by GCC 4 as long as you remember to turn alignment exceptions off beforehand.

Thanks. I also get an abort if I try to access fat32 formatted flash drives with this build.

Has anyone tried running this on QEMU lately? I’ve followed the instructions at:

http://code.google.com/p/understand/wiki/RISCOSOnQEMU

but still get this:

http://picasaweb.google.com/lh/photo/c9sQrKtw8Hy4KUIU-B3LfQ?feat=embedwebsite

is that to be expected, or should it work OK now?

I gave up on running builds under QEMU a long time ago because its emulation of the hardware was so incomplete. That screenshot looks about right for where I’d expect a build to get stuck. If you’re able to recompile the RISC OS source code, go to RiscOS.Sources.HAL.OMAP3.hdr.omap3530 and change the QEMU flag from {FALSE} to {TRUE}. This will disable the bit of code it’s getting stuck on in the video initialisation. Or if you can’t recompile RISC OS you can always have a go at fixing QEMU to emulate the DSI PLL :)

If you get beyond that then I’m not sure what will happen – chances are it will fail horribly somewhere else. It might be worth checking if the Maemo version of QEMU is in a better state (my original docs for getting QEMU running are at the bottom of this page Just be warned that I never really got a chance to test the ROM under the Maemo version of QEMU because QEMU disagreed with my PC and refused to respond to any input)

The unaligned access in UnixLib is my doing as it happens; my strlen implementation uses that (previously well-defined and unquestioned) behaviour to slightly reduce the chance of a load-use stall. Anyway, I’ve updated it and expect one of the gccsdk folk to commit the change soon; patching the latest NS binary with this change allows it to start up and run normally, as it did with the non-aborting OS ROM for me (I’ve been unable to reproduce the failure Chris reports).

Re the strlen change, original source is at http://adrianl.drobe.co.uk/ns/strlen.txt and jmb has kindly created a patch against UL HEAD -> http://jmb.drobe.co.uk/unaligned-strlen.p if anyone – Chris? – is impatient. I have tested with its original test rig and it passes.

drobe seems to be down right now. :( I’ll be sure to grab the patch when it comes back up. Thanks.

I’ve checked in a fix for the abort when using FAT formatted devices.

If you run into any other aborts, can you tell us the address? That way we can be sure we’re actually fixing the bug you found, and not the first abort we find when we test the issue :)

I’ve checked in a fix for the abort when using FAT formatted devices.

Excellent! I got my Beagle Board up and running today, and I’ve been experiencing an abort error when using a FAT memory stick. I’m trying to build a suitable ROM image from the CVS tree now.

And Jeffrey, I would like to congratulate you on your work getting RISC OS to run on the Beagle Board. Keep up the good work! It’s excellent to see RISC OS running on new hardware!

Rob.

Netsurf is now working ok. Apart from I get an abort at &201CF810 if I try to log into riscosopen.org. The abort happens as soon as I click on the field to enter my username. Works fine when alignment exceptions turned off. According to the ‘where’ command the address is in the ‘tinct’ module.

I’m also getting an abort when I run Firefox,

&FC168B0C is at offset &00003C94 in module TaskManager

First the task icon disappears then firefox appears on the icon bar then quits.

With regards to aborts. I am getting quite a few. Should I keep posting them here?

With regards to aborts. I am getting quite a few. Should I keep posting them here?

If it’s a program linked against unixlib then there’s probably not much point mentioning it at the moment (unless you know it’s been linked with a version containing the strlen() fix, or if it aborts somewhere weird, e.g. the task manager for FireFox). But for all other programs I’d say it’s certainly worth mentioning any aborts.

There is a wiki page I created a couple of weeks ago for listing application compatability – it’s probably a good idea if you list all the aborts there so everyone knows where to find them (and so they don’t get buried under hundreds of forum posts!)

https://www.riscosopen.org/wiki/documentation/pages/Cortex-A8+software+compatability+list

Of course the wiki’s broken itself again, so you’ll probably have to wait until tomorrow before you’re able to post anything.

According to the ‘where’ command the address is in the ‘tinct’ module

Tinct uses unaligned accesses for performance, so is not ARMv7 safe at present. There is currently no timescale for making it ARMv7 safe.

unless you know it’s been linked with a version containing the strlen() fix

All autobuilt versions of NetSurf since 11:30 this morning contain this fix.

Any chance of a new build of the Beagle Board ROM with Jeffreys fix for fat32 devices? I’m stuck as I don’t have an Iyonix to read an ADFS formatted USB drive, so I have to use fat32 for the moment.

I’ve tried building a ROM myself from the CVS, but I ran into a few problems!

Or can someone please send me a ROM they have recently built?

As yet all I’ve been able to do with my Beagle Board is play with Paint, Draw & Edit!

Many thanks! Rob.

rob@robheaton.co.uk

If you look back in this thread there’s a small basic program to turn off alignment exceptions. Then fat32 usb drives will start working again.

If you look back in this thread there’s a small basic program to turn off alignment exceptions. Then fat32 usb drives will start working again.

Thanks Chris, I hadn’t noticed that! I’ve tried running that BASIC program at the supervisor prompt and after starting the desktop. I can access the fat32 USB stick via the command line, and it allows me to copy 3 files then I get an “abort on data transfer” message.

I get the same abort error when I try to access the fat32 USB stick via the filer. The error I am getting is: Internal error: abort on data transfer at &FC2A36EC

Try formatting the USB stick with a partition size of 1GB.

Try formatting the USB stick with a partition size of 1GB.

Cheers Chris, that works!

Finally after 3 days, I can copy files to the Beagle Board! Thanks for all your help!

I’ve uploaded a new build of the OMAP ROM image which should have the fixed FileCore for FAT-formatted USB discs.

I’ve uploaded a new build of the OMAP ROM image which should have the fixed FileCore for FAT-formatted USB discs.

Many Thanks Steve! I will try the new build tonight.