-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help! Bricked UV-K5 here #107
Comments
Some news. Getting a clue about what could be the origin of this issue, and discovered that 0x0516 "bootloader" command allows to push a 104 bytes binary chunk in device's RAM and flash it somewhere without any check. I don't have a clue about the use of that, but it could explain how I crashed my device. So, playing with this command I may have suggested the CPU to flash garbage, possibly impacting bootloader or any other critical region I don't know. Quick patches later I recovered some functionality, but screen keeps near unreadable, flickers heavily with strong lines, hangs if powersave is on, and of course, no correct battery reading. I simply faked it to permanently display 4 bars and patching other functions, effectively preventing "battery low" actions as a temporary measure :) It can TX again. I don't know if simply playing with CPU instructions could physically break something inside. Maybe it's just my bad luck! Do you think a corrupted bootloader could affect internal peripherals that way? ...sorry for being so chatty! anyway diagnosing it is still fun there :) |
Final thoughtsThis time I got it right :) Nice job, Quansheng! As in the meantime, I was so close to declare my UVK5 as dead, that I ordered a new one... For nothing. tl;dr : Don't play with UART 0x516 command. It is for factory reserved use. It aims to set a digital signature -involving unique "CPU Id" and QS keys- |
I've done something similar to mine. I used k5prog but gave it a firmware file to load to the eeprom. My radio thinks the battery is at 0.27% 0v and won't turn on. I can turn it on by pressing a key a power on. I can flash new firmware and also have dumped the eeprom from another radio using k5prog and tried to write it to broken radio. How exactly did you fix yours? |
Interesting case. It is a different issue anyway. Personally I prefer restoring EEPROM dump using python: https://github.com/Lar-Sen/Quansheng_UV-K5_Kitchen/blob/main/v2.01.31_mods/utils/eeprom_tool.py In rare cases, a wrong EEPROM may set a custom AES key, which would prevent you from restoring any parameter. In that case, I suggest you to fully wipe AES keys using below tool, as it uses a backdoor key to restore EEPROM access:
Trust me, these units are nearly impossible to brick :) Edit: As you probably lost your original EEPROM, make sure you rely on a good dump to restore. Here is one |
Nice, that totally worked. Luckily I read the readme before flashing and created a backup of the original eeprom. Now it shows the correct battery voltage on boot. Many thanks :) |
Thanks for reading the documentation and creating the backup first :) For others reading this: you can also use the image read from the radio by chirp, just cut it to the first 8192 bytes. I made the chirp driver read all eeprom by design so that people would have backups laying around.
Which option did you use when you bricked the radio? -W or -B ? -W write most of the eeprom (but without what i think is calibration data) -W should be safe, and should NOT write to places it shouldn't |
Interestingly I used -w but with the firmware instead of the eeprom backup. I was able to use the factory tool in windows to put the original firmware back which does turn on even with the battery voltage saying 0.12V 0% and it's usable. I then (thinking that the factory firmware had fixed things) flash back egzumer, which worked directly after the flash, but it failed after a power cycle. If anyone else has this problem and wants to flash the eeprom, you can get an egzumer radio to power on by holding any key down whilst powering up, you'll get a release key message, but you can then use k5prog in that state. After reading the advice here I tried with -W (which failed) and -B which worked. |
I was too confident about near unbreakable attributes of our favorite device... but this time it's for good.
Was playing with 0x0516 bootloader command. Now I painfully discovered (it's related to NVRAM programming EDIT: it is not EDIT2: It indeed IS! the command blindly program a 106 byte payload into NVRAM' sector 1) at the factory, just a little 2kb ROM section I wasn't even aware of, till today.
The device boots, CPU is fine. Screen just shows big fat horizontal lines. TX/RX/keyboard don't work, neither audio.
Trying to read display framebuffer shows garbage.
EEPROM, bootloader, main FW area are fine. Result is exactly the same with several genuine or modded FW I tried. Even FF'd EEPROM.
So I don't have my own backup, but fortunately there is one in this repo.
I own a generic ST-Link and have a basic knowledge about SWD unbricking.
If any of you successfully recovered from such a case, please let me know. NVR is only 4*512byte sectors to reflash :)
EDIT: Just used the RAM reader mod to dump NVR area : It is in fact exactly the same as the repo's dump (which was in fact a ROM section for the CPU). My assumption about me fucking up the area with cmd 0x0516 was
falseTRUE.SO.... What the issue with mine? Have you ever encountered such a failure?
The text was updated successfully, but these errors were encountered: