OpenGD77

• It seems the radios (including its RT72 variant) are now discontinued
• There seem to be two versions of the model (-V1 and -V2). All radios I had have V1 bootloader and it is possible somebody bricked theirs V2 using the V1 bootloader code from the report.
• There are no Left/Right buttons and there is no rotary encoder, so the button mapping for usage would have to be redesigned against other OpenMDUV380 like radios
• The memory structure of the radio (V1) uses sectors where last byte in each sector identifies the sector type ID (probably to ensure wear-leveling and/or journaling of sectors), so the factory calibration values would be placed randomly in codeplug part of SPI flash memory - again, this section would have to be found first by the firmware and copied/moved to some fixed point, or a data file with the stock CPS would have to be loaded which contains the calibration data always on the same position instead. Also the type of calibration data points differs from the other radios, and frequencies are recorded in it in BCD (binary coded decimal) format. For the structure of calibration data I was able to identify in CPS data file refer to the attached image, offsets in the sector are the same, but subtract 0x2000 from the offset (L1* and H1* values are the power settings like those in OpenGD77 for 1/5W) but the chosen frequency for calibration point is not clear.
• As a side note, the firmware code starts at 0x8008000 not at 0x800C000 like in MDUV380-like radios (plus at 0x8004000 there is a block with some model information, anti-clonning checksum of CPU ID, etc.).

OK2MOP wrote: ↑

Wed Jul 19, 2023 9:09 am

Just a few comments if anybody is still considering the porting/reverse engineering it from an owner of several of these radios and a person who extracted the stock firmware from the radios, wrote a flashing tool in Python, and mapped some of the codeplug memory:

There have been experiments with alternative firmware without DMR for this radio, which partly works (not by me). HW is similar to RT3s, but there are two possible issues which may prevent you from finishing the port:

• It seems the radios (including its RT72 variant) are now discontinued
• There seem to be two versions of the model (-V1 and -V2). All radios I had have V1 bootloader and it is possible somebody bricked theirs V2 using the V1 bootloader code from the report.
• There are no Left/Right buttons and there is no rotary encoder, so the button mapping for usage would have to be redesigned against other OpenMDUV380 like radios
• The memory structure of the radio (V1) uses sectors where last byte in each sector identifies the sector type ID (probably to ensure wear-leveling and/or journaling of sectors), so the factory calibration values would be placed randomly in codeplug part of SPI flash memory - again, this section would have to be found first by the firmware and copied/moved to some fixed point, or a data file with the stock CPS would have to be loaded which contains the calibration data always on the same position instead. Also the type of calibration data points differs from the other radios, and frequencies are recorded in it in BCD (binary coded decimal) format. For the structure of calibration data I was able to identify in CPS data file refer to the attached image, offsets in the sector are the same, but subtract 0x2000 from the offset (L1* and H1* values are the power settings like those in OpenGD77 for 1/5W) but the chosen frequency for calibration point is not clear.
• As a side note, the firmware code starts at 0x8008000 not at 0x800C000 like in MDUV380-like radios (plus at 0x8004000 there is a block with some model information, anti-clonning checksum of CPU ID, etc.).