AppSize in !Boot

For the last 3 days I’ve been trying to make a beagleboard rom image but when I put my new USB modules in it it doesn’t boot. As it changes to the desktop and the splash screen appears, an error box pops up with no text, buttons or icon in it. The iconbar hasn’t appeared at this point. Though I can’t do anything I can move the mouse so USB is working. I can unplug and reinsert the mouse and other devices and the hub lights go on and off and the mouse continues working.

If I use the old usbdriver file with my new ehci driver it boots ok so I thought there must be something wrong with my new usbdriver file.

However if I remove the line

AppSize 512000K

from !boot.utils.BootRun (7th line from bottom) everything works correctly.

What does appsize do?

This command is used at startup to shrink the RMA to its smallest possible size, and should not be used by other applications.

However if I remove the line
AppSize 512000K
from !boot.utils.BootRun (7th line from bottom) everything works correctly.
What does appsize do?

Isn’t the board you have an old Beagle rather than an XM?
IIRC the memory of the older version had less memory.

From the Rev C4 manual

5.3
Memory
The Micron POP memory is used on the Rev C4 BeagleBoard and is mounted on top of
the processor as mentioned. The key functi
on of the POP memory is to provide:
o 2Gb NAND x 16 (256MB)
o 2Gb MDDR SDRAM x32 (256MB @ 166MHz)

A quick check on the wiki page show 256MB vs. 512MB in the XM

So that command appears to be trying to set the RMA to a size bigger than the board memory.

I don’t think the value matters too much. I think it just free’s up available memory.

Its just a puzzle that with my new modules if I abort Bootrun after appsize xxx (value doesn’t make any difference) *desktop fails after showing the splash screen with what looks like not enough memory but *BASIC works. USB is working normally. Remove Appsize xxx and everything works normally.

Does disabling networking have any effect, since that’s via USB too, right?

Disabling networking made no difference. Tracking the bug through !Boot doesn’t look as if it is going to help either. I created a short obey file

AppSize 512000K
desktop

and put it at various points in !boot. It entered the desktop correctly right up until I put it as the last line in Choices.boot.predesk when it didn’t enter the desktop properly – failed in the usual manner.

If I put the obey file in the line before the last line it works correctly even though the line it was put before is just a comment.

It looks like at some point memory usage grows to the point where appsize does something and causes a failure.

I can’t even see how the new usbdriver module uses memory any different to the old usbdriver.

I’ve run out of ideas at the moment.

Yeah, that is very weird indeed. I hope someone with the knowledge can help you soon. Fingers crossed…

Investigating further Appsize (line 332 here) changes the RMA dynamic area size.

If I add AddToRMA 80k after AppSize 512000k everything works correctly – less than 80k fails.

I note in BootRun after the line AppSize 512000k there is the line

If Boot$OSVersion < 350 Then AddToRMA 256K

So this may be a problem that is supposed to be fixed. Anyone any thoughts?

What you’re most likely experiencing is one of the limitations of OS_ChangeDynamicArea – you aren’t allowed to resize a dynamic area from within an IRQ handler. So in the worst-case situation of an unfragmented RMA, if AppSize is allowed to shrink it to its minimum size then there’ll only be under 4K of space available for IRQ handlers to allocate memory from. If they use up that 4K (or need something larger) then they have no way of growing the RMA, other than having some kind of fallback path which will register a callback to allow the operation to be performed from the foreground (assuming there’s enough memory available to register the callback!)

At this stage I think the simplest fix would be to remove the “If Boot$OSVersion < 350 Then” bit and just make it so that all versions of the OS add 256K to the RMA after shrinking it. Later on it might be nice to have the RMA resize itself automatically to try and ensure there’s a minimum amount of free space available for IRQ code. Or even better, allow OS_ChangeDynamicArea from IRQ handlers! (But that would be a pretty big change, especially since it does things like issue service calls to warn applications of the memory being moved)

Thanks Jeffrey That seems a reasonable explanation to me – Thank goodness I didn’t rip my code to shreds :-)

Bodge alert… HeapUtils !