It is hard if you are going to be playing in assembly circles. Many start elsewhere (text, graphics and even audio on the GBA) but you can certainly start there if you want and make some good headway.
Anyway there is no special thing I can tell you like you might for other systems of the time and later -- there is no file system or known pattern of ROM makeup, no magic header that tells you everything you want to know and it is just new enough that you get to see the results of compilers having their fun. Short version is it is all jumbled up in the game compared to unpacking an exe or dll on Windows.
I cover a few things in http://www.romhacking.net/forum/index.php/topic,14708.0.html
Equally there is a trick to finding the binary for most games. Also in the link above but the general idea is the first byte is a jump, typically to the end of the header, and then the first jump to anything in the 08?????? memory range is the binary in earnest.
I should also say that although the GBA is classic a classic implementation of an ARM processor if you are learning it in the hope you will be able to twist it to a modern ARM processor like those seen in phones it might not be the most useful. It won't hurt but compared to some things you might do it is going to leave a lot of gaps -- the GBA has no multi tasking, a seldom seen elsewhere THUMB mode, no floating point, technically not even a divide, a truly limited amount of memory, not much in the way of APIs or system commands (the BIOS has some good stuff but it is certainly not android style Linux) and a lot of embedded hardware that has since been abstracted but is dominant on the GBA (no 3d for instance, give or take a mode7 a like option). I would love to see more GBA hackers but the way you phrased it sees me want to say that.