Static/snow

[gjreasoner]

Just got my pi/netv2. Having an issue with static on the overlay so badly you can hardly read the text. Same hdmi cable and different source it works great. I’m not even sure where to begin to start tracking it down. Thanks for any assistance 👏

[xadacka]

I've had that happen, too, plugging it out and in again a few times usually fixes it for good (until the next time you swap cables anyway). If that doesn't help I'd try a different cable.

[bunnie]

The static is due to an inability to sync the crypto keys (encrypted data looks like static). if plug/unplug the cable does the static go away? also, what is the source you are using? some devices aren't quite hdcp spec compliant and in order for netv2 to do its trick the source needs to be spec compliant. there are some things I can walk you through for debugging if you can open a shell on your rpi. thanks,

…

-b. --

On June 29, 2019 12:47:04 PM GMT+08:00, Justin Reasoner ***@***.***> wrote: Just got my pi/netv2. Having an issue with static on the overlay so badly you can hardly read the text. Same hdmi cable and different source it works great. I’m not even sure where to begin to start tracking it down. Thanks for any assistance 👏> > > > > -- > You are receiving this because you are subscribed to this thread.> Reply to this email directly or view it on GitHub:> #12

[gjreasoner]

Thanks for the speedy replies.

So I can get a clear overlay using another raspberry pi as source but when I try to use my chromecast as a source that's when I the static as shown in the photo.

I'll try few more different HDMI cables as suggested and I can absolutely open a shell on the netv2 rpi if you have some suggestions there @bunnie.

Really appreciate both you guys taking the time out to respond, thank you.

[mithro]

@gjrdiesel Just a reminder,

IMPORTANT: If you want to connect a regular HDMI cable to the "overlay" port, you will need to re-build the FPGA with the correct pattern of differential pair inversions to match an HDMI cable. See https://github.com/AlphamaxMedia/netv2-fpga/blob/master/netv2mvp.py#L148. The pattern of inversions checked into the master branch targets the custom M2M jumper, which swaps some differential pairs to improve routing.

[mithro]

From here -> https://github.com/AlphamaxMedia/netv2-fpga#netv2-litex-quickstart-guide

[bunnie]

Hmm, you'll need to stick a debug build onto your device to debug the HDCP key exchange.

If you don't mind, grab the file below:

firmware.zip.zip

Copy it to your raspberry pi, and unzip it. Put the firmware.bin file into ~/code/flterm

Then do:

pm2 stop netv2-status
cd ~/code/flterm
./flterm --port /dev/ttyS0 --speed 115200 --kernel firmware.bin

Switch to a new window, and do this:

cd ~/code/netv2mvp-scripts
sudo openocd -f reboot.cfg

Switch back to the flterm window. You should see the FPGA reloading, and in this case, it should be grabbing its kernel from the serial port, a process that takes a few seconds.

Inside flterm, type these commands:

json off
debug km
debug dumpe

It'll be helpful to see the spew coming out of debug km and debug dumpe to try and see what's going on.

[gjreasoner]

K, here are the dumps

