[mattst88]

I've loaded the PROM in Ghidra. The ability to decompile to C is great.

I looked at some particular parts of the PROM that took a while to understand to see if I could have understood them quicker with Ghidra. In particular, the part of `sloader` that searches for the `post1` and `firmware` sections and then calls `post1(&firmware)`. Given that I already understand how this works, I can see that this is happening from the decompiled C, but the lack of labels, comments, etc really hampers my ability to understand from the decompiled C alone.

This might all be down to inexperience with the tool.

The ability to iteratively add a label, rerun the decompiler, reread the decompiled assembly, make more inferences was really the key to building an understanding for me.

Another aspect I'm unsure how to handle in Ghidra is that the base address differs between sections of the firmware. E.g. the `firmware` section is copied to RAM and executed from `0x81000000`. It's not clear to me how to configure this in a granular way, rather than a single base address for the whole PROM image.

[the_biot]

Annotating the decompiled code is very much part of the workflow in using Ghidra, but the UI is not really intuitive. If you right-click on variables, function names etc there are a bunch of options for annotation. You can also edit the function signature, which can cause the decompilation to improve.

I know you can do various base address manipulations, but your case seems like it would be hard -- the base address is in the file, or has to be calculated.