[020] LKV373 Update - GCC for the IT9919 

If we can build some momentum around these chips, they would be useful for lots of interesting projects. An open source firmware for these devices could unlock some really cool functionality e.g. swiss-army-knife of internet connected casting/streaming equipment, video-capture Raspberry Pi/FPGA modules. But to achieve that, it's going to be quite a big job - so we might see some proofs of concept, but to build a proper user-friendly firmware would require a team to dedicate themselves to make it happen. And in that time, will the chips remain available? I don't know where to source them right now. Are Lenkeng making new stock, or just running down the last remaining IT9070s and 9919s ? Are the newer higher-res Lenkeng devices related? - are those a better platform to processed with? We will hopefully find out soon when I do the teardowns. So for now I'm just interested to see where this goes, and how people respond to it. There are plenty of interesting avenues to pursue here if anyone cares to look into it.

Yea, me to, he does have `set -u` at the beginning of the script """-u When the shell tries to expand an unset parameter other than the '@' and '*' special parameters, it shall write a message to standard error and the expansion shall fail with the consequences specified in Consequences of Shell Errors."""

Certainly having a C compiler will make further experimentation much easier. The hacky python homebrew assembler was pretty accident prone to work with. At the moment we have no way to send input into U2 - but if we did, perhaps we could write a gdb remote debugging server for the IT9919. But that would probably be overkill for LKV373 experiments. It appears that the U2 software is actually very simple: all it does is kick off the capture/encoding engine - so as you say, just dumping the register settings would be extremely helpful. I need to take another look at the EzCAP 283S firmware - because I previously suspected it was powered by an IT9919, and it uses the chip to do a lot more: it has USB Host and Slave support, file systems, HDMI input, RGB888 input/output etc. So there's plenty of directions to proceed here. If you're interested in getting involved, I suggest lurking on the #lkv373a IRC channel on FreeNode.

what about www.it7090.com

@@DAVIDGREGORYKERR does not seem related

@@MissingClara I was able to browse straight in text was all in Chinese.

Interesting. These LKV373 devices have a non-populated jack connector. Other Lenkeng products seem to come with an IR widget on a jack cable. My understanding is that MU1 controls/monitors U2 through the Host SPI link into U2's memory bus. U2 encodes the HDMI into H.264 wrapped into MPEG-TS packets, and transfers it to MU1 through a TSI serial link - which is a defined standard for MPEG-TS transfer.

Glad you're enjoying it. I just wish I could post more often - but that's life. About the terminal: I switched from using tmux+vim to using vim8 which has terminal support and support for multiple windows and splits. The benefit is that can keep everything in a single instance. My vim config is here: github.com/jhol/shellrc/blob/master/vimrc In the terminal in vim8, the default key-binding is Ctrl-w, N to break into "normal" mode in the terminal which lets you move through the buffer and yank text just as if it was a normal text file. Then press i to return to "insert" mode i.e. normal terminal operation. I use the tinykeymap plugin to make window management feel more netural to a former tmux user.

I know about it yes, though never actually used it. Someone said it doesn't have or1k support yet (maybe a side project for someone). Anyway, in this case I think it's good for people to understand how gcc bootstrapping works - even if they never do it. Most of the time, a crosstool-ng or a distro-supplied compiler is the right answer

There is a LKV373KVM on ebay also, which have a few USB ports.

From what we know, I think that's now ruled out. It seems to be an ITE processor of some sore, and we suspect it contains an ARM core of some kind. In general an FPGA would be an expensive part to put into a cheap consumer device like this. 10-years ago when 1080p was brand new, before there were mass market chipsets, devices like this may well have contained FPGAs. They would have also cost $$$. I'm sure 8K will go through a similar evolution in the next decade.

I'm sure you're correct - though it seems like overkill, when you can implement printf with a simple state-machine.

@@OpenTechLab I think part of it is also that some implementations avoid the syscall and such (think fflush), and so must maintain the buffer somewhere thread safe between calls.

Good point. An unbuffered state machine would have to flush constantly

Excellent question. Perhaps I should have explained in more detail. I added a note to the show notes, I used my call-graph script from the previous video to dump out the call-graph of the whole of the Lenkeng upgrader software. I then used the networkx graph library in python to isolate the sub-graph of functions called by puts() which I knew the address of from previous experiments, which gave this diagram: opentechlab.org.uk/_media/videos:020:20191002-puts-printf-subgraph.dot.png?cache= From various other hints in the strings, I suspected the software contained a build of newlib of whatever vintage. I then used the or1k disassembler to try and piece together a plausible theory for the number and type arguments to the various functions called by puts(). Still quite uncertain, I decided to take a punt on 0xa512c being the correct address, and voila - it worked! In future jobs like this will be a bit easier, because v3l0c1r4pt0r has written a patch for radare2 that adds support for or1k.

@@OpenTechLab Thanks for the explanation! It seems to be a fair amount of work.

It took me about four evenings and a Sunday afternoon. It was tricky, yes, but I was reusing a lot of bits of code and information left over from previous work. Otherwise it would have taken a lot longer

Haha, his voice is close but not quite there for me. Do love some David Mitchell though! :)

Yes, I think that's part of the FAT filesystem handling code. All the web assets are stored in a read-only FAT file system embedded in the image

@@OpenTechLab That sort of makes sense, but Fat doesn't have any hard nor soft reliance on DOS, so it does seem out of place.

Yeah and a few more copies have been found now. Check out the show notes for links

Just on this device

I'm not dead, but it's a bit hard for me to make videos right now.

@@OpenTechLab Glad to hear that you are still alive. Just started watching your videos and really enjoyed it. Please find time&energy to make more. Thanks, a new subcriber