Importing ROM data imports as RAM about ghidra_i960 HOT 6 CLOSED

@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).

from ghidra_i960.

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.

from ghidra_i960.

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.

from ghidra_i960.

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)

from ghidra_i960.

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.

from ghidra_i960.

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.

from ghidra_i960.