Hmm, I know the factory firmware can be reliably crashed by sending malformed data over the network. I wonder if there's a RCE hidden somewhere in there which might allow bootstrapping to Linux over the network.
Wow, that it a lot of work. I found it amazing that the OWON folks thought emulating a DDR2 memory in an FPGA was good design. And I was blown away by the determination of this guy to figure out every pin, I picked up a few tricks I'll be using in the future.
> I found it amazing that the OWON folks thought emulating a DDR2 memory in an FPGA was good design.
The SoC has the same kind of memory connected to it, so the memory controller in the SoC is configured for DDR2. And many uCs and SoC don't like it if their address banks are not configured for the same kind of clocking and do weird things otherwise.
For example the STM32F407 (and probably the 205, 207 and 405) truncate the last clock in a transmission toward the fastest clock speed configured in the FSMC banks. That caused quite a bit of trouble in a project. Also it's an undocumented erratum, or at least it was at the time when we had to deal with it.
Yes, but this particular CPU/SoC has a parallel bus with the NAND flash connected to it. Which would be the more traditional way to connect an FPGA.
For a recent example: The TI Sitara am57xx has 8 individual chip-selects on its "General-Purpose Memory Controller (GPMC)" and supports a few flash-specific modes, but also "Asynchronous SRAM-like memories and ASIC devices" (quote from the datasheet http://www.ti.com/lit/ds/symlink/am5728.pdf p245). So, to connect a FPGA the data/address lines would be shared between flash and FPGA but individual chip-selects would select one or the other.
As one can (typically) configure very relaxed timings on these busses, it's much, much easier to interface to and sufficient for everything that doesn't have to be super-fast. Of course with the disadvantage of being slower this might have been THE reason to go for the DDR2 memory bus.
> Yes, but this particular CPU/SoC has a parallel bus with the NAND flash connected to it. Which would be the more traditional way to connect an FPGA.
Absolutely.
> As one can (typically) configure very relaxed timings on these busses, it's much, much easier to interface to and sufficient for everything that doesn't have to be super-fast.
"super-fast" is probably the keyword here. In an oscilloscope you normally want a very short trigger re-arm interval. Which means that you want to get the data out of the acquisition buffer as fast as possible. At the sampling rates the used ADC supports the regular parallel bus timings might be to slow, but by implementing a DDR2 interface a very quick transfer could be implemented.
Actually if I had to design this (actually only recently I did design something like this) I'd not transfer acquired samples to main system memory at all but instead present the FPGA attached DDR2 to the SoC in a double buffered manner and even do things like averaging, envelope tracking and similar acquisition tasks in FPGA on the backbuffer memory.
I admire your tenacity. A thought about the DDR2 interface: since you own both sides of it, you can cheat. Write identical data to addresses n and n+1, and use the standard rising edge on the FPGA. When reading data back to the SoC, throw away every other word.
Hey! It's been a while since I've seen one of those. I ran a Dreamplug [1] for quite a while. There was a reasonable amount of info about OpenOCD and uBoot for that platform but I'm guessing the scope is different enough that it wouldn't help.
I'm not familiar with this model but what OS does it usually have? I know there are other oscilloscopes which already run Linux, and some of the high-end ones use Windows. VxWorks is also used. The low-end ones seem to prefer Linux --- and tend to have rather long boot-time as a result.
OWON seems to have written their own RTOS for the SDS7102. Except for a few strings referring to yaffs (which they don't actually seem to use) I didn't find any strings in the firmware mentioning any of the RTOSes I know about.
And Linux isn't that slow to boot if you are a bit careful. It takes about 10 seconds from when I press enter to start downloading Linux using openocd until I can log in with ssh. 3 seconds of that is the JTAG download and a second or two is the time it takes to get a DHCP lease over the network.
