Fujitsu FR60/80 Support

Summary

I developed a FR 60 Plugin and I would like to upstream this work. I am unsure if the maintainers of this project are interested in accepting this functionality to mainline. If there is interest, would it be for generalizable functionality of the architecture or the core specific features as well.

I am also wondering what the best avenue is to ask questions regarding this work if I have any (github issues perhaps?).

Details

I am working on analyzing the DVR processor in the Sony PSX which uses the Fujitsu MB91302A processor.

To aid with this I’ve built a Ghidra plugin which enables decompilation of the firmware and automatically setting up memory space and identifying & labeling registers and Fujitsu uTron kernel system calls.

This plugin is available on my github here: https://github.com/desrdev/ghidra-fr60

This was developed with a single goal in mind, and after completing the work I spotted the following projects targeting similar goals and architecture: https://github.com/simeonpilgrim/ghidra_fujitsu_fr https://github.com/ammaraskar/ghidra-fujitsu-risc

With the exception of ghidra-fujitsu-risc, the projects are released with compatible licenses to Ghidra. Both projects are targeting a single processor on a specific kind of device however and are not truly general plugins for the Fujitsu 32bit processors.

From a quick glance, all three of our implementations are fairly close to each other which suggests the CPU instruction architecture can be generalized across all 32bit Fujitsu processors.

Fujitsu no longer manufactures or advertises these components, however Infineon/Cypress do market these cores and they are still in active use today.

Given that the core is actively used and there are now 3 separate targets repeating work, I feel there is a case to be made to upstream some part of these projects to Ghidra mainline to allow reuse of the generalizable aspects of all three of these projects.

I am open to doing this work and maintaining this new feature, but I am unfamiliar with the process, style guide, and best practices when designing Ghidra cores or contributing to the Ghidra project in general.

Even in my own plugin there are features and functions I wish to add, but I am not sure of the idiomatic way to approach them.

To reiterate, I am willing to do the work required to get this mainline ready, and the plugin I developed is fully functional and I use it almost daily, but I will likely need some assistance to do so and I understand if the maintainers do not have the bandwidth/interest to take this on.

Thank you for your time.

[emteere]

Should you choose to submit a PR, a processor specification used in a wide number of devices would be acceptable. We can’t make a judgement call on whether the work is worthwhile for you to undertake. The ghidra community will try to help/answer questions as bandwidth allows should you need guidance. Processors in general are usually fairly contained and don’t affect the rest of Ghidra, so they are easier to review and accept.

Also acceptable would be scripts/extensions/loaders/analyzers that are generic, such as formats (ie: elf), or a larger general development framework that have a wide usage across general software (ie: gcc). In general, we can’t accept any scripts/code that specifically targets a vendors platform or software, especially game systems such as the PSX.

We would be open to including the processor in the baseline distribution. It should be generalized, as you mention, to target the base instruction set that is common across the variants for the processor family. Registers for a very specific device variant may not be acceptable depending on their generality across other devices/variants.

The processor would need to go through a code review before inclusion in the baseline. It is highly recommended to implement the automated PcodeTest for the processor if there is an available C compiler. It helps both you the developer and reviewers to know that the pcode semantics are sound. I would endeavor to create a sample binary that is from open source code such as our pcode unit test code so the bytes are easily shareable/reproducible.

If you plan to submit a PR, please submit one for only the processor related artifacts.

If you think there are general plugin/loaders/scripts that we could accept as well, submit that as a separate PR. I’d keep each PR very targeted to a specific topic for example one just for an ELF loader modification to handle the FR60. The more focused/self contained a PR, the easier it is for others to consider and comment on.

We can’t promise any level of responsiveness, as there are definitely other processors or issues that are of higher priority. However getting the breadth of processors available for someone who might need it in the future is a worthy goal. You can look at other processors for general style, or to see how similar processor features are implemented (ie: zero overhead loops). Any questions should be general to Ghidra or reverse engineering with ghidra related, and not targeted at any particular device or binary unless legally available to the public such as a binary compiled from open source.

Processors can take a while to develop and review by the Ghidra community, as you can see from the backlog. Each one has some unique feature that can stress sleigh processor modeling. However, we appreciate the effort!

[DiscoStarslayer]

Hey @emteere. No further questions. Thank you for the assistance. I managed to build the test cases using gcc, the architecture is simple enough that the ABI is identical between that and the proprietary Fujitsu compiler.

The test suite identified a lot of subtle errors and I’m now at 98% test coverage. Thank you very much for pointing me in this direction as it greatly improved the disassembly.

Looking forward to closing out that last 2% and preparing a PR sometime in the future. I will close this ticket 😄