I already requested the GPL source code for both these scopes.
No response at all yet
Also, I just saw Dave's video and got excited and disappointed at the same time (Happy MSO5000 owner and no $ and room for an HDO1000 just to hack it :p)
Interesting stuff from the boot log though; afaik the rockchips have quite decent upstream support (both in U-Boot and in Linux), yet they use (obviously) the vendor stuff, as that ddr training data clearly is from the rockchip SDK, though maybe only the SPL is from rockchip? not familiar with this chip ... I bet they just did minimal modification to the off-the-shell android port from rockchip.
So the good news:
```
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
...
Trust Addr:0x4000, 0x58334c42
No find bl30.bin
...
RunBL31 0x40000 @ 97359 us
\x01NOTICE: BL31: v1.3(release):845ee93
```
While I'm not familiar _at_all_ with this specific chip/SDK, looks like that secure boot is disabled, e.g. no fuses etc what I worried about. (Chime in the common, rigol loves hackers :p). So that makes a lot of stuff possible! Someone send me a scope
(@tv84 probably needs one too >:p) that trust addr is a bit scary though, though I think it's just trying to load an 'arm trust zone firmware' binary here... (though bl30.bin seems to be associated with Amlogic's S905 according to google foo). BL31 seems to be 'optee' opensource trust zone firmware? which actually is booting ... so maybe locked down after all?
```
GPT 0x3335db8 signature is wrong
recovery gpt...
GPT 0x3335db8 signature is wrong
recovery gpt fail!
```
Why do vendors never _try_ to fix warnings/errors. This is simple to fix, and should be avoided, a recovery GPT exists for a reason ya'know :p
Anyway, seems to at least load uboot or at least in string, but then dead silcence, no console output, no kernel output
but:
All those "\0\0\0\0\0\0\0\0" is probably when the second bootloader (u-boot) started and used a different baudrate. You may want to re-decode that part.
Never would have thought of that. It would really do that?
That's probably very true
(where's autobaud ...) 115k is very common for U-Boot ... and yes, I would not be surprised. Vendor of the shelf bits and pieces glued together
And they probably never looked/cared at the SPL, if they can get their U-Boot output, if they are even hacking around that at all.
Wondering if we can go from HDO1000 -> HDO4000 (with limitations) though. They probably interleave the ADC to go from 2G to 4G samples, but I'm not analog enough to understand how that would work. I suppose if each samples at 1/2 the clock (or the clock runs twice as fast :p) that could work. The FPGA could be the same, (makes software development and testing much easier) and just never go into a mode that would do anything better then 2G? Curious. But then, rushed developers don't make things easy and modular, just 'it works, ship it' and hack things together to make things work.
I don't think this is how it worked on the MSO5k's, there you only had 2 pairs per adc, 1 + 3 combined. I think this design is different. So very curious if an HDO1000/HDO4000 owner can see if we have the same limits as before (chan 1 + 3 combined) ... @dave :p
Anyway, I just realized I'm just reading page 1, and there's 8 pages already
So let me read those 8 pages first and then comment some more :p