Toolbox problem on beagleboard?

I have been asked by someone to port !RiscPCB to run on the beagleboard it already runs on the iyonix computer OK, when I run it with alignment exceptions off it runs OK but with them on it crashes, When the pointer enters the main window.

After removing most of the main loop code it still crashed which led me to investigate other areas, it seems that I had used the toolbox to change the pointer shape when it entered the main window, if I remove this option it cures the error.

I have listed the toolbox modules in my boot file
for reference.

I tried adding a pointer shape change in another simple toolbox program and that also crashed?

ColourDbox 0.23 01 Jul 2003
ColourMenu 0.24 01 Jul 2003
DCSOject 1.17 03 Sep 2003
FileInfo 0.22 01 Jul 2003
FontDbox 0.22 01 Jul 2003
FontMenu 0.27 01 Jul 2003
IconBar 1.22 01 Jul 2003
Menu 0.40 01 Jul 2003
PrintDbox 0.20 01 Jul 2003
ProgInfo 0.20 01 Jul 2003
SaveAs 0.22 01 Jul 2003
Scale 0.19 01 Jul 2003
TextGadget 0.49 06 Jul 2003
ToolAction 0.25 27 Aug 2003
Toolbox 1.71 27 Aug 2003
Window 1.81 31 Aug 2003

Are you using ROL’s version of the toolbox modules? If so then I suspect that’s what the problem is, as 2003 is far too old for them to have been compiled by an ARMv7-safe compiler.

You could try using the versions which are supplied in the OMAP ROM image, but obviously that’s no good if you need any of the newer features (a quick look at CVS suggests that ROOLs toolbox modules are mostly 11 years old)

Twas me who asked you !!
I’m running with the modules built into the ROM and the same problem when entering the window occurs.
Where shows it is in the SpriteExtend module at offset &158C
The problem is a LDR R14,[r1,#12] where r1 is equal to 1
The file that contains this is SprExtend.Sources.SprOp line 1093.

Where exactly can I find the ROOL Toolbox modules? None in the self extracting HD4 file and unfortunately I never managed to use the *.tar,bz files.
Not that I’m sure if I installed the ROL ones in the first place. It’s been a while since I set up my BB and “info” just gives me a 2010 build date.

The ROOL Toolbox modules are in the ROM. *help toolbox will show what variant is in use, in OS5.17 it is 1.57, in the ROL Toolbox it is 1.71. The ROOL Toolbox modules can be seen here

Are you sure about that, David? Mine claimed to be 1.52 and still does so after downloading and installing the modules from ROOL.
Interestingly it also says “17. Jan 2003”

Ok so these should be correct then:

ColourDbox 0.19 (04 May 2000)
ColourMenu 0.21 (04 May 2000)
DCS Object 1.12 (15 Apr 2005)
FileInfo 0.19 (19 Jan 2010)
FontDbox 0.18 (04 May 2000)
Iconbar 1.20 (04 May 2000)
Menu 0.36 (04 May 2000)
PrintDbox 0.16 (04 May 2000)
ProgInfo 0.18 (13 Aug 2003)
SaveAs 0.19 (29 Nov 2004)
Scale 0.15 (04 May 2000)
ToolAction 0.30 (14 Jun 2008)
Toolbox 1.52 (17 Jan 2003)
Window Object 1.71 (30 Mar 2005)

Are you sure about that, David? Mine claimed to be 1.52

Sorry, my spelling mistake, the OS5.17 ROM Toolbox module is indeed 1.52.

After some more investigating it seems that even though I had the toolbox modules I listed in the boot sequence the loaded modules are :-
Toolbox 1.52 (17 Jan 2003)
ColourDbox 0.19 (04 May 2000)
ColourMenu 0.21 (04 May 2000) etc.

I still get the error with these modules loaded if I turn on the pointer shape control via the toolbox. So its seems that there may be a problem with the toolbox unless I have done something very silly :-)

