Having issues with the built firmware on macOS

[majonez]

If you don't like his/theirs (developers') decisions, don't use the product. If you don't have time to test, then don't.

As I said to another whiner, just walk away. Bye...

No point to comment that. Really mature attitude.

P.S.
And if you ask what rights I have to comment, I earned my rights by doing a small part of beta testing for Roger since the beginning, even before this forum and before public testing.

Bye now...

Wow, if you're so glorious, then you must have a power to kick me from here. Don't be ridiculous.

[oh1fss]

I spend literally hundreds if not thousands of hours a year on this firmware and the CPS

Thanks, impressive work!

If you publish the source code, others can help finding bugs and even help developing new features. That's how Linux has become so great. Linus Torvalds has not done everything by himself, but he started it and now coordinates the development. He is a hero.

[EA5JAQ]

I just can't imagine how frustrating must be to spend hundreds of hours working in a project like this and rejecting donations to stick to the ham radio non-profit principles, to later learn that someone is charging money for you've done for free. If Roger and the developers want to stop publishing the source code to protect their work, it's their hard-earned right to do so. As a developer, I felt really sad when I read that they wouldn't be updating the github repo. I've been playing around with the code for a couple months now, I'm still amazed at it and I'd love to see the lastest changes (what they've accomplished with the Eco Levels, and the endless list of bug fixes is just impressive), but it's their decision and it needs to be respected.

If I may suggest, as having different people helping out in whichever way they can (as someone mentioned before) can be really helpful for the development of the project (not to mention the educational potential of this project), what I'd do is release it under some sort of registration system, where if someone wanted to download the full code, they'd have to send a request (including their callsign, etc) agreeing to a strict licence, and the devs would decide if they get it. I don't know if that's actually possible, but if it was it'd be a good way to release it avoiding licence breaches (or at least, tracking who breaches it).

Anyway, it's just an idea to try and keep everyone happy and helping out, but the developers have got the last word on this, and after all the work they've done for free (and all they've done for the ham community) we must just give them all our support. Btw, congrats for the last version.

73

[VK3KYY]

I do share the code with core developers and supporters who work on the RF etc, but at the moment, because of commercialisation, and people ignoring the copyright and license wishes of Kai, the original creator of the project,, I am not willing to make it fully public.

There is nothing prevent anyone from developing new features like Single Frequency Repeater using the publicly available code, as the core has not changed very much, and I could integrate any significant new features into the latest code

Or perhaps investigate the DMR admit criteria
Or DMR talk permit tone when the repeater is already transmitting
Or look at the RD5R DMR Tx pulse envelope problem
Or the problem with the Voice Prompts occasionally causing a crash
etc
etc

I have started to maintain the legacy / publicly available code, with bug fixes from my private code, e.g. Fixes to the MCU PLL settings and also change to the I2S optimisation and also the DMR audio pipeline, and a bug fix for the DMR filter, were all updated in the public repo last week.

The CPS repo is fully public, and again with loads of things that people would like, e.g. the ability to re-order the Channels, but I never received a PR for the CPS to add any new features like that


I do not accept arbitrary changes to the UI etc of the firmware, as often they are not well thought through and do not take into consideration the wide range of operating uses or backwards compatibility, or multilingual considerations etc.
And bug fixing submissions often takes me longer than it takes me to write the change myself.

People are free to make suggestions on the forum and have them discussed for merit and feasibility of implementation, however I have removed the "Feature requests" section some time ago, because we are virtually at the limit of what is capable with the hardware and the limited space for both the firmware application and also things like additional fonts or a lot of changes to voice prompts, etc

[Arnie97]

I apologize sincerely to the developer team for my impertinent reply. I was just a bit surprised as a newcomer, and never meant to offend anyone or start an argument; unfortunately I've screwed things up. I would definitely appreciate your great work even if it was closed-source from the beginning.

For any newcomer who's trying to build the source code from scratch, I'd recommend either Linux or Windows as the developing platform, as I could build a working binary with the latest MCUXpresso on these platforms without any hassle. Don't run the plain make directly from the command-line though; the IDE will generate a new makefile on its own, under the path $workspace/Debug_GD-77/makefile (or $workspace/Debug_Foo/makefile if you chose another target platform Foo). I'll investigate what's going wrong with macOS later.

73

[VK3KYY]

We use windows and Linux using the MCUExpresso IDE.

Someone made a standalone makefike but is not actively supported and the firmware may no longer run correctly if you try to use the makefike because all files except codec.c now are set to -Os

Because of possible patent problems the source code does not include an AMBE codec, the firmware uses the AMBE codec binary from the original official firmware.
And the binary sections from the original firmware are linked with the compiled source code to make the final unencrypted binary.

But its not possible to publish even the unencrypted binary sections, so there is a Exe tool in Linkerdata to download the official firmware binary and decrypt it and extract the 2 AMBE binary sections.

If you don't run that exe you will not have the AMBE bin sections and it will not link.

You can run that tools in a Windows VM and make those files and copy them back to you Mac files and it should then link OK

[Arnie97]

And the binary sections from the original firmware are linked with the compiled source code to make the final unencrypted binary.

If you don't run that exe you will not have the AMBE bin sections and it will not link.

You can run that tools in a Windows VM and make those files and copy them back to you Mac files and it should then link OK

Thank you for the clarifications, but I did have the AMBE bin sections. I compiled tools/codec_dat_files_creator/codec_dat_files_creator.c with libcurl on my Mac and it worked well. Actually I could link everything together and get the final sgl binary. The problem was, my radio doesn't boot any more after I flash the firmware built from Mac into it.

[VK3KYY]

And the binary sections from the original firmware are linked with the compiled source code to make the final unencrypted binary.

If you don't run that exe you will not have the AMBE bin sections and it will not link.

You can run that tools in a Windows VM and make those files and copy them back to you Mac files and it should then link OK

Thank you for the clarifications, but I did have the AMBE bin sections. I compiled tools/codec_dat_files_creator/codec_dat_files_creator.c with libcurl on my Mac and it worked well. Actually I could link everything together and get the final sgl binary. The problem was, my radio doesn't boot any more after I flash the firmware built from Mac into it.

Hard to say exactly whats causing this.

Which radio do you have ? RD5R ??

[VK3KYY]

And the binary sections from the original firmware are linked with the compiled source code to make the final unencrypted binary.

If you don't run that exe you will not have the AMBE bin sections and it will not link.

You can run that tools in a Windows VM and make those files and copy them back to you Mac files and it should then link OK

Thank you for the clarifications, but I did have the AMBE bin sections. I compiled tools/codec_dat_files_creator/codec_dat_files_creator.c with libcurl on my Mac and it worked well. Actually I could link everything together and get the final sgl binary. The problem was, my radio doesn't boot any more after I flash the firmware built from Mac into it.

I checked your first post and you said you have a RD5R

I've just built the version from github and uploaded it to my RD5R using the CPS and it boots OK.

Which would suggest somehow the build went wrong for you.

I presume you have run bin2sgl to convert to encrypted binary before uploading ?

Take a look at firmware.bin , produced by the IDE, with a hex editor, and check it looks vaguely like a ARM binary.
(lots of 32 bit vector addresses at the beginning, a lot of them will be the same.

You could also run strings on it and see if you can see all the strings.

Also, make sure you have selected the correct build target etc.

Then check the sgl file looks vague OK. It will appear mostly like random bytes apart from the header.

[VK3KYY]

FYI.

Some fixes have been pushed to the repo on github, and also the development branch in the repo has been removed as its now redundant.