Alternate found? R13 (RPM only) downgrade to R11 (ProGrammer)

[mitaux8030]

At the heart of this little discussion is an attempt to downgrade a newer flash release that is compatible with RPM only, to an earlier version of flash that is ProGrammer friendly, without access to RPM in the first place. Here, I'm going to assume that the Feature Encryption string is already known, and that tracking data can either be redone by alignment or 'close enough' default settings are used in the interim.

According to MA-Com, the official process for downgrade is as follows:
"PROCEDURE FOR RECOVERING RADIO FROM R13 (OR GREATER) RADIO CODE BACK TO R11 (OR EARLIER)
In order to prepare to recover radios, it is necessary to change the bootloader that ProGrammer uses to the new bootloader that is installed with RPM. Once this is done, recovery can be done..."

This of course means that you need both RPM and ProGrammer to achieve this end result. I've been thinking about the situation, and find myself questioning the need to upgrade ProGrammer's bootloader, per the official process detailed above. My initial conclusions are that it should be possible with the standard Radio Maint 'Recovery' tool. No bootloader file from RPM needed. If anyone can prove me wrong by experience, or explain the fault in my logic, I'd love to hear about it.

So why do I think that the standard RadioMaint can do this? Lets start with the architecture of three radios: M-RK, LPE200 and Jaguar 700P.
Each of these radios can update their flash load via the UDC. The LPE200 and Jag even share the very same processor. And each of them have a very similar architecture as far as how a flash load gets from the UDC to the flash memory.
Generally, it goes something like this: UDC -> Processor -> common data & address bus -> flash memory E2PROM & RAM. There's also a seperate bus from the Processor to the much smaller personality/tracking data/feature data E2PROM as well.

So, anything - be it flash load, personality data, tracking info etc - needs to go through the processor. For loading the flash, this has been achieved by using a 'bootloader'. MA-Com describes a bootloader as:
"RAM Bootloader Software - downloaded by the PC programmer into the radio and executed. This software communicates with the PC using a full network protocol
(x3.28). Serial data is transferred through the radio UART [buried inside the microprocessor] for FLASH application loading, DSP code storage and personality storage. This software supports read/write of EEPROM data such as Tracking Data and Feature Encryption". MA-Com mention that a RAM bootloader is used for all three models for flash loading.

That tells me that the bootloader is being executed directly by the microprocessor (probably loads itself into RAM and then executed by the micro that way) *without* needing the assistance of the flash. Besides, the very name 'bootloader' to me implies that its job could potentially have to be done 'cold' with absolutely nothing in the flash. Which further implies that the bootloader can do its job no matter what the contents of the flash may be.

From that, I conclude that the bootloader, directly instructing the microprocessor to transfer a flash image to E2PROM, will do so no matter what is in the flash. So, even though a radio may have a very late flash version, the bootloader should overwrite it with whatever it has been instructed to. Well, that's my theory, anyway.

I've sort of proved my thoughts on a 'sacrafical' M-RK2; I was pretty brutal with it. I started with just erasing the flash, then restarting the recovery process. That restored the M-RK fine. I then managed to force a M-RK1, an Orion, an LPE and even a M7100 flash into the M-RK's flash memory, and each time a recovery did its job without any problem or complaint.

So an existing late version flash in a radio shouldn't prevent a bootloader - any bootloader, no matter what its 'version' - from loading whatever flash image you specify.

So why exactly does MA-Com specify that the bootloader for ProGrammer need to be updated to that of RPM's bootloader, before a flash version downgrade via ProGrammers Recovery is carried out?

 

[mitaux8030]

Rather than making you all read through another one of my thoughts, asking questions as I go, I'll take a different approach: ask the questions up front and then explain my reasoning.

Q: what size, on disk, is J2R13B (or later) versions of flashcode?

