#43573 - _Dan - Tue May 24, 2005 8:42 pm
Hello. :)
How would I get the address of the end of the rom?
I'm guessing it's something similar to the code for accessing video,
video = (unsigned short *)0x6000000;
but with the rom length or something.
The reason for this is to access data appended to the rom after compilation. Is it okay to do this? (there is no special format the rom's end has to be in or anything?)
Thanks.
#43581 - DekuTree64 - Tue May 24, 2005 9:58 pm
You could probably do it with some linkscript magic, by making an extra section at the end (like .rodata, .irwam, etc) with only one label in it and use that as your end marker. Probably not the best option though.
I think the way most file systems (such as tepples' GBFS) do it is with a magic string. Just make something like "@#$Dan's file system header%^&", or anything else you want that you would consider long enough and strange enough that the odds of it appearing anywhere else in the ROM by coincidence are so slim you don't have to worry about it.
Then in your data appending tool, put that string before all your file data.
In the GBA code, search for the string and you have your data start.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#43591 - tepples - Tue May 24, 2005 11:54 pm
Correct. GBFS uses a linear search from the address you specify in find_first_gbfs_file() to the end of ROM space. You can slightly speed up the search by passing an address known to be near the end of your ROM. In general, use the following command:
For devkitARM, the symbol is _end, and code will look roughly like the following (untested):
| Code: |
extern const char _end[];
const GBFS_FILE *dat;
int main(void)
{
dat = find_first_gbfs_file(_end);
} |
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#43685 - Steve++ - Wed May 25, 2005 6:36 pm
The magic string shouldn't be able to start just anywhere, otherwise the filesystem will be testing each byte for the beginning of the filesystem. Instead, the magic string should be aligned by some large boundary. I think 1KB is large enough. That's 1024 searches per MB.
#43743 - tepples - Thu May 26, 2005 3:39 am
GBFS does use a 256 byte stride when linear-searching for the magic string, as documented in its manual. I selected 256 bytes as a compromise between the low overhead requirements of .mb and the high speed requirements of .gba.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#43783 - _Dan - Thu May 26, 2005 8:14 pm
Great, thanks for the help. The magic string is a good idea.
BUT it would probably be quicker if I could specify the location (or at least have some idea where in memory to start looking).
I read somewhere it is something like:
0x8000000 + ROMSIZE
Where ROMSIZE is the size before files have been appended.
To get the location of the end.
If I appended my data to the rom, then to access the first element:
unsigned char *filedata = (unsigned char *)(0x8000000 + ROMSIZE);
filedata[0]; // first element of appended data
Is this correct?
Also, is it the same 0x8000000 location for both multiboot and normal roms?
Thanks.
#43789 - tepples - Thu May 26, 2005 8:24 pm
For multiboot programs, the starting location will be 0x02000000. For ROM programs, it'll be 0x08000000. However, ROMSIZE isn't known until link time, and only some link scripts echo it back to a symbol that a program can use. I am pretty sure it has something to do with the _end symbol, but I haven't tested it.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#43796 - _Dan - Thu May 26, 2005 8:48 pm
Thanks. :)
Presumably I could set the ROMSIZE to some random number, compile, and then to change it to the correct value either edit the rom or recompile.
I'll have a search for the _end thing.
#47810 - Mucca - Wed Jul 13, 2005 8:27 pm
I dont get, why dont you just use the symbols of any data that you link. Am I missing something here? Compile all raw binary files to .o using objcopy, and simply use the symbol:
extern const char _binary_myfile_bin_start
ok, not exactly that name, it depends on which objcopy you use and how you use it (check the name and type of the symbols by running nm.exe on the .o file). Heck IIRC the bin2o tool lets you define your own symbol name. Have a look in the devr's FAQ.
edit: oops dead thread. Should have opened my eyes