So decompile in the sense of look at some kind of original source code (some use decompile in the sense of explode a ROM into its component files, which, outside of a few homebrew games, does not exist for the GBA though there are some quirks you might exploit and mindsets to adopt as regards such things).
Theoretically it is possible -- most GBA games would be predominately written in C with maybe some inline assembly (C++ might theoretically compile but the overhead would be too much, indeed it was too much for a lot of the DS so you would be 3ds before that and even then it still saw assembly and plain C). The state of ARM decompilation of around that time... harder, much less with a base of the Nintendo chosen compilers (though some would have used the ARM-SDT). I don't think any emulators even use dynamic recompilation which is something of a first step (though others do skip that and go right for static). Any source code then is leaked (some stuff was in the gigaleaks, though not sure those games would be in it), accidentally included somewhere (no real examples for this I am aware of) or released (got plenty of binaries of games that failed to be published subsequently legitimately released but not sure any came with source code, some libraries were later released that got used in commercial games though with the krawall stuff being the most noted).
That might change in the future and the ARM options of IDA are rising rapidly, ARM had also pretty much taken over the portable embedded chip market by this point (the last gasp of MIPS on the PSP and maybe a few of the homebrew focused handhelds being what else went) so things will probably improve over the years to come.
To that end most people instead would go back to classic disassembly which does work. Don't think we have yet seen some full commented disassemblies like we have for various GB/GBC, SNES, NES, megadrive and such titles (usually pokemon, mario, sonic, final fantasy) but some are heading that way. Hundreds of hacks based on reverse engineering assembly code and altering it there have happened though and plenty of very nice tools for it also exist and have done for many years.
Not sure what to start with for this.
Few will do static disassembly for the GBA, though you can find the binary easily enough (GBA carts are set at 0800000 in memory, first instruction will be a jump to probably the end of the header, then some basic IO setup/initialisation and somewhere in that will be a jump to somewhere else in the 08??????-09?????? region where you have the binary proper. This would be one of those quirks.). Static is also harder as the GBA ARM7T CPU has two operating modes -- one a 32 bit mode called ARM and another a nominally 16 bit instruction mode called THUMB (albeit with the 32 bit registers in play) and while some tools can make an educated guess as to what is what you don't necessarily know by looking so having an emulator be in the right mode when looking at something makes life easier.
All that said most will probably first meet assembly either in tracing (the act of finding where something is in the ROM/code by watching what it changes and working backwards, or maybe forwards) or hardcoding cheats.
https://www.romhacking.net/documents/361/ is my usual link on tracing, though I do note it is for a very old command line fork of VBA (
https://web.archive.org/web/20130215155212/http://labmaster.bios.net.nz/vba-sdl-h/ ) so instead maybe grab no$gba which has had its debug version since become free, have some fun with GDB
https://wrongbaud.github.io/posts/ghidra-debugger/ and mgba has some good stuff
https://mgba.io/2015/10/20/dumping-the-undumped/ and the rest of that series of posts for examples.
Hardcoding cheats is less commonly done for the GBA than it was for the DS but the principle is almost the same as tracing. Easy enough to use cheats (
https://doc.kodewerx.org/hacking_gba.html https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial ) to find an area of memory changed by some action, set suitable breakpoint on said area and whatever alters it you change to not do that (harder if there are 20 instances of things that change it, think all the ways you might die/lose a life in a Mario style platformer) or change the logic just before the write to that area. Alternatively find the vblank routine (usually run 60 times a second) and add an extra write to that, or maybe have a check on the pressed keys also in the vblank and actions done accordingly. Said vblank thing is what a lot of things will do but might get troubled at some level if say the damage is too great and all the damage calculations and checks upon it happen before your write comes back in (though I did once do a what if you have no rings thing for one of the Sonic Advance titles with a cheat and that would work OK for that, albeit dodging bonus zones so probably better to go in for hit detection instead if doing that one properly).
http://www.coranac.com/tonc/text/asm.htm is a nice intro to ARM assembly, and GBA hardware as a whole actually. Sounds like you already found
http://problemkaputt.de/gbatek.htm ,
https://blog.quirk.es/2008/12/things-you-never-wanted-to-know-about.html ,
https://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm ,
http://members.iinet.net.au/~freeaxs/gbacomp/#BIOS Decompression Functions if rounding out the usual list.
Some like
https://web.archive.org/web/20120501132450/http://www.drunkencoders.com/tutorials/GBA/day_1.html too.
I have some worked examples in
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ as well.
https://www.romhacking.net/start/ also is worth a link, to say nothing of the site there in general.
Sonic does have a hacking base but usually more for the 16 bit era stuff, though enough fiddle with other games at a reasonably high level.
For an assembler to make code the other side then no$gba will have some options for it though fiddly and a bit different to some others, armips is probably what most use
https://www.romhacking.net/utilities/635/ or they will use the GCC ARM assembler (devkitpro being how most install that one). Don't use the older stuff like goldroad unless you are following a guide and need it to do the whole bug for bug thing.
If you are not familiar with assembly in general then while the above links will get you there eventually if you want more the mindset I do usually suggest people gain the basics on X86/x64 PC with stuff like art of assembly
https://www.plantation-productions.com/Webster/ and
https://stuff.pypt.lt/ggt80x86a/asm1.htm and then move sideways. The main differences tending to be lack of floating point (even the DS does not have that), immediates are smaller (though your assembler might do it for you), dedicated instructions/DMA is what does memory reading/writing (
https://adshomebrewersdiary.blogspot.com/2012/02/unequivocal-answer.html ) and there is no divide (though there is on in BIOS functions or you could do log lookup table based fun and games)
Quirks as I mentioned them. The vast majority of GBA games will use what is known as the Sappy format for audio
https://www.romhacking.net/documents/462/ for docs,
https://www.romhacking.net/utilities/948/ for a utility though there are some newer forks. This can be detected easily enough so there are tools to find it and handle it. Atrius' golden sun editor notes the location of pointers for various things and will go from there rather than hardcoded values which is something to contemplate, GBA pointers are also of the form 08?????? where the ?? give or take endianness is the location in the ROM so a sea of 08 a suitable number of bytes apart is probably something interesting (graphics being fairly regular spaced when you read the pointers, text being more variable but short especially if pointers are also line breaks, levels/music/... probably being rather longer. The GBA BIOS includes several decompression algorithms, run the game logging them and you can feed them to decompression tools with the added bonus of knowing what compression, where in the ROM and how long it is. Wind in some relative search (
https://www.romhacking.net/utilities/513/ ) and more general hacking approaches, possibly even some corruption, and you get even more. Even if it is data you don't care about then knowing what is is means you don't have to look there for what you do want.
