(no title)
the_biot | 21 days ago
As somebody else suggested, try Ghidra's decompiler. It produces very sloppy C code, but still reads faster than assembly most of the time.
Now enriching Ghidra's decompiler output to clean up the C code, that would be a neat trick, and one that Ghidra isn't doing.
mattst88|21 days ago
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|20 days ago
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.
rasz|21 days ago
speaking of PC BIOSes there is/was a great disassembler called Sourcer https://corexor.wordpress.com/2015/12/09/sourcer-and-windows... with its Bios Preprocessor producing very readable sources full of comments and enumerated hardware IO.
Author of Sourcer Frank van Gilluwe also wrote a somewhat companion book "The Undocumented PC, A Programmer's Guide to I/O, CPUs, and Fixed Memory Areas".
mattst88|21 days ago
I'll give Ghidra a try!