StrongEd and SparkFS problems on CortexA8

SparkFS and StrongEd do not work any more on my BBrev6, though they used to in an earlier version. I tested several programs and may have accidentally overwritten some important module in my boot structure. Could somebody please confirm that both still run on the latest rom image?

Error messages are:

StrongEd: abort on data transfer at &00042E7C

SparkFS: reports “Handle is either illegal or has been closed” when packing files bigger that 200k. Unpacking also has problems.

Thank you. I hope it’s just me <:->

Does StrongED produce a StrongDump file when aborting? If it does, could you please send it to me so that I can check if it’s a problem at StrongED’s end. Thanks.

I sent you the StrongDump file to the casema address. Having to use !SrcEdit feels really bad after getting used to StrongEd :-). Thanks and good luck. If I can check or test anything please let me know.

Thanks for the StrongDump file.

I’ve had a look at it and I can’t see anything wrong with StrongED. The abort is in an STR but the address used is both valid and word-aligned.

There was one oddity though, the StrongDump contains a copy of the exception registers. All registers look normal except for user_r13 and user_r14 which both point into ROM space.

Somehow they must have been corrupted, either before or after being written to the exception area. It might be useful to know when/why this happens.

I can’t offer any direct assistance (no BeagleBoard) but if anything needs adding to StrongED (eg debug output) then I’d be happy to help.

Just tried it out and I get the same error Uwe got with Jeffrey’s latest ROM image (2010-08-14). The one before also gives that error (2010-07-20). The one I originally used however lets StrongEd work just fine (2010-05-05).

So either later RISC OS versions are broken, or StrongEd uses code that gets away with previous OS versions.

I guess this is one for Jeffrey to analyze :-(

I guess this is one for Jeffrey to analyze :-(

Hmm, I’ll try to find it anyway. I have have found out that StrongEd does work when certain things happen. Just when I tried to generate the StrongDump file, StrongEd suddenly worked. But I had tested some programs going weird the evening before and left the board running, and even the TaskManager Icon was missing. After rebooting, the problem was back and I could generate the StrongDump file. I did not think of generating a module listing when StrongEd worked though – that was probably a big mistake.

I had a look at this last night. It looks like it’s another fun issue to do with the interaction of AMBControl and the cache/TLB op abort handler. Specifically, this is what seems to be happening:

• StrongED calls Wimp_SlotSize
• Wimp_SlotSize changes the mapping of the pages in application space, causing the pages to be mapped out
• Wimp_SlotSize then returns, and the CPU starts executing code from a page that’s no longer mapped in(!). I’m sure this must be a bug/’optimisation’ in AMBControl/ChangeDynamicArea where it’s not cleaning the cache properly; or possibly a bug in the cache/TLB ops.
• The CPU hits the STR R0,[R12,#-8] instruction that occurs shortly after the SWI
• This triggers a data abort, since the page pointed to by R12 isn’t mapped in
• The first thing the data abort handler does is try to load the aborting instruction to determine whether it’s a cache/TLB op that’s aborted. But this fails because that page isn’t mapped in (even though it should be mapped in in order for the CPU to be able to trigger a data abort from that address)
• The data abort handler gets re-entered, passes the ‘is this a cache/TLB op?’ test OK (since it would be examining the LDR that the cache/TLB op check code does), and goes on to enter AMBControl
• AMBControl then detects that the fault address is inside application space and maps in the missing page, and resumes the aborted instruction (i.e. the first instance of the abort handler)
• The first instance of the handler then looks at the ‘STR R0,[R12,#-8]’ and decides it’s not a cache/TLB op either. Control then passes onto AMBControl again, which uses the DFAR (Data fault address register) to determine what address triggered the abort; except the DFAR would have been clobbered by the recursive abort, and will be pointing to the STR instruction rather than the address the STR is accessing.
• AMBControl then thinks “Huh, that page is already mapped in. Must be a genuine abort” and maps in the rest of application space before passing control to the environment abort handler.
• This then causes the data abort error to be reported, even though the code isn’t doing anything wrong.

While looking at the code last night I realised the cache/TLB op check wasn’t re-entrant (after all, it should never trigger an abort itself), which is why the register dump wasn’t showing the right values for R13 & R14. So I fixed it to preserve all registers, but I forgot about DFAR & DFSR, which is why I was still having problems. A quick test now confirms that if I also make it preserve DFAR & DFSR then everything works (or at least StrongED does; I haven’t tried SparkFS), so when I get home tonight I’ll do a bit more testing, check in my fixes, and upload a ROM image (I need to grab the latest changes from CVS, and make sure I haven’t got any debug code knocking around)

The fix is now in CVS, although at some point I should probably try and work out why the ‘impossible’ data abort was triggering in the first place.

Here’s an up to date ROM image

I can confirm that StrongEd loads fine with your changes made and a rebuild.

P.S it looks like Jeffrey has his own page in the Wiki !!