The GXP series phones from Grandstream form a robust platform that follow a highly consistent architecture.
The processor is a TMS320VC5501PGF, a DSP processor from TI that has downloadable compiler support and lots of data sheets. This is a chip with lots of internal expansion hardware. It is purely a DSP, so without any other processor such as ARM included.
The address space is divided in four spaces, externally shown as signals /CE0 to /CE3. These spaces are assigned as follows:
Space Contents CE0 Network chip? CE1 Flash memory (generally 2 MB) CE2 Dynamic RAM (generally 4 MB) CE3 Buttons, LEDs, LCD
Each of these spaces can be configured with individual timing constraints. As a result, the fastest RAM access is possible while the peripherals of buttons and LEDs are addressed in a modest pace.
The crystal frequency driving the DSP is 19.6608 MHz, which falls apart in factors 3.5^2.2^18 so after a PLL multiplication with 15 it runs the CPU very close to its maximum of 300 MHz, but can still be used to derive frequencies like 8000, 16000, 48000, 96000; just not the mad frequency 44100 (which is 2^2.3^2.5^2.7^2 so it seems to be a misfit by design).
The network chip is usually a KSZ8842-16MQL, which includes a switch with two external ports. The chip is modern in that it supports IPv6 multicast (MLD) and can go up to speeds of 100 MHz. I have seen an (early?) GXP-2020 model based on RTL8019AS with an extra switch in an RTL8035CS, but that line of chips has clearly been abandoned for the rest of the GXP models.
The sound codec is a TLV320AIC20K. This chip is configured over I2C and further operated over TI's multiple-channel serial port protocol, using the DSP's McBSP1 port. The DSP generates the sample rate because the codec is setup as a slave; awkwardly, the codec will also generate the rate internally, because it needs an oversampling rate. I would definately have setup the codec as a master to avoid having to specify the samplerate in two locations.
The keys are organised in a matrix, usually N*5, where the five lines connect to lines of McBSP0 that are dedicated to GPIO input functions: CLKR0#17, CLKX0#20, FSR0#19, FSX0#23 and DR0#18. The N driving lines are connected to the high part of the 16-bit databus, so D8-D15. A tri-state buffer ensures that not all data bus traffic flows to the keyboard.
The LEDs are two-colour LEDs, consisting of a red and orange LED which can be driven independently. The only exception is the MESSAGE LED, which is only red. Each LED has a common ground and either the reds or the greens are all driven simultaneously. This architecture makes sense, but it requires constant switching between red and green to enable combinations of the two colours. Note that it is possible to combine red and green colours by driving both. Most LED common ground values are stored in octal D-FF chips, but the MESSAGE LED is an exception -- it is directly driven from the inverse of the XF output of the DSP. Since it is also subject to the general red and green drivers, it has to be an awkward part of any driver code, making it impossible to switch from DMA.
The LCD is graphical, and black-and-white. They have an integrated driver chip, making for a plug-and-play solution. It is very difficult to determine how these displays are driven.
Generic logic chips used are: