[chirp_devel] Memory area modification
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.
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 !
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).
FWIW, I think your CHIRP changes are correct - meaning, you should be able to just extend the address that you read from to include the new area. However, the behavior you're seeing is exactly what I see when I read past the end of lots of radios that support address-based operations. I assume the radio has a sort of "modulo memory size" behavior implemented in the read command internally. Thus if you provide an address larger than the max it is expecting, you wrap around to the beginning.
You could also check and make sure that the read command isn't wrapping around due to the actual width of the field. It looks like the driver reads blocks and uses a 16-bit field to do so, but also applies some READ_OFFSET value that is pretty large. So if the block you're trying to read is past the end of READ_OFFSET+blocknum, you might be wrapping back to zero.
So, I haven't closely examined that driver and mentally applied your changes, but a quick glance makes me think that's all that should be required. Thus, I suspect there's something else going on in the radio, like some cloning code that needs to be changed, in order to read the later regions. The fact that you see the same behavior with an unmodified radio supports this theory, IMHO.
--Dan
Hi,
The fact that you've confirmed that the way I've modified the chirp driver should be enough is already a step forward! We'll keep on looking at the firmware, especially why things work with the memory backup tool.
Thanks for your help!
Le mer. 10 janv. 2024 à 00:07, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> a écrit :
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).
FWIW, I think your CHIRP changes are correct - meaning, you should be able to just extend the address that you read from to include the new area. However, the behavior you're seeing is exactly what I see when I read past the end of lots of radios that support address-based operations. I assume the radio has a sort of "modulo memory size" behavior implemented in the read command internally. Thus if you provide an address larger than the max it is expecting, you wrap around to the beginning.
You could also check and make sure that the read command isn't wrapping around due to the actual width of the field. It looks like the driver reads blocks and uses a 16-bit field to do so, but also applies some READ_OFFSET value that is pretty large. So if the block you're trying to read is past the end of READ_OFFSET+blocknum, you might be wrapping back to zero.
So, I haven't closely examined that driver and mentally applied your changes, but a quick glance makes me think that's all that should be required. Thus, I suspect there's something else going on in the radio, like some cloning code that needs to be changed, in order to read the later regions. The fact that you see the same behavior with an unmodified radio supports this theory, IMHO.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
participants (2)
-
Dan Smith -
Tommy