How should the 8051 processor module be modified to support a target that uses code bank switching?

[cyrozap]

There are some 8051 microcontrollers that are standard 8051 (not 80251 or 80390) cores but support >64kB of XDATA using a third data pointer SFR (e.g., DPX / SFR:0x93) and use code bank switching to support >64kB of CODE / PMEM using a bank-switch SFR (e.g., PSBANK / FMAP / SFR:0x96). I'd like to be able to use Ghidra to reverse engineer code for these kinds of microcontrollers, but the current 8051 processor module has some problems with this.

Supporting the extended XDATA space is straightforward, since the DPX register gets used for every access to XDATA, so it should simply be a matter of widening the EXTMEM address space and making sure that all instructions that perform XDATA access have DPTR prefixed with DPX.

Supporting the bank-switching may be more complicated. In microcontrollers with this kind of 8051 core, there's two "regions" of the CODE / PMEM space: a common portion that can be accessed regardless of the current setting of the bank-switch register, and a banked portion that can be swapped between some number of code banks. As I understand it, the banks only get changed after executing a jump instruction--simply setting the PSBANK / FMAP register to a new value is not enough, at least not for a MOVC instruction to read from the selected bank. Furthermore, because code for these microcontrollers is normally laid out linearly, simply prefixing the jump target with the bank number in PSBANK / FMAP won't point to the correct address in physical code memory. And it seems trampoline functions (depending on the specific firmware implementation, sometimes there's just one that takes a bank number + 16-bit address, and sometimes there's one for each bank) are used to access functions in the different banks. I'm not sure how to handle all of this in a way that would keep the decompiler happy and properly generate xrefs between all the code banks.

If anyone has any ideas for how to approach these issues, I'd be happy to hear them!

[gtackett]

Code bank switching is a feature of the Silicon Labs (originally, Cygnal Integrated Products) CIP-51. It also has an extended data memory space, support for flash memory, and on-chip extended RAM (XRAM).

CIP-51 devices which support over 64KB of flash have a one byte SFR (PSBANK, at SFR address B0 for the F12x or F5 for the F58x/F59x) which can be used to map Bank 1 code and (separately) constant fetches to any of up to four banks in the (up to) 128KB flash memory space. Code/constant fetches from addresses 0000 to 7FFF (the lower half of the 8051 program address space) always use Bank 0, while code/constant fetches from 8000-FFFF can be mapped to Bank 1 (the default, corresponding to the upper half of the base 8051 program address space), 2, or (for devices that support 128KB flash) 3.

CIP-51 also uses a page scheme for SFRs, with pages numbered 0, 1, 2 and F. Some SFRs like PSBANK and DPTR are of necessity available on all 4 SFR pages, while many of the CIP-51 peripheral registers are located only on a specific page. The architecture also supports automatic SFR page switching on interrupts.

I intend to open one or two issues to address specifically the CIP-51 code banking and SFR paging . The details are well documented in SIlicon Labs literature.

[gtackett]

From what I know (not a lot) about how Ghidra processor models work, I suspect that a Ghidra mechanism called a context register would be used to implement storage access instructions that are dependent on a hardware register.

[cyrozap]

CIP-51 has a 16 bit data pointer (DPTR, made up of subregisters DPL, 0x82, and DPH, 0x83) which works in conjunction with the 16-bit form of the CIP-51 MOVX. The chip also has an 8-bit MOVX which uses R0 or R1 instead of DPTR.

This is standard for all 8051 variants, is it not? In either case, on the chips I've been looking at if the DPX register is ignored, MOVX works the same way with the address space limited to the lower 64 kB.

CIP-51 also uses a page scheme for SFRs, with pages numbered 0, 1, 2 and F. Some SFRs like DPTR are of necessity available on all 4 SFR pages, while many of the CIP-51 peripheral registers are located only on a specific page. The architecture also supports automatic SFR page switching on interrupts.

The chips I'm interested in don't have paged SFRs--they use the expanded XDATA space for memory-mapped registers.

[gtackett]

In response to the comment from @cyrozap I've edited my comment to describe CIP-51 code banking, which was my intended topic before brain drift led me to write about data banking.

The main point I intended to make, though, is that Ghidra context registers will likely be needed for Ghidra to deal with both code and data banking, as well as SFR paging, . (I haven't yet looked to see if Ghidra already has a context register for data banking.)