z80hastings
Posts: 2
Joined: Sun Dec 16, 2012 2:58 pm

Possible Memory/Linker Issue

Wed Jan 02, 2013 10:17 pm

Run into a rather annoying problem; and after spending the usual unproductive time searching for answers thought it might just be quicker to ask. Basically worked through the tutorials on the University Of Cambridge site and have been writing my own code from there; but have now hit a wall.

My code will compile and run as expected (using the linker/makefile from the tutorials but my own code for displaying on screen, etc).
If I try to include a second binary file in the source via:

Code: Select all

.section .data
.align 4
imgTestSprite:
.incbin "sprite.bin"
The code stops running; if however I replace the sprite.bin file with a copy of a smaller binary file it works, so its obviously the size that's causing the issue (its only around 13Kb in size).
As mentioned above the basic dev environment set-up is as per Uni Of Cambridge tutorials.
Any help in where to look would be much appreciated (it's all so much more complicated than the old days of bare-metal z80 assembler on the Amstrad) :?

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Possible Memory/Linker Issue

Thu Jan 03, 2013 7:35 am

My guess would be that it's down to where you're including the binary file. If it's (for example) causing the entry point to be moved from 0x8000 and you're jumping into some random data rather than your code.

The other option is that it's causing relative branches to break (most likely if you're using thumb rather than arm, as ARM relative jumps have 24-bit range).

I'd suggest using the -Map <file> option to the linker and then going over that with a fine tooth comb.

User avatar
Chadderz
Posts: 64
Joined: Thu Aug 30, 2012 12:50 pm
Location: Cambridge, UK

Re: Possible Memory/Linker Issue

Fri Jan 04, 2013 7:26 am

This is almost certainly the framebufferinfo causing the problem. This was a bug in the GPU code at the time of writing the tutorial, but is now fixable. Basically, when we supply the address to the GPU via the mailbox in framebuffer.s, it sometimes doesn't flush its cache, and so the value it writes back never appears to us. The code actually gets stuck waiting for the reply (try flashing an LED there). You can fix this by adding 0x40000000 to the address of the framebufferinfo that you report to the GPU, which causes the GPU to write through its cache.

z80hastings
Posts: 2
Joined: Sun Dec 16, 2012 2:58 pm

Re: Possible Memory/Linker Issue

Fri Jan 04, 2013 9:33 pm

Brilliant, that did it! Adding 0x40000000 to the framebuffer location worked a treat; and saved me tearing out more hair .. Now on with the coding :)

Return to “Bare metal, Assembly language”