RUNTIME>debug km
source public ksv (lsb): ac655f42
source public ksv (msb): 0000009a
sink public ksv (lsb): 4717256c
sink public ksv (msb): 000000d9
Km (lsb): b2ed5c1f
Km (msb): 00906d76
Km'(lsb): b2ed5c1f
Km'(msb): 00906d76
Committing Km
Writing to 1f to e000c018
Writing to 5c to e000c014
Writing to ed to e000c010
Writing to b2 to e000c00c
Writing to 76 to e000c008
Writing to 6d to e000c004
Writing to 90 to e000c000
Confirm check Km as writ: (LSB) b2ed5c1f
Confirm check Km as writ: (MSB) 00906d76
Flipping Km valid
RUNTIME>
RUNTIME>debug dumpe

 00: 6c 25 17 47 d9 00 00 00 00 00 00 00 00 00 00 00
 10: 42 5f 65 ac 9a 00 00 00 9a 4e 8a 8a 7b d4 89 77
 20: 6c 25 17 47 d9 00 00 00 00 00 00 00 00 00 00 00
 30: 42 5f 65 ac 9a 00 00 00 9a 4e 8a 8a 7b d4 89 77
 40: 6c 25 17 47 d9 00 00 00 00 00 00 00 00 00 00 00
 50: 42 5f 65 ac 9a 00 00 00 9a 4e 8a 8a 7b d4 89 77
 60: 6c 25 17 47 d9 00 00 00 00 00 00 00 00 00 00 00
 70: 42 5f 65 ac 9a 00 00 00 9a 4e 8a 8a 7b d4 89 77
 80: 6c 25 17 47 d9 00 00 00 00 00 00 00 00 00 00 00
 90: 42 5f 65 ac 9a 00 00 00 9a 4e 8a 8a 7b d4 89 77
 a0: 6c 25 17 47 d9 00 00 00 00 00 00 00 00 00 00 00
 b0: 42 5f 65 ac 9a 00 00 00 9a 4e 8a 8a 7b d4 89 77
 c0: 6c 25 17 47 d9 00 00 00 00 00 00 00 00 00 00 00
 d0: 42 5f 65 ac 9a 00 00 00 9a 4e 8a 8a 7b d4 89 77
 e0: 6c 25 17 47 d9 00 00 00 00 00 00 00 00 00 00 00
 f0: 42 5f 65 ac 9a 00 00 00 9a 4e 8a 8a 7b d4 89 77

I'm also trying to figure out how to rebuild the FPGA but progress is slow.

[bunnie]

Thanks for the debug log.

I checked this through my simulator and it looks like the computation seems valid, so the issue isn't the capture and computation of the key. It seems it probably has something to do with the exact timing of the handshake.

One thing that might be interesting to try, if you have the time, is to turn off HDMI as the audio device on the Chromecast. I don't know if that's even an option, but one possibility is that the embedded audio islands are throwing off the cipher sync, I have seen a couple edge cases there before, may be possible I missed one that the Chromecast touches.

Also, can you please let me know what is the exact make/model of the Chromecast you're using? I want to look up how much it would cost for me to acquire an exact replica of that situation. To debug a handshake issue, I would have to acquire a unit and I'd like to see if I can afford to buy it for testing purposes.

Also, there's maybe one other thing you can try, if you have the time, that might reveal a little more about what's going on. If you can do the procedure to get into flterm and turn off the json spew and run these commands:

debug hpdforce
debug hpdrelax

and send on the output that'd be helpful. The first command forces an HPD event without unplugging the device, the second returns the connection to normal. This allows us to witness the handshake very cleanly, you should see some notes about eye positions and key derivation going by.

I might ask you to turn on an even higher debug level later on (e.g. using the "debug input0" command, but it generates a LOT of spew). What I'm looking for is specifically if during the handshake I can see any evidence of a time-out or renegotiation that would throw off the cipher sync.

One possible hypothesis is that the NeTV2 simply can't do the math fast enough to keep up; there is a small window in which we have to commit the keys -- after the key exchange but before the first frame arrives -- and if the derived keys come too late, then we lose sync with the stream as a whole.

[gjreasoner]

The model is a US based Chromecast Ultra running Cast Firmware version 1.40.156414. On a 65" 1080 LG.

I'm not sure it's possible to disable audio. The only adjustable audio setting I could find was a Group delay correction setting.

I've tried switching to an older First Gen Chromecast running version 1.36.159268 but never got any video output at all, just a black screen. I'll retry a few times with that one and get a flterm debug log.

Output from the two commands from the Chromecast Ultra:

