The firmware images don't appear to be signed, so they could be modified easily
I wouldn't be so sure.
Oh, don't worry, I'm rarely sure of anything
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
I did later amend some of this to reflect some uncertainty --
https://www.eevblog.com/forum/index.php?topic=30.msg2824#msg2824There's no room for a hash, so you could do whatever you want to the file.
There's no room for a hash in the header, but that desn't mean that one (or a CRC) isn't embedded in the firmware images, to detect corruption or tampering.
[
"Hash" was a poor choice of words on my part. There's no obvious sign of a cryptographic signature, or a hash, or even a CRC. The former would be the only real form of protection that would let them "fix" the problem -- the latter two could be reversed, given enough time and energy.
I've yet to see a system that used hashes or signatures that didn't have them in a fairly obvious spot. Especially if there's a nice header with other metadata. Doesn't mean it couldn't happen, but I find it unlikely.
Unfortunately, this means that there's no sort of bootloader which could recover corrupted firmware, so your options would be to desolder the NOR flash holding the firmware and reprogram it using a chip programmer, or try to get the 13-pin JTAG-looking connector working.
Actually, there IS a bootloader in the BlackFins, in protected space. But I doubt it would have the ability to read files off a USB stick. So in that sense, you may be right that once corrupted software was loaded, recovery would be difficult.
OR, they may have a dual-image system, where they can load a 2nd set of firmware into the other half of Flash, but not toggle control over to it until it had been successfully validated. Otherwise, once they started a reflash cycle, they'd have to blow away the original firmware first. From which point there'd be no recovery on power fail or by the time it knew the image it loaded was bad.
That could explain how they utilize 8 MB of Spansion Flash, when the firmware only occupies 4 MB. And during operation, the remaining 4 MB can be scratchpad space (like 1 MB for Reference waveform memory, as Andreas and Drieg pointed out).
I was just plain wrong about the bootloader. There are at least two, one of which has me mystified:
1) There's the BlackFin standard bootloader, the one you're referring to. It can boot from a NOR flash (or other external memory), or a SPI master, or a SPI slave, depending on strapping. (Ref:
http://www.analog.com/static/imported-files/data_sheets/ADSP-BF531_BF532_BF533.pdf page 14)
2) There is an unknown mystery second-stage bootloader somewhere. BMODE1 is tied hard to Vcc, and BMODE0 is pulled low with a resistor, which means that the BF is acting as a SPI slave, and being fed code from some unknown place over SPI. It's possible the entire firmware is loaded over SPI, but it doesn't seem likely to me (not in the normal boot case). That being said, I can't find any place where that could be coming from -- nothing looks like a SPI flash, and 15 minutes of poking around with a DMM didn't find anything connected to the SPI lines except for the edge connector. The only place I can think that they might even be possibly hiding it would be the Lattice CPLD, but I couldn't find any connections between the BF's SPI bus and the Lattice chip.
I think that that second-stage bootloader is probably fairly small, and it probably loads the rest of the firmware from the NOR flash. I don't know why they bother doing this, instead of booting from the NOR flash directly -- they could be doing some sort of verification in there, but my gut feeling says they're not. The SPI lines (as well as BMODE0 and PF2 aka SSEL) are run out to an edge connector right next to the I2C EEPROM, and I believe this is what is used in the factory to load the initial firmware onto the device. These same SPI lines should be what carries the normal bootloader, but I haven't had a chance to open my scope back up and watch those lines with an LA -- if anyone else does that, I'd love to hear about it, because now it's bugging me.
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
The dual-image idea doesn't seem very likely to me either -- but at this point, I'm just guessing because I have nothing to go on and am too much of a coward to risk bricking my scope to prove a point
![Sad :(](https://www.eevblog.com/forum/Smileys/default/sad.gif)