First Blackfin lessons
433 views
Skip to first unread message
tgaz
Jan 3, 2012, 3:02:33 PM1/3/12
to Rigol Homebrew List
Since I'm new to Blackfin, I thought I'd share what I've learned
today:
* DS1052E seems to be using ADSP BF531
* Source: http://www.eevblog.com/forum/index.php?topic=553.msg33203#msg33203
* http://www.analog.com/pr/ADSP-BF531
* The 10-byte "block header" of the firmware file is defined in EE-240
* http://www.analog.com/static/imported-files/application_notes/EE-240_Rev4.pdf
* Why the .RGL file header is 21 bytes is beyond me...
* It also seems different between 2.4 and 2.5
* In 2.5 the version string isn't ASCII anymore?
* Given the .RGL file is exactly 4 MB + 21 B, I assume we have 4 MB of
flash memory, but the last 6,685 bytes of 2.5 are all zeros.
* SMMR and CMMR as they are called in the map file on the Wiki are
called "System MMR" and "Core MMR" in the Programming Reference.
* The BF531 memory map is in the Hardware Reference in Fig. 6-3
* I can't find a way to load a map file into IDA Pro :(
* LSETUP is a nifty loop construct, but the IDA plugin should
recognize it as an XREF target :)
today:
* DS1052E seems to be using ADSP BF531
* Source: http://www.eevblog.com/forum/index.php?topic=553.msg33203#msg33203
* http://www.analog.com/pr/ADSP-BF531
* The 10-byte "block header" of the firmware file is defined in EE-240
* http://www.analog.com/static/imported-files/application_notes/EE-240_Rev4.pdf
* Why the .RGL file header is 21 bytes is beyond me...
* It also seems different between 2.4 and 2.5
* In 2.5 the version string isn't ASCII anymore?
* Given the .RGL file is exactly 4 MB + 21 B, I assume we have 4 MB of
flash memory, but the last 6,685 bytes of 2.5 are all zeros.
* SMMR and CMMR as they are called in the map file on the Wiki are
called "System MMR" and "Core MMR" in the Programming Reference.
* The BF531 memory map is in the Hardware Reference in Fig. 6-3
* I can't find a way to load a map file into IDA Pro :(
* LSETUP is a nifty loop construct, but the IDA plugin should
recognize it as an XREF target :)
Andreas Schuler
Jan 4, 2012, 11:16:15 PM1/4/12
to rigolh...@googlegroups.com
More about RGL file format you find at:
http://www.eevblog.com/forum/index.php?topic=553.msg42404#msg42404
Here are some unfiltered facts tedious copied from over 100 pages of messy eevblog forum entries:
(Maybee not all is correct)
Doing some research on DSO, and found this thread. From the photo we can say there
is a least one other component overclocked, the FIFO.
Reference is IS61LPS25636A-200 (http://www.issi.com/pdf/61LPS25632TD.pdf), It is
either 32 ou 36 bits wide and can run at a maximum of 200MHz. Now you have 1G sample
per second, assuming 8bits, if you want to store it in a 32bits RAM you need to run
at 250MHz. Then you are 50MHz over limit....
To each his own -- I'd see fiddling with the software as the first choice, not the
last one. Much cleaner. Smiley Sadly, IDA Pro can't handle Blackfin DSP code,
leaving me to deal with objdump.
In the hopes of seeing something useful, I yanked off the 24LC04 I2C EEPROM attached
to the Blackfin DSP, in the hopes of finding something obvious -- I was disappointed
with what I found:
DS1052E
0000000: 0104 ffff 1700 0000 00ff ffff 8025 0000 .............%..
0000010: 0009 0001 0001 0100 a086 0100 1900 0000 ................
0000020: 0000 803f 0000 0001 a086 0100 e7ff 0000 ...?............
0000030: 0000 803f 0000 0000 0000 0100 0000 0700 ...?............
0000040: 0000 0000 0000 0000 cdcc cc3d 1400 b5ff ...........=....
0000050: 0300 9600 0000 0000 0100 0000 0000 0000 ................
0000060: 0000 ffff 4042 0f00 0000 0000 0000 0000 ....@B..........
0000070: 0000 0000 a086 0100 0000 0000 0000 0000 ................
0000080: 0000 0000 0000 0800 0020 0000 0000 0000 ......... ......
0000090: 0800 0010 0500 0000 bd37 0635 5c8f c23e .........7.5\..>
00000a0: 0000 0000 0000 0000 0002 1900 e7ff 0000 ................
00000b0: bd37 8635 0000 0000 bd37 8635 0000 0000 .7.5.....7.5....
00000c0: 0000 0000 0000 0000 0100 0000 0000 0100 ................
00000d0: cdcc 4c3e cdcc 4c3e 0100 0000 0100 0000 ..L>..L>........
00000e0: 0100 0000 0000 0003 0101 07ff 4042 0f00 ............@B..
00000f0: 0000 0000 4042 0f00 0000 0000 0000 0000 ....@B..........
0000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000110: 0000 0000 0000 0000 0000 ffff bd37 8635 .............7.5
0000120: 00ff ffff bd37 8635 0000 0000 0000 0000 .....7.5........
0000130: 0100 01ff 0000 0000 0101 0101 0101 0101 ................
0000140: 0101 0001 0000 0000 0100 ffff 3aa3 14a9 ............:...
0000150: 00ff 0000 0001 0203 0405 0607 0001 0203 ................
0000160: 0405 0607 0000 0000 0000 0000 0007 0700 ................
0000170: 0007 0708 0202 0202 0202 0202 0202 0202 ................
0000180: 0202 0202 0000 0202 0202 0202 0202 0202 ................
0000190: 0202 0202 0202 0000 8ded b5a0 f7c6 b03e ...............>
00001a0: 0100 00ff 0000 0000 ffff ffff 0000 0000 ................
00001b0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................
00001c0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................
00001d0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................
00001e0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................
00001f0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................
m not seeing anything that looks remotely like a model number or serial number.
This was from a DS1052E -- anyone else care to do the same so we can compare?
The firmware images don't appear to be signed, so they could be modified easily --
they are 4194325-byte files, which seems to me like a 21-byte header plus a 4MB
firmware image. The header is:
0000000: 4453 3130 3030 4520 2020 3032 2e30 322e 3032 2e30 30 DS1000E 02.02.02.00
There's no room for a hash, so you could do whatever you want to the file.
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.
DS1052E
000000 01 04 FF FF 0C 00 00 00 00 FF FF FF 80 25 00 00 .............%..
000010 00 09 00 01 00 01 01 FF 40 42 0F 00 00 00 FF FF ........@B......
000020 00 00 80 3F 00 00 00 00 D0 07 00 00 00 00 FF FF ...?............
000030 00 00 80 3F 00 00 00 00 00 00 01 00 00 00 07 00 ...?............
000040 00 00 00 00 00 FF FF FF CD CC CC 3D 14 00 B5 FF ...........=....
000050 03 00 96 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
000060 00 00 FF FF 00 C2 EB 0B 00 00 00 00 00 00 00 00 ................
000070 00 00 00 00 A0 86 01 00 00 00 00 00 00 00 00 00 ................
000080 00 00 00 00 00 00 08 00 00 40 00 00 00 00 00 00 .........@......
000090 08 00 00 10 05 00 FF FF BD 37 06 35 5C 8F C2 3E .........7.5\..>
0000A0 00 00 00 00 77 BE 1F 3E 00 02 19 00 E7 FF FF FF ....w..>........
0000B0 BD 37 86 35 00 00 00 FF BD 37 86 35 00 00 FF FF .7.5.....7.5....
0000C0 00 00 00 00 00 00 00 FF 01 00 00 00 00 00 01 FF ................
0000D0 CD CC 4C 3E CD CC 4C 3E 01 00 00 00 01 00 FF FF ..L>..L>........
0000E0 01 00 00 00 00 00 00 03 01 01 07 FF 40 42 0F 00 ............@B..
0000F0 00 00 00 00 40 42 0F 00 00 00 00 00 00 00 00 00 ....@B..........
000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
000110 00 00 00 00 00 00 00 00 00 00 FF FF BD 37 86 35 .............7.5
000120 00 FF FF FF BD 37 86 35 00 00 00 00 00 00 00 FF .....7.5........
000130 01 00 01 FF 00 00 00 00 01 01 01 01 01 01 01 01 ................
000140 01 01 00 01 00 00 00 FF 01 00 FF FF FA 5C 78 6B .............\xk
000150 00 FF 00 00 00 01 02 03 04 05 06 07 00 01 02 03 ................
000160 04 05 06 07 00 00 FF FF 00 00 00 00 00 07 07 00 ................
000170 00 07 07 08 02 02 02 02 02 02 02 02 02 02 02 02 ................
000180 02 02 02 02 00 00 02 02 02 02 02 02 02 02 02 02 ................
000190 02 02 02 02 02 02 FF FF 8D ED B5 A0 F7 C6 B0 3E ...............>
0001A0 01 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF ................
0001B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
0001C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
0001D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
0001E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
0001F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 ................
Personal Message (Offline)
Re: The Rigol DS1052E
« Reply #236 on: March 15, 2010, 08:55:34 PM »
Reply with quoteQuote
Quote from: JimBeam on March 15, 2010, 05:52:36 AM
Well, I though, you could read in between the lines, that I already did so - and
when I tell you that I just closed the cover of my new DS1102E for the moment and
now look for a schematic and/or pictures of the LA part of the 1xxxD, guess what
this means..... Grin
Fine, fine, take all the glory and girls ... I should have listened to the voices in
my head when I saw those strings looking through the firmware. Wink Kidding ...
actually, Dave himself was the first to suggest this possibility. I'll give it a
try, as soon as I get this thing put back together ... I still wonder where they're
storing that info.
Actually, while I still have the thing in pieces, let me document a few things I
found, in case they're useful to someone later --
* I dunno what's actually stored on that 24LC04; the device will power on
without it attached to the board, but it hangs at the loading screen.
* There's an 8-pin card edge connector on the board, directly adjacent to the
EEPROM. I had hoped that it was a factory programming interface for that
EEPROM, but instead it's something quite different: It's the SPI master bus,
and you could connect a SPI flash chip to it and the Blackfin would boot from it
(according to the datasheet). If we number the pins as 1 <notch> 2 3 4 on the
top and 5 6 7 <notch> 8 on the bottom, then the pins appear to be SCK <notch>
MISO GND MOSI / PF2 Vcc GND <notch> BMODE0. BMODE1 is shorted to Vcc; pull
BMODE0 to ground to enable booting from external SPI flash. This is probably
how they program the units in the factory, and could be used to recover from a
bad firmware flash.
* BMODE0 is pulled to Vcc internally through a 10K resistor, which means that
normally it boots from another SPI master in the system -- not the 8MB NOR flash
as I expected. Very odd. Anyone know how this thing boots? (It still may be
the case that the 4MB of firmware is stored in the first half of the NOR flash,
but there has to be something shoving a boot stub to this thing over SPI or the
datasheet is lying. I guess the second 4MB of the NOR flash could be used for
the internal waveform storage, as well as the serial number and model number.)
* There's also a (presumably) perfectly usable JTAG port for the Blackfin --
pinout seems to be (in order from 1-14) Vref !EMU <empty> GND GND TMS GND TCK
GND !TRST GND TDI GND TDO, but I haven't tried it.
* The six-pin header near the Altera chip is the programming header for the
Lattice CPLD; I didn't bother trying it, presumably it's fused off.
-----------
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
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
-----------------------------
the header sits right next to the blackfin is connected to EMU, TMS, TCK, TRST, TDI,
TDO. i heard with my brain, it sounds like JTAG (MOSI, MISO CLK, ISPDAT, ISPCLK
sounds pretty similar). will study more on this. i dont have any programmer, any
suggestion? can i program arduino mega to do that? blackfin 531 is a way much more
powerful than atmega1280, i dont know if i can make arduino outruns blackfin. Smiley
----------------------------------------
Hello Everybody,
I'm new on this forum... also tried the firmware downgrade, but unfortunately used
the 02.01.01 Firmware for downgrading. Result was the same as Halman's:
Fan running, but no image on the screen and no response on USB and RS232.
I was trying to figure out the pinning of the internal JTAG header:
--------
3,3V(10k +3v3) <| o o |> /EMU (83)
| |
| o |> GND
| |
GND <| o o |> CPU Pin85 = TMS
| |
GND <| o o |> CPU Pin94 = TCK (10k)
| |
GND <| o o |> /TRST (84) (10k)
| |
GND <| o o |> CPU Pin86 = TDI (10k)
| |
GND <| o o |> CPU Pin87 = TDO 100-
--------
http://www.analog.com/static/imported-files/application_notes/ee-68_rev10.pdf
There should also be a 3V3 Pin at least on the header, I haven't checked it yet.
Flash S29GL064N90TFI04 runs at 3.3V, word-mode
CPU ADSP - BF531
Pin95-BMODE1 = 0V
Pin96-BMODE0 = 3V3
--> Boot from (16bit) Flash
The CPU's datasheet mentions a internal ROM; I'm not sure if it's really a ROM
(meaning that even Rigol hasn't changed it) and I want to find out it's content. My
goal is to get access to the CPU via the JTAG interface to try to reflash the FLASH.
Has anybody found out about the Flash's layout? It's 8MBytes large, but the *.rgl
files are only 2MBytes large...?
@halman, shafri: Please give an update about your work.
Thanks
Meiner
--------------------------------------------------
You are right, the *.rgl is 4 MBytes. That's exact the size of the 4 async memory
banks in the ADSP CPU (datasheet page6, starting at address 0x20000000). That's the
cause why the *.rgl is only 4 MBytes while the flash is bigger (but cannot be fully
accessed by the ADSP CPU). Boot mode 01 (Use boot ROM to load from 8-bit or 16-bit
flash) starts the internal boot ROM with a 10-byte header read from the external
flash to load the internal code memory and start executation from there afterwards.
I didin't understand why you want to trace from the altera to the spansion flash? In
my opinion the flash is connected to the ADSP-BF531, not to the altera. I'm still
trying to find a way to reflash the spansion via the ADSP's JTAG interface? If not
possible, Plan B would be to desolder the flash and replace it with a new one
flashed in an external programmer.
I think the 02.01.01 firmware I used for downgrading uses a different boot block
inside the flash which is not compatible with my hardware. Replacing the whole
4MBytes flash content should therefore make the scope work again. I only hope that
the 4 MBytes used are at the beginning of the entire 8MBytes flash...
--------------------------------------------------
i agree with marianoapp, i cant find any codelike data inside. by just looking at
the flash compressed file 71KB vs original 8MB, your flash only contains a highly
redundant bytes with some database/structured/tabular like format chunks inside.
maybe your flash got formatted by the bootloader or something... i think.
added: the bin is separated into 2 equal sized 4MB space with a header in each
section... the contents are identical except in the middle of 1st section (around
2MB location, some additional data OOOOPPPP..CCCCC where in the same location for
the 2nd section, its emptied with FFFFFFFFFFFFFFF Huh?
this is interesting, @meiner & others... can you suggest a flash reader to me, if
the price and availability is right, i think i'm going to get one as well to read my
spansion, preferably from ebay, cheaper but reliable. i'm suspecting something from
the tabular data in the flash bin, but i think better not to say it for now, only
speculating.
ps: i wish a more generic eeprom reader that can read not just spansion, but
samsung, atmel etc, so it will be more useful to me, i got quite a number of
salvaged samsung eeprom here.
-------------------------------------------------
Quote from: Meiner on July 09, 2010, 01:23:14 AM
I was trying to figure out the pinning of the internal JTAG header:
[...]
There should also be a 3V3 Pin at least on the header, I haven't checked it yet.
Flash S29GL064N90TFI04 runs at 3.3V, word-mode
CPU ADSP - BF531
Pin95-BMODE1 = 0V
Pin96-BMODE0 = 3V3
--> Boot from (16bit) Flash
The CPU's datasheet mentions a internal ROM; I'm not sure if it's really a ROM
(meaning that even Rigol hasn't changed it) and I want to find out it's content. My
goal is to get access to the CPU via the JTAG interface to try to reflash the FLASH.
Please double-check this; I measured BMODE0/1 and got completely different results,
see http://www.eevblog.com/forum/index.php?topic=30.msg2824#msg2824. (I also put
the JTAG pinout there.)
The purpose of the ROM is to read those BMODE pins and fetch the rest of the code
from the appropriate source ... if the datasheet says it's ROM, it's doubtful that
Rigol can reprogram it.
----------------------------------------------------------------
http://www.eevblog.com/forum/index.php?topic=553.msg42404#msg42404
Here are some unfiltered facts tedious copied from over 100 pages of messy eevblog forum entries:
(Maybee not all is correct)
Doing some research on DSO, and found this thread. From the photo we can say there
is a least one other component overclocked, the FIFO.
Reference is IS61LPS25636A-200 (http://www.issi.com/pdf/61LPS25632TD.pdf), It is
either 32 ou 36 bits wide and can run at a maximum of 200MHz. Now you have 1G sample
per second, assuming 8bits, if you want to store it in a 32bits RAM you need to run
at 250MHz. Then you are 50MHz over limit....
To each his own -- I'd see fiddling with the software as the first choice, not the
last one. Much cleaner. Smiley Sadly, IDA Pro can't handle Blackfin DSP code,
leaving me to deal with objdump.
In the hopes of seeing something useful, I yanked off the 24LC04 I2C EEPROM attached
to the Blackfin DSP, in the hopes of finding something obvious -- I was disappointed
with what I found:
DS1052E
0000000: 0104 ffff 1700 0000 00ff ffff 8025 0000 .............%..
0000010: 0009 0001 0001 0100 a086 0100 1900 0000 ................
0000020: 0000 803f 0000 0001 a086 0100 e7ff 0000 ...?............
0000030: 0000 803f 0000 0000 0000 0100 0000 0700 ...?............
0000040: 0000 0000 0000 0000 cdcc cc3d 1400 b5ff ...........=....
0000050: 0300 9600 0000 0000 0100 0000 0000 0000 ................
0000060: 0000 ffff 4042 0f00 0000 0000 0000 0000 ....@B..........
0000070: 0000 0000 a086 0100 0000 0000 0000 0000 ................
0000080: 0000 0000 0000 0800 0020 0000 0000 0000 ......... ......
0000090: 0800 0010 0500 0000 bd37 0635 5c8f c23e .........7.5\..>
00000a0: 0000 0000 0000 0000 0002 1900 e7ff 0000 ................
00000b0: bd37 8635 0000 0000 bd37 8635 0000 0000 .7.5.....7.5....
00000c0: 0000 0000 0000 0000 0100 0000 0000 0100 ................
00000d0: cdcc 4c3e cdcc 4c3e 0100 0000 0100 0000 ..L>..L>........
00000e0: 0100 0000 0000 0003 0101 07ff 4042 0f00 ............@B..
00000f0: 0000 0000 4042 0f00 0000 0000 0000 0000 ....@B..........
0000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000110: 0000 0000 0000 0000 0000 ffff bd37 8635 .............7.5
0000120: 00ff ffff bd37 8635 0000 0000 0000 0000 .....7.5........
0000130: 0100 01ff 0000 0000 0101 0101 0101 0101 ................
0000140: 0101 0001 0000 0000 0100 ffff 3aa3 14a9 ............:...
0000150: 00ff 0000 0001 0203 0405 0607 0001 0203 ................
0000160: 0405 0607 0000 0000 0000 0000 0007 0700 ................
0000170: 0007 0708 0202 0202 0202 0202 0202 0202 ................
0000180: 0202 0202 0000 0202 0202 0202 0202 0202 ................
0000190: 0202 0202 0202 0000 8ded b5a0 f7c6 b03e ...............>
00001a0: 0100 00ff 0000 0000 ffff ffff 0000 0000 ................
00001b0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................
00001c0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................
00001d0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................
00001e0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................
00001f0: ffff ffff 0000 0000 ffff ffff 0000 0000 ................
m not seeing anything that looks remotely like a model number or serial number.
This was from a DS1052E -- anyone else care to do the same so we can compare?
The firmware images don't appear to be signed, so they could be modified easily --
they are 4194325-byte files, which seems to me like a 21-byte header plus a 4MB
firmware image. The header is:
0000000: 4453 3130 3030 4520 2020 3032 2e30 322e 3032 2e30 30 DS1000E 02.02.02.00
There's no room for a hash, so you could do whatever you want to the file.
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.
DS1052E
000000 01 04 FF FF 0C 00 00 00 00 FF FF FF 80 25 00 00 .............%..
000010 00 09 00 01 00 01 01 FF 40 42 0F 00 00 00 FF FF ........@B......
000020 00 00 80 3F 00 00 00 00 D0 07 00 00 00 00 FF FF ...?............
000030 00 00 80 3F 00 00 00 00 00 00 01 00 00 00 07 00 ...?............
000040 00 00 00 00 00 FF FF FF CD CC CC 3D 14 00 B5 FF ...........=....
000050 03 00 96 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
000060 00 00 FF FF 00 C2 EB 0B 00 00 00 00 00 00 00 00 ................
000070 00 00 00 00 A0 86 01 00 00 00 00 00 00 00 00 00 ................
000080 00 00 00 00 00 00 08 00 00 40 00 00 00 00 00 00 .........@......
000090 08 00 00 10 05 00 FF FF BD 37 06 35 5C 8F C2 3E .........7.5\..>
0000A0 00 00 00 00 77 BE 1F 3E 00 02 19 00 E7 FF FF FF ....w..>........
0000B0 BD 37 86 35 00 00 00 FF BD 37 86 35 00 00 FF FF .7.5.....7.5....
0000C0 00 00 00 00 00 00 00 FF 01 00 00 00 00 00 01 FF ................
0000D0 CD CC 4C 3E CD CC 4C 3E 01 00 00 00 01 00 FF FF ..L>..L>........
0000E0 01 00 00 00 00 00 00 03 01 01 07 FF 40 42 0F 00 ............@B..
0000F0 00 00 00 00 40 42 0F 00 00 00 00 00 00 00 00 00 ....@B..........
000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
000110 00 00 00 00 00 00 00 00 00 00 FF FF BD 37 86 35 .............7.5
000120 00 FF FF FF BD 37 86 35 00 00 00 00 00 00 00 FF .....7.5........
000130 01 00 01 FF 00 00 00 00 01 01 01 01 01 01 01 01 ................
000140 01 01 00 01 00 00 00 FF 01 00 FF FF FA 5C 78 6B .............\xk
000150 00 FF 00 00 00 01 02 03 04 05 06 07 00 01 02 03 ................
000160 04 05 06 07 00 00 FF FF 00 00 00 00 00 07 07 00 ................
000170 00 07 07 08 02 02 02 02 02 02 02 02 02 02 02 02 ................
000180 02 02 02 02 00 00 02 02 02 02 02 02 02 02 02 02 ................
000190 02 02 02 02 02 02 FF FF 8D ED B5 A0 F7 C6 B0 3E ...............>
0001A0 01 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF ................
0001B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
0001C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
0001D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
0001E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
0001F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 ................
Personal Message (Offline)
Re: The Rigol DS1052E
« Reply #236 on: March 15, 2010, 08:55:34 PM »
Reply with quoteQuote
Quote from: JimBeam on March 15, 2010, 05:52:36 AM
Well, I though, you could read in between the lines, that I already did so - and
when I tell you that I just closed the cover of my new DS1102E for the moment and
now look for a schematic and/or pictures of the LA part of the 1xxxD, guess what
this means..... Grin
Fine, fine, take all the glory and girls ... I should have listened to the voices in
my head when I saw those strings looking through the firmware. Wink Kidding ...
actually, Dave himself was the first to suggest this possibility. I'll give it a
try, as soon as I get this thing put back together ... I still wonder where they're
storing that info.
Actually, while I still have the thing in pieces, let me document a few things I
found, in case they're useful to someone later --
* I dunno what's actually stored on that 24LC04; the device will power on
without it attached to the board, but it hangs at the loading screen.
* There's an 8-pin card edge connector on the board, directly adjacent to the
EEPROM. I had hoped that it was a factory programming interface for that
EEPROM, but instead it's something quite different: It's the SPI master bus,
and you could connect a SPI flash chip to it and the Blackfin would boot from it
(according to the datasheet). If we number the pins as 1 <notch> 2 3 4 on the
top and 5 6 7 <notch> 8 on the bottom, then the pins appear to be SCK <notch>
MISO GND MOSI / PF2 Vcc GND <notch> BMODE0. BMODE1 is shorted to Vcc; pull
BMODE0 to ground to enable booting from external SPI flash. This is probably
how they program the units in the factory, and could be used to recover from a
bad firmware flash.
* BMODE0 is pulled to Vcc internally through a 10K resistor, which means that
normally it boots from another SPI master in the system -- not the 8MB NOR flash
as I expected. Very odd. Anyone know how this thing boots? (It still may be
the case that the 4MB of firmware is stored in the first half of the NOR flash,
but there has to be something shoving a boot stub to this thing over SPI or the
datasheet is lying. I guess the second 4MB of the NOR flash could be used for
the internal waveform storage, as well as the serial number and model number.)
* There's also a (presumably) perfectly usable JTAG port for the Blackfin --
pinout seems to be (in order from 1-14) Vref !EMU <empty> GND GND TMS GND TCK
GND !TRST GND TDI GND TDO, but I haven't tried it.
* The six-pin header near the Altera chip is the programming header for the
Lattice CPLD; I didn't bother trying it, presumably it's fused off.
-----------
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
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
-----------------------------
the header sits right next to the blackfin is connected to EMU, TMS, TCK, TRST, TDI,
TDO. i heard with my brain, it sounds like JTAG (MOSI, MISO CLK, ISPDAT, ISPCLK
sounds pretty similar). will study more on this. i dont have any programmer, any
suggestion? can i program arduino mega to do that? blackfin 531 is a way much more
powerful than atmega1280, i dont know if i can make arduino outruns blackfin. Smiley
----------------------------------------
Hello Everybody,
I'm new on this forum... also tried the firmware downgrade, but unfortunately used
the 02.01.01 Firmware for downgrading. Result was the same as Halman's:
Fan running, but no image on the screen and no response on USB and RS232.
I was trying to figure out the pinning of the internal JTAG header:
--------
3,3V(10k +3v3) <| o o |> /EMU (83)
| |
| o |> GND
| |
GND <| o o |> CPU Pin85 = TMS
| |
GND <| o o |> CPU Pin94 = TCK (10k)
| |
GND <| o o |> /TRST (84) (10k)
| |
GND <| o o |> CPU Pin86 = TDI (10k)
| |
GND <| o o |> CPU Pin87 = TDO 100-
--------
http://www.analog.com/static/imported-files/application_notes/ee-68_rev10.pdf
There should also be a 3V3 Pin at least on the header, I haven't checked it yet.
Flash S29GL064N90TFI04 runs at 3.3V, word-mode
CPU ADSP - BF531
Pin95-BMODE1 = 0V
Pin96-BMODE0 = 3V3
--> Boot from (16bit) Flash
The CPU's datasheet mentions a internal ROM; I'm not sure if it's really a ROM
(meaning that even Rigol hasn't changed it) and I want to find out it's content. My
goal is to get access to the CPU via the JTAG interface to try to reflash the FLASH.
Has anybody found out about the Flash's layout? It's 8MBytes large, but the *.rgl
files are only 2MBytes large...?
@halman, shafri: Please give an update about your work.
Thanks
Meiner
--------------------------------------------------
You are right, the *.rgl is 4 MBytes. That's exact the size of the 4 async memory
banks in the ADSP CPU (datasheet page6, starting at address 0x20000000). That's the
cause why the *.rgl is only 4 MBytes while the flash is bigger (but cannot be fully
accessed by the ADSP CPU). Boot mode 01 (Use boot ROM to load from 8-bit or 16-bit
flash) starts the internal boot ROM with a 10-byte header read from the external
flash to load the internal code memory and start executation from there afterwards.
I didin't understand why you want to trace from the altera to the spansion flash? In
my opinion the flash is connected to the ADSP-BF531, not to the altera. I'm still
trying to find a way to reflash the spansion via the ADSP's JTAG interface? If not
possible, Plan B would be to desolder the flash and replace it with a new one
flashed in an external programmer.
I think the 02.01.01 firmware I used for downgrading uses a different boot block
inside the flash which is not compatible with my hardware. Replacing the whole
4MBytes flash content should therefore make the scope work again. I only hope that
the 4 MBytes used are at the beginning of the entire 8MBytes flash...
--------------------------------------------------
i agree with marianoapp, i cant find any codelike data inside. by just looking at
the flash compressed file 71KB vs original 8MB, your flash only contains a highly
redundant bytes with some database/structured/tabular like format chunks inside.
maybe your flash got formatted by the bootloader or something... i think.
added: the bin is separated into 2 equal sized 4MB space with a header in each
section... the contents are identical except in the middle of 1st section (around
2MB location, some additional data OOOOPPPP..CCCCC where in the same location for
the 2nd section, its emptied with FFFFFFFFFFFFFFF Huh?
this is interesting, @meiner & others... can you suggest a flash reader to me, if
the price and availability is right, i think i'm going to get one as well to read my
spansion, preferably from ebay, cheaper but reliable. i'm suspecting something from
the tabular data in the flash bin, but i think better not to say it for now, only
speculating.
ps: i wish a more generic eeprom reader that can read not just spansion, but
samsung, atmel etc, so it will be more useful to me, i got quite a number of
salvaged samsung eeprom here.
-------------------------------------------------
Quote from: Meiner on July 09, 2010, 01:23:14 AM
I was trying to figure out the pinning of the internal JTAG header:
[...]
There should also be a 3V3 Pin at least on the header, I haven't checked it yet.
Flash S29GL064N90TFI04 runs at 3.3V, word-mode
CPU ADSP - BF531
Pin95-BMODE1 = 0V
Pin96-BMODE0 = 3V3
--> Boot from (16bit) Flash
The CPU's datasheet mentions a internal ROM; I'm not sure if it's really a ROM
(meaning that even Rigol hasn't changed it) and I want to find out it's content. My
goal is to get access to the CPU via the JTAG interface to try to reflash the FLASH.
Please double-check this; I measured BMODE0/1 and got completely different results,
see http://www.eevblog.com/forum/index.php?topic=30.msg2824#msg2824. (I also put
the JTAG pinout there.)
The purpose of the ROM is to read those BMODE pins and fetch the rest of the code
from the appropriate source ... if the datasheet says it's ROM, it's doubtful that
Rigol can reprogram it.
----------------------------------------------------------------
Reply all
Reply to author
Forward
0 new messages