Still working on the assumption that ProGrammer's 'Recovery' (without updating the bootloader with that R0R08B03.bin file from RPM) will force whatever it's been told to load into flash, regardless of the existing contents... the only reason I can think of as to why this won't produce a working radio is this:
Perhaps R11 flashcode doesn't address the high page of a 2 meg flash memory, perhaps it assumes it will only ever be in a 1 meg flash. And so when the flash addresses a 2 meg flash as if it were only 1 meg, it would need to be loaded into the high page of flash memory to work properly... like when you're burning an 8k EPROM image, you'd normally use a 27C64 EPROM... but if all you have on hand is a 27C128, you'd have to load that 8k into the upper page of memory because the MSB address bit is never set, and if not set, the EPROM internally pulls that pin high. Perhaps the new bootloader from RPM transplanted to ProGrammer loads any <1 meg flash image into the high page of 2 meg flash?

But then no, I don't think thats the case, as there are very early versions of flashcode (eg J2R03A02) that were released for 2 meg flash radios, that were loaded with the standard bootloader from ProGrammer.

So I still can't see any reason why a standard RadioMaint 'recovery' (without the updated RPM bootloader file) won't work?
Comments anyone?

 

[Radioman96p71]

My "SWAG" on this would be that the <RPM bootloader contains the proper code to boot the radio into flash mode when sent the signal from anything less than RPM. Im not real familiar with how the radio and software interact but that would be my guess. Could be something as stupid as "we used the hex code xxxxx to put the radio into flash mode with ProGrammer but decided to use hex code yyyyyyy in RPM so the bootloader needs to be changed to work with it" Again, just throwin it out there

 

[mitaux8030]

Ah, good thought there! You might be on to something.

With the earliest versions of the M-RK, the flashcode writers only had 128k of memory to play with; being that limited, they'd have to be frugal with what they put into the flash, and so a 'built-in' flashcode bootloader was one of the things that got left out. When programming a M-RK, there's an obvious transfer process going on between PC and radio for the RAM bootloader... at a guess, the PC is probably downloading a flashcode bootloader to the radio RAM via the micro, and then the micro executes that code from RAM (rather than executing flash code from E2PROM as it normally would) - which then goes on to download flashcode and over-writes the E2PROM with the new code, and then resets to run the new flashcode.

But with the LPE200 & later radios, the bootloader 'loading' stage is almost instantaneous; not enough time for a bit of bootloader code to be transferred from PC to radio by the looks of it. Perhaps the bootloader formed part of the flashload starting with the LPE200, and only needed that little 'island' of a subroutine to be called by ProGrammer / RPM when required.

Yeah, that would fit what I'm observing and RadioMan's ideas, and the 'official' instruction from MA-Com of needing to update the PC bootloader code for newer versions of flash (they probably changed the location / call point of the bootloader subroutine in flash after R11 - or something like that).

Its kind of mind-boggling to think that there's 2, 4 & even 8 Meg of flash memory at your disposal these days. I come from an era where 64k was considered 'adequate' and tight, compact code was the order of the day. My old boss wrote the code for a very well known radio of the time; he mentioned that for all the stuff they crammed into it, 64k was a challenge and it came down to looking for ways to save not bytes, but BITS, to be able to squeeze it all in. Ahh, the memories (no pun intended).

 

[Radioman96p71]

I know what you mean! Its crazy these days how much flash and RAM they can cram into the smallest devices. Many cell phones now have 512MB of flash and the same in RAM! Thats insane considering some of the first generation pocketPC's only had 64MB to work with and that was being generous.

I have always been curious as to how difficult it would be to write a 'custom' flash for these newer radios. Many other devices out there have been reversed engineered and found ways to custom-code them so that they are more suitable to what that individual wants. I wonder if it would be possible to write a custom flash for Jaguars to unlock all the flash and give it more capabilities for 'scanner' users like removing the TX portion of the code and adding in some mild form of FPP to change parameters like LID to follow I-calls and such. I'm sure ive been in the garage too long with the chemicals but i dont see it being impossible