RUNTIME>debug hpdforce
RUNTIME>
RUNTIME>hdmi_in0: setting algo 2 eye time to 14 IDELAY periods
hdmi_in0: setting algo 2 eye time to 14 IDELAY periods
debug hpdrelax
RUNTIME>
RUNTIME>
RUNTIME>
RUNTIME>hdmi_in0: setting algo 2 eye time to 14 IDELAY periods
hdmi_in0: setting algo 2 eye time to 14 IDELAY periods
source public ksv (lsb): ac655f42
source public ksv (msb): 0000009a
sink public ksv (lsb): 4717256c
sink public ksv (msb): 000000d9
Km (lsb): b2source publi

I'm working on getting a log from debug input0 next. I really appreciate all the help!

[gjreasoner]

Still debugging the chromecas ultra here:

Here is a link to a full debug log with all the flterm commands:
https://gist.github.com/gjrdiesel/ad0ba14f03670b8d956dd42389c4e71c

Here is a recorded session (probably not as helpful but maybe):

[bunnie]

Thanks. I guess I shouldn't be so shocked that I can't buy a Chromecast Ultra and have it shipped to Singapore, probably because it plays region-locked content.

I'll try to acquire one on my next visit to the USA, but that does mean it'll be about a month and a half before I can even try to reproduce the issue.

[bunnie]

It does look like it glitches during the handshake, probably the next step is for me try and reproduce it in my lab. As mentioned above, acquiring such a unit will take a little time. It's in my budget to buy one, just not in my budget to get it shipped to me fast. Thanks for your patience.

[bunnie]

So, I finally acquired a Chromecast Ultra.

The bad news is that this doesn't exhibit the bug you've outlined. The HDCP handshake happens flawlessly and I don't have snow on my overlay. So, the problem may be specific to a Chromecast/TV combo issue. Have you had any luck with this problem, or still the same as last I checked in?

[gjreasoner]

I'm sorry @bunnie, I've rearranged some equipment (ultimately this setup is for my parents, and they've since moved) and the device is working great. It is doing the same issue I had with the chromecast if I use their sound bar, but I'm not ready to start diagnosing that yet.

I appreciate you taking the time and money to investigate further. Do you have a donation link I can help reimburse for the chromecast ultra debugging? Thank you again.

[bunnie]

Hi @gjrdiesel, no worries. I'm also moving at methodical pace on squashing the bugs. I appreciate the offer for a donation link but the good news is that I have a (small and almost spent) budget to buy interoperability testing equipment; the NeTV2 crowdfunding campaign helped fund that. I now have a totally separate, off-topic rant about how I had to install an app to configure the chromecast and for some reason it insists on knowing my location -- but the google surveillance state is a separate rant :)

However, if it turns out I need to get a sound bar and that's pricey we can figure something out -- an amazon gift card or something like that could help split the cost to acquire & reproduce the setup. Where it really starts to get scary is if I have to acquire a specific TV model to reproduce, but so far the TVs usually aren't the culprit, it's the video sources that tend to be non-compliant.

That being said, I could see a sound bar causing a problem -- I've never actually tested the system with a full Dolby surround-sound system (as I don't have one), and such a configuration would put more data islands in the sync periods. Data islands are encrypted using the same cipher stream as the video, and if you choke on a data island the cipherstream becomes un-sync'd and the video also goes to snow.

So if you do ever get around to poking at this, I'd love it if you could try to configure a basic sound mode to compare against your preferred setup -- a minimal, base stereo, standard bit-depth stream followed by an unplug/plug cycle to rekey the ciphers would help establish if maybe the issue lies in the increased density of the data packets being sent over the wire when working with a hi-def audio setup.

And like I said, no hurries. I just closed a dev cycle on the NeTV2, so any findings from this will be revisited when I open my next dev candidate & release cycle in a few months. The good news is I haven't seen an +1's on this bug, so it could be more of a fascinating corner case than a broad-impact bug. But other users, if you're reading, drop a comment here if this bug impacts you so I know how to prioritize it!