
Linux on the SDS7102 Scope - zdw
http://blog.weinigel.se/2016/05/07/linux-on-sds7102.html
======
lgeek
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.

------
ChuckMcM
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.

~~~
datenwolf
> 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.

~~~
cnvogel
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](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.

~~~
datenwolf
> 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.

------
rvense
This project is incredibly cool and the posts are really well written.

------
voltagex_
>ARM926EJ-S [41069265] revision 5 (ARMv5TEJ)

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.

[1]: [http://www.geek.com/chips/dreamplug-puts-a-1-2ghz-arm-pc-
in-...](http://www.geek.com/chips/dreamplug-puts-a-1-2ghz-arm-pc-in-a-power-
outlet-1310349/)

------
userbinator
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.

~~~
wingel
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.