OK, back on topic, I think the next step would be to find a way to hijack the serial port being used while the radio is accessed and see just what is being said. Maybe there are some clues there? I used to have an app in Windows that would let you look into and manipulate the RAM pages used by a program, that might be handy too to see what the program is thinking. I cant for the life of me think what it was called. HDT might also be handy if you had access to a RPM programmed radio and compare the flashes to see what the differences were.

 

[ElroyJetson]

I've used a serial port monitor to monitor and record everything while reading or programming the radio and also while downloading the firmware and DSP code to file. Getting a raft of data is dead simple. Knowing how to parse it, well, that's a bit more complex.


You'd start by finding out about the chipset used in the radio. Then find some development tools for those chips. Compilers, assemblers, a list of instruction sets, debug tools. Then apply them judiciously to the firmware and DSP files and see what you can get out of them.


It'd all start there. Not a task for inexperienced software engineers, I'm sure.


I'm not sure even M/A-Com knows what it's doing, actually. I have 2008 dated firmware for a 7100 in one radio, and when you have the copyright screen displayed in the revision menu and hit the M button, the whole copyright screen scrolls...and the copyright date changes to 2006. They didn't do a full edit of even the copyright screen. Pretty shoddy...but that's M/A-Com for you.


Elroy

 

[mitaux8030]

Been thinking about this again...
and I keep coming back to my original thought... what if the flash is corrupt or even dead empty? The bootloader CANT reside in flash for this reason (and hence wouldn't be 'called' by the PC loader routine).
So my original idea still stands... the bootloader MUST be sent by the PC each and every time, and therefore regardless of flash contents, any version of bootloader would do the job.

 

[smackdaddy]

It's actually quite funny.. Even with the latest J2R18 firmware, it now says Harris when you scroll through the REV menu. Hit the "M" button and it still scrolls M/A Com (C)2006. LOL!

Cheers,
SD.

I'm not sure even M/A-Com knows what it's doing, actually. I have 2008 dated firmware for a 7100 in one radio, and when you have the copyright screen displayed in the revision menu and hit the M button, the whole copyright screen scrolls...and the copyright date changes to 2006. They didn't do a full edit of even the copyright screen. Pretty shoddy...but that's M/A-Com for you.

 

[EnidPuceflange]

Been thinking about this again...
and I keep coming back to my original thought... what if the flash is corrupt or even dead empty? The bootloader CANT reside in flash for this reason (and hence wouldn't be 'called' by the PC loader routine).
So my original idea still stands... the bootloader MUST be sent by the PC each and every time, and therefore regardless of flash contents, any version of bootloader would do the job.

Actually there are two bootloaders that are used - one in the flash that allows the personality to be read and written (which is fast to start up but can't load the flash radio code) and if that fails, a bootloader that runs from the radio RAM that is loaded by Programmer/RPM.

Later versions of the 7100 radio dispenses with the flash loader and just contains a copy of the RAM loader, so they CAN load radio code as well as personality.

As far as the bootloader that comes with RPM/Programmer (the RAM based loader) is concerned, the difference was that the newer one could load radio code over a certain size (I'm thinking 1Mb was what the Harris guy said). The older one is limited, but in the case of downgrading radio code you should be fine with the older version.

Hope this helps,
Enid

 

[Radioman96p71]

Bringing this back from the dead, I will be trying this on a radio in the very near future. Anyone with RPM care to offer up a copy of that bootloader file in case things go fubar!

Much appreciated!

 

[Radioman96p71]

Noone wants to help me out? R0R08B03.bin is all I need, just a simple bootloader file. Doesnt even have to be a newer version of RPM, all versions will have it. Anyone... anyone? Bueller?

Thanks in advance!

 

[Radioman96p71]

Nevermind, figured it out myself! Saved me 100 bucks to send it off.