Importing ROM data imports as RAM

[biggestsonicfan]

I'm not sure if this is a Ghidra 9.1.2 thing or specific to the language definition, but in the disassembly, the header lists the memory map as ram and follows that with the address space ram: 00000000-000fffff. Renaming the area to ROM in the memory map alters the first instance of ram to ROM but not the address space listed. I'd like to assign the actual RAM space to 0x500000 with a length of 0x100000 and a secondary RAM allocation at 0x200000 for the length of 0xCF218.

[mumbel]

@cglmrfreeman ram in this view is just the Ghidra view of memory, but yes, I specified that name in my code (register is the other which just represents the register map, but that shouldn't be viewable).

When you load the binary into ghidra, after selecting the processor you get to the screen that has 4 fields (something like loader type, processor, filename, project name) and buttons (ok, cancel, options). If you click options you can change the base address for the file you have loaded (0x500000 in this case), otherwise any file it will load will probably be zero base addressed.

If you've already loaded into ghidra, you can move it and add additional memory segments using the Memory Map window (Window->Memory Map`) or its the little icon that looks like computer chip. From here you can add new segments, rebase, resize, rename, permissions, etc...

If your new memory is uninitialized data, like setting up a .heap or .bss, then you can just add here. If you're wanting to add like .data or other initialized data, you can File->Add To Program and then just use that Options button to set the base address of the new bytes you're adding.

Not saying one way or the other, but this module should be fine in any version of ghidra, so you can upgrade to 9.2.4 or 10.0 beta w/o issue, just need to put this in to that Ghidra/Processors/ directory. I typically work on this in master from source and run out of eclipse so should be fine with any released version. A lot of improvements have been made in terms of resource management and output which might be helpful for RE and regular usage of the tool. You can make a backup by exporting the file you're on or you can even just copy/paste in the tree of projects, but when you open with a newer ghidra it may ask to upgrade the project (the last change I added to this repo would do so as well).

[biggestsonicfan]

If you click options you can change the base address for the file you have loaded (0x500000 in this case), otherwise any file it will load will probably be zero base addressed.

Well, yes, but that is if I load the ROM from the start as RAM (the address for the RAM for the Model2 hardware begins at 0x500000), which I'm not. I am loading the ROM data.

I can do this:

But I still end up with this in the header of the disassembly:

I've also mapped the memory fine like this:

It's just annoying to have ram: 00000000-000fffff in the header comments. I can live with it though.

[mumbel]

Ah, I see. ram and register are just the naming conventions I've seen across the processor modules (their internal types of address spaces are ram_space and and register_space). its basically addressable memory or "addressable" registers. I can change the name to something else, but its the same name for the whole addressable memory range/memory segments.

[biggestsonicfan]

Ah, then leave it I guess. I am finding all sorts of interesting quirks and things that are just plain different in Ghidra that leave me uncomfy, lol.

Such as the disassembly syntax changing for seemingly no reason:
One moment it's this:

The next moment it's this:

And how data is represented like this by default:

Where the stob operation is storing the byte of r3 to 0x1C0000A, but it should properly be represented like this:

And maybe have a comment that this resolves to 0x1C0000A. Otherwise this makes it look like the bytes disassemble to stob r3, 0x1C0000A(r11) and not stob r3, 0xA(r11)

[mumbel]

the add_BACKUP_TO_RAM could be some instruction issue on how the address+offset gets calculated. Is that text changing from function to function or like the same function, but after it refreshes or going to another function and back?

I'm not sure how/if you can get the non-markup text in the listing view. I'm not seeing any settings at a glance that would turn that off. I know just reading the instructions with their API it would just be 0xa case (so its probably a setting somewhere, but not sure). I know some scalar access would do like stob r3,0xa(r11)=>DAT_01c0000a or stob r3,0xa=>DAT_01c0000a(r11) and no clue really why it picks one vs the other. I guess all my RE, that's preferable since I don't care as much about the literal instruction text and the markup is better, so have not really with messed with it.

[biggestsonicfan]

I got my answer and it's particularly stupid.

When you do the first auto-analysis, all those settings are fixed and apply to any future analysis on the disassembly. If "Basic Constant Reference Analyzer" is checked, and it is by default, it results into what I was complaining about.

However, this takes away the convenience of having memory addresses auto-referencing, and the hints of saying 0xa(r11)=>DAT_01c0000a is just gone.