Well there's some truth there, but what truth I'm aware of should not scare anyone off from using chirp with Yaesus.
Back in early 2014 I was doing some chirp code development on FT-60s, fixing some bugs and with the eventual goal of adding "Settings" control. Someone else has since done that.
Part of that process is mapping the memory by twiddling bits in the image, uploading to the radio, and seeing through the radio's button interface what changed. It went pretty smoothly for a while, then I managed to brick *TWO* FT-60s. One of which was repaired by sending it to the factory to replace an eprom.
I'm not going to add any further detail here, my investigation was pretty thoroughly documented in a thread on the chirp_devel mail list with subject "How to brick an FT-60" starting 3/22/14. See also Bug #1547: [FT-60] Chirp should check parity on download.
But normal use of chirp to program radios doesn't do this. The user interface only lets you make limited, well understood changes to the radio image bitmap. I still do that with mine.
-dan
Date: Wed, 27 Mar 2019 22:05:06 -0600 From: Larry Lovell larry.lovell76@gmail.com Subject: [chirp_users] Programming Yaesu Radios using CHIRP To: Discussion of CHIRP chirp_users@intrepid.danplanet.com
Has anyone had a problem programming a Yaesu radio with CHIRP? Someone mentioned that their Yaesu was damaged and had to be sent to the factory because CHIRP had overwritten some code controlling the processor. It also had to be re-flashed. Since I don't fully understand how CHIRP works this doesn't make sense to me, but knowing manufacturing companies, they may share Channel Memory with processor memory and not think much about it. Thanks for your information.