[chirp_devel] Memory area modification

[Tommy]

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 at 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 at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20240112/e609fa08/attachment-0001.html