BTW tank how did you determine that the error was in the sprite extend module, can you tell where a module is loaded in memory without looking at the sources? I just get an error of PC=&FC31AFb8

BTW tank how did you determine that the error was in the sprite extend module, can you tell where a module is loaded in memory without looking at the sources?

*modules will list the start address of each module. That makes it quite easy to work out which ROM module you’re in. Modules in the RMA will be a bit harder, since they might not be listed in increasing address order, and you’re not given any indication of where each module ends, etc. There’s also the *where command (supplied by the DebugTools module – see this wiki page) which is an easier/more reliable way of finding out where a crash was. Unfortunately, working out which source line caused the error is a little bit trickier.

Terry/Tank, are you two looking into this bug? If not, does the current version of RiscPCB work well enough on the BB for people to recreate the bug? Or is there a simple testcase that can be used? (I’ve never really used the toolbox, so I’ve got no idea how much code is required to get it to change the pointer shape when entering/exiting windows)

Terry which version of !RiscPCB are you using – 0.47? ie have you recompiled?
In ver 0.47 there are at least four ARM7 instructions incompatable.
00020B0C LDR R0,[R4,#6]
00020E68 LDR R0,[R5,#6]
00020E98 LDR R0,[R5,#6]
00020EB8 LDR R2,[R4,#6]

Use the ‘*WHERE’ command in a tast window to determine the module and offset of the error.

I am recompiling a newer version of RiscPCB using the C/C++ version 5.68 which I think by default should compile OK for ARM7 type chips.

Jeffrey I have a simple toolbox application that I used to use as a template I will see if I can upload it somewhere so people can try it.

There is very little code involved when using the toolbox you just assign a sprite to use for the pointer shape and the toolbox controls this in the background. when I upload the file I will add some instructions.

I have a minimal SpriteExtend wrecker on my site

It is written in AppBasic but the actual pointer change is set using ResEd. The application opens a window, just move the pointer over it.

*showregs
Register dump (stored at &2000E8AC) is:
R0 = 00000124 R1 = 00000001 R2 = 65109232 R3 = 5F727470
R4 = 6E696F70 R5 = 00000074 R6 = 00000000 R7 = 20124520
R8 = FA207DF8 R9 = FC1A0B88 R10 = 00000001 R11 = 00000854
R12 = 2002A174 R13 = FA207D28 R14 = 2002A6A0 R15 = FC27F6B4
Mode SVC32 flags set: nzcvqjggggeAift PSR = 00000113
*where
Address FC27F6B4 is at offset 0000148C in module SpriteExtend
*help SpriteExtend
==> Help on keyword SpriteExtend
Module is: SpriteExtension 1.39 (11 Jan 2011)
*

Hi I have uploaded a simple C program that shows the error at
http://www.idealist.demon.co.uk/testtool.zip

For those that have never used the toolbox go into !test directory double click on the res file
double click on the main file
press menu in window that opened and
select other properties
at botton of other properties window you should see the pointer control.

Cheer’s

Terry

Using the info from D Pitt :-
The instruction is ldr r14,[r1,#&00C]

r1 = 1
Program is trying to do an unlined load from &00C +1 zero page.

Can this be correct?

Yes, that’s the same conclusion that Tank came to.

Now your mission (if you choose to accept it!) is to work out why that code (line 1093 of SpriteExtend.Sources.SprOp) ended up with a bad sprite area pointer in the first place.

Terry, as Jeffrey said, use the *Where command to show which area of memory the error is located in, and *Showregs to do a register dump.
Jeffrey, the toolbox lets you choose a pointer shape by sprite name in the !ResEd editing window.
I have just tried the !RiscPCB.Res file with !ResTest and this does not produce the error, but when the app is run, as before, the same error (I also tried one of my apps and put a pointer shape in, with the same results, it works in !ResTest but not when the program is running), so what interaction with an actual running app as against !ResTest could cause this.
This may not be being caused by SpriteExtend, as it may be being passed duff registers.
I had a problem a few months ago with a toolbox app that was passing an unaligned pointer to the wimp.

[a few minutes later]
Building the SpriteExtend module with BIC r1,r1,#3 just above the offending line of code lets it work….
A quick test loading a saved PCB design and messing with it seems OK.
Jeffrey, do you remember you did this to the wimp for me (wimp04 was the file in question)?
Does this indicate that the Toolbox has a deeper problem somewhere ?

Jeffrey, do you remember you did this to the wimp for me (wimp04 was the file in question)?

Yes, it was this thread. Although I did fix the crash, it doesn’t look like we ever got to the bottom of why the toolbox was passing in a bad pointer in the first place. Have you still got a copy of the program? It would be good to look into what was going wrong.

With this SpriteExtend crash I think it’ll definitely be the toolbox at fault, since ‘1’ certainly isn’t a valid sprite area pointer. We should probably also add to SpriteExtend a simple check for any obviously invalid sprite/area pointers so that the SWIs just return errors instead of misbehaving in machine-dependent ways.

If someone’s going to find time to delve further into the Toolbox, is it worth keeping an eye open for Ticket #214 issues too?

[Edit: Oops, that’s the ‘TextGadgets’ module – sorry.]

Just looking at the code pointed by Jeffrey I can see that R0 is the SpriteOp opcode used (SetPointerShape) and as it is greater than 0×0100 R1 is the sprite area pointer.

If you look at the description of Wimp_CreateWindow, value 1 is used to refer to the Wimp Sprite Area. My guess is that the calling code forgot to replace that value with the actual sprite area pointer used by the Wimp.

With this SpriteExtend crash I think it’ll definitely be the toolbox at fault, since ‘1’ certainly isn’t a valid sprite area pointer.

I’ve just had a look at the code in CVS and in the Toolbox/Window/c/events code to change the pointer in subroutine events_pointer_over_window it first checks to see if the pointer is in the clients sprite area by trying the sprite op to set the pointer shape. If that fails it then tries the WIMP sprite area.
It gets the client sprite area with:regs.r⁰ = Toolbox_GetSysInfo_SpriteArea;
if ((e = kernel_swi (ToolboxGetSysInfo, &regs, &regs)) != NULL)
goto end;
I believe this call is returning 1 for the sprite area and the test that just failed on other machines crashes on the Beagleboard.

You could try putting a dummy sprites file called “Sprites” in the application directory and see if that stops the crash by ensuring there is a valid client area sprite pointer. This may (or may not) prove my theory.

Looking at toolbox/toolbox/c/task it appears that the client sprite pointer is set to 1 (which is supposed to mean use the WIMP sprite area) if no “Sprites” file is loaded.
So the fix would be to either ensure the SpriteOp returns a kernel error if it’s given an invalid address (or even specifically 1) or to fix the toolbox pointer set code so it doesn’t try the load at all if the client sprite area is 1.

That sounds like a good analysis, Alan.

So the fix would be to either ensure the SpriteOp returns a kernel error if it’s given an invalid address (or even specifically 1) or to fix the toolbox pointer set code so it doesn’t try the load at all if the client sprite area is 1.

I think it would be best if we implemented both fixes.

You could try putting a dummy sprites file called “Sprites” in the application directory and see if that stops the crash by ensuring there is a valid client area sprite pointer.

A dummy Sprites file does indeed evade the crash in both of the test applications above.

So the fix would be to either ensure the SpriteOp returns a kernel error if it’s given an invalid address (or even specifically 1) or to fix the toolbox pointer set code so it doesn’t try the load at all if the client sprite area is 1.

I think it would be best if we implemented both fixes

I agree. Fixing the toolbox code as well would make it a lot clearer on what was happening.

Unfortunately I haven’t the tools to do the either of the fixes, but it should be obvious what needs to be done from my description of the problem above.

I’ve now checked in some fixes to both the toolbox and SpriteExtend. I’ll see if ROOL can upload any new ROM images (or update the toolbox downloads).

Thanks for the help everyone!