Allow UV-K5 Loaner firmware uploads

[aditaa]

Summary

• allow CHIRP’s UV-K5 driver to accept banners starting with "UV-K5 Loaner Firmware"
• prevent uploads from being blocked for the channel-only loaner build

Testing

• no automated suite available; change limited to firmware whitelist check

[aditaa]

project code for new firmware https://github.com/aditaa/uv-k5-Loaner-firmware

[kk7ds]

The project page says it was forked from the egzumer firmware. Would it not be better to bless this using that variant as the parent? Also, is there a chance that there will need to be chirp support for specific flags or something in the future? If so, it'd be better to have a dedicated subclass for this.

[aditaa]

it was forked from egzumer ... but its going to be a little off ... just used that as a base for the firmware

as for specific flags im trying to keep as much support for chirp as possible, but if you think its better for a subclass we can go that way

[kk7ds]

it was forked from egzumer ... but its going to be a little off ... just used that as a base for the firmware

Well, AFAIK the egzumer one has quite a lot of additional feature change from the OEM one. Are those things available in yours as well? If they are, then this should use that driver instead of the OEM one. If they're not (or not all) and the OEM one is still compatible and a closer fit, then it's better to stick with that.

as for specific flags im trying to keep as much support for chirp as possible, but if you think its better for a subclass we can go that way

Well, I don't want another class necessarily as it becomes a real mess to keep track of all the small differences. It really just depends if you're going to diverge or not. Changing it later is not very fun.

That said, can you please put a version number in your firmware message? It's total madness that we have so many floating around with so many differences. At least putting 1.0 in there now, having this check for 1.x and maintaining some sort of semver basis (i.e. no major changes without bumping to 2.x) would be ideal.

[aditaa]

ok i think you are right with using the different base .... i will rebuild the firmware starting with that go ahead and close this MR and i will open a new one when i am ready

[kk7ds]

I'd prefer you re-use this PR when you're ready just to keep the discussion archive together.

[aditaa]

ok re based the code to work from the factory code

also had to shorten the name to allow for version tagging

the code should just check the beginning and allow all further versioning

[kk7ds]

I guess I'm a bit confused.. I thought you had a lot of work being done in your firmware fork, based on egzumer. Thus I was expecting you to move the chirp firmware blessing to the egzumer driver subclass instead, because that's what your actual firmware was based on. The fact that you just rebased the whole firmware on the OE stuff (I think is what you're saying) makes me wonder.. why do this at all if the CHIRP driver doesn't need to change? Why not just build your firmware images with whatever OE firmware version number it's based on, with the things locked down that you're changing?

[aditaa]

i did have a good amount down on the fork .... but it wasn't useing egzumers feature set ... just restricting alot of basic features ... so i was able to redo the same work on the oem firmware ... it looks a little bit different but the functions the same and it actually save me more work down the line as i wont have to remove as much ... but i can still port in his ui pieces later

the main reason i need the chirp driver is the firmware name ... i need it to say something the end use will understand on boot and if i change the name / version numbers chirp flags it as unsupported ... and one of the biggest pieces of this firmware is that it is not programmable from the front end it has to be computer programed (chirp) and that way whey the radios are loaned out the end user has to stay on the channel we give them