Project

General

Profile

Actions

Bug #11065

open

Increase memory area read

Added by Reppad NG 4 months ago. Updated 4 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
01/08/2024
Due date:
% Done:

0%

Estimated time:
Chirp Version:
next
Model affected:
Radtel RT890 / Ruyage UV58Plus / Iradio UV 5118 plus
Platform:
Windows
I read the instructions above:
Yes

Description

Hello and Happy new year !

I am part of a project which aims to create open source firmware to improve the features of the Radtel RT890 Radio and its clones (Ruyage UV58Plus / Iradio UV 5118 plus).
We use a custom version of the iradio_uv_5118plus.py driver which works, we modified the frequency limits, the modulations, added the scanlists...
In an attempt to remain compatible with the manufacturer's firmware we stored most of new settings outside of the original settings memory area, I tried integrating that area into the chirp image and it didn't go well...

The new memory area (0x3D5000) is located after the original settings area (0x3C1000).
My intention was to increase the value of END_ADDR and _memsize to download memory from the start of the original area to the end of the new area, then add an entry in _ranges to write the new settings.
During my tests, I obtain an image which is the desired size but its content cycle the original area (basically if I double the size, I have twice the original information concatenated).
There are no errors in debug log and the addresses printed by do_download and _read_block seem good.

I tried just changing the READ_OFFSET starting address (0x7960 instead of 0x7820) leaving the size as is and I still get the original data (the joined log file).

I don't have the impression that it is our firmware that exclusively returns this address range because we have a tool that dumps the entire SPI memory (4MB) and uses the same UART commands.
This behavior is the same on a radio with the stock firmware, to reproduce you just need to change the value of READ_OFFSET, by putting 0x7960 for example and you will still obtain the data of the original area.

Do you think I forgot to do something?

Many Thanks !
Reppad

Actions #1

Updated by Jim Unroe 4 months ago

It looks to me like this is a question that should have been asked in the [chirp_devel] mailing list.

Actions #2

Updated by Reppad NG 4 months ago

If you think it's more suitable, I'll ask on the list.
Thanks for the advice

Actions

Also available in: Atom PDF