Build for C7000 based radio
Build for C7000 based radio
Hello everyone, I didn't see this section right away, I'm adapting OpenGD for the HR_C7000(DH4570) CPU-CSKY chip, from the work done: FM reception and transmission, DMR reception, but for now I'm stuck on the vocoder, I hope the authors of the project will be interested in this and they will help
- Attachments
-
- photo_2025-05-26_09-13-14.jpg (173.11 KiB) Viewed 736 times
-
- photo_2025-05-26_09-12-38.jpg (110.92 KiB) Viewed 736 times
Re: Build for C7000 based radio
You didn't post any information about this radio apart from it uses the C7000 DMR/DSP + MCU chip.
Re: Vocoder
Because the CPU architecture is not ARM it will not be possible to use the donor file from the GD77 or MD9600.
You have 2 options.
1. Use some other MBE vocoder for which there is source code, e.g. LibMBE. However this has legal problems
2. Reverse engineer the official firmware for this radio to locate the 3 entry points of the encoder, decoder and ECC functions used by the OpenGD77 firmware, and also find the memory address range used by all of the vocoder related functionality.
This is simple
We were able to find the function entry points becasue of work done by Travis Goodspeed for the MD380Tools, by pattern matching the function pseudo code generated by Ghidra for both the MD380 official binary and the MD9600 (and GD77)
To find the extent of the vocoder functions requires the use of a reverse enginnering program like Ghidra or possibly Radare2 etc, however I tried using a CSky plugin for Ghidra and it was not able to decode the firmware binary for the GD73, so this plugin does not appear to work with the specific type of CSky MCU which is in the C7000.
Possibly you already have a working Ghidra plugin for the C7000.... So you can compare the pseudo code for all functions in the official binary and attempt to match with pseudo code for the vocoder entry points for the MK22 or STM32
When you have found the entry points and extend of the vocoder, then you will need to change your linker file so that those area(s) are not used by the linker.
Note. The vocoder extent in the binary may not be one contiguous block, it may be multiple sections, as with the MK22 (GD77) firmware.
Re: Vocoder
Because the CPU architecture is not ARM it will not be possible to use the donor file from the GD77 or MD9600.
You have 2 options.
1. Use some other MBE vocoder for which there is source code, e.g. LibMBE. However this has legal problems
2. Reverse engineer the official firmware for this radio to locate the 3 entry points of the encoder, decoder and ECC functions used by the OpenGD77 firmware, and also find the memory address range used by all of the vocoder related functionality.
This is simple
We were able to find the function entry points becasue of work done by Travis Goodspeed for the MD380Tools, by pattern matching the function pseudo code generated by Ghidra for both the MD380 official binary and the MD9600 (and GD77)
To find the extent of the vocoder functions requires the use of a reverse enginnering program like Ghidra or possibly Radare2 etc, however I tried using a CSky plugin for Ghidra and it was not able to decode the firmware binary for the GD73, so this plugin does not appear to work with the specific type of CSky MCU which is in the C7000.
Possibly you already have a working Ghidra plugin for the C7000.... So you can compare the pseudo code for all functions in the official binary and attempt to match with pseudo code for the vocoder entry points for the MK22 or STM32
When you have found the entry points and extend of the vocoder, then you will need to change your linker file so that those area(s) are not used by the linker.
Note. The vocoder extent in the binary may not be one contiguous block, it may be multiple sections, as with the MK22 (GD77) firmware.
Re: Build for C7000 based radio
Thank you very much, Zastone UV008 radio, it is used for satcom, I found a codec, it is absolutely identical in code for both CK803S and STM32, if you want I can share the module for IDA Pro ? , I wrote it myself
- Attachments
-
- tmp.jpg (215.83 KiB) Viewed 697 times
Re: Build for C7000 based radio
this utility, the first tab is for flashing only Opengd, the second tab is relevant for stations with the HR_C7000 chip, full flash backup and recovery
https://drive.google.com/file/d/1ITVNKF ... sp=sharing
https://drive.google.com/file/d/1ITVNKF ... sp=sharing
Re: Build for C7000 based radio
C-SKY module for IDA Pro 7.6, copy to procs folder
- Attachments
-
- C-SKY(ck803s).zip
- (52.14 KiB) Downloaded 51 times
Re: Build for C7000 based radio
if you are interested I can send you the toolchain, since csky uses the old gcc 6.3.0, I had to create a new one on v13.0 and the entire OpenGD source with corrections for the UV008 station
Re: Build for C7000 based radio
Due to my current personal circumstances I am unable to do any OpenGD77 development, but if you want to share your work you should upload it to some public location where other people can download it.
BTW.
If the radio is the zastone UV008, I checked the price and its very expensive compared with the UV380 or DM1701
So, I don't think many people will buy this radio for use with OpenGD77
However there are many other radios which use the C7000 which are good value or better hardware which would benefit if someone ports OpenGD77 to those radios, e.g GD88
Re: Build for C7000 based radio
It's sad of course that you can't do this anymore, it's just hard for me too, I studied the CSKY code, but I still have to study your source code, I still can't understand why the source code doesn't initially use RTC?
Re: Build for C7000 based radio
I found all three vocoder inputs, but there is a difference with TYT, it is transferred from flash to RAM, I figured out how to include binary files cut from the original firmware, then I transfer them to native addresses, but I don’t know yet how to tell the compiler that this memory area is occupied and cannot be used for variables and procedures, can you suggest anything?
Re: Build for C7000 based radio
Your tool chain should include a linker file .ld. which definites the Program ROM addresses and size, and also the various RAM sections which are the stack and also the global memory addresses and sizeR3MDG wrote: ↑Sun Jun 01, 2025 5:06 pmI found all three vocoder inputs, but there is a difference with TYT, it is transferred from flash to RAM, I figured out how to include binary files cut from the original firmware, then I transfer them to native addresses, but I don’t know yet how to tell the compiler that this memory area is occupied and cannot be used for variables and procedures, can you suggest anything?
The STM and NXP versions, have multiple ROM sections , so that the compiler does not use the part of the official firmware binary area which contains the codec.
Originally the NXP version reduced the size of the RAM section so that the official firmware codec could use this, but I realised that the address of the global RAM buffer was actually being passed to the codec entry functions, and it was therefore possible for the OpenGD77 firmware code to allocate this buffer and pass a pointer to that buffer to the codec entry functions
If the CSky codec is compiled from the same source code, you should be also able to pass the pointer to the RAM buffer, hence you only need to modify the linker file to exclude the area of ROM which contains the codec functions
You didn't say whether the address in RAM for the codec is hard coded or whether the codec could be put into any location in RAM.
Can you see in the decompilation of the official firmware whether some RAM for the codec is allocated using malloc?
If so you could also allocate memory in the same way.