ROVA Tools – Programmer for Realtek RTD2660 / RTD2120 LCD controllers

If you recognise this, chances are you’be been tinkering with LCD panels too:

RM5451 LCD Controller

The RM3251/RM5451/RM5251 LCD controllers offered hobbyists one of the first ever opportunities to create their own LCD display centric contraptions. Prior to this, the LVDS interface featured by almost all LCD panels was a mystery, with scores of tinkerers wondering how on earth to interface this to something more familiar, i.e. VGA or DVI.

One day, I saw this on eBay:

ROVA USB-TOOLS Programmer

I’ve seen a few of these over the years, normally you get one posted to you when you engage with a LCD controller firmware company, right after signing a non-disclosure agreement, and handing over a lump of cash.

But on eBay? This is interesting. I had to hit ‘buy’. The seller, NJYTouch has managed to get their hands on the programmer software for this family of boards, and a whole bunch of firmware images for different panels, and they’re selling it on eBay for hobbyist money.

Disappointingly no source code was included, but this was no surprise to me. I’ve not seen a single line of source code for these controllers in my life. That isn’t to say it’s not out there, there’s plenty of sites flogging off leaked source snapshots of these boards.

The good news is that the CPUs on these boards are almost always 8051s, which is pretty easy to reverse engineer.

Enter ROVATools. My creation of the last few years. I first started on it in 2011, then abandoned it due to lack of time, and picked it up again in 2014.

There are two main programs:

ROVAEdit – RTD2120 boards only

ROVAEdit LCD Controller firmware editor

This gives one access to pretty much all of what you’d need to change when creating an image for an unsupported panel. This program can only edit the firmware for supported R.RMxxxx boards.

ROVATool – Programming software

ROVATool – Alternative programmer for R.RMxxxx and PCB800099

The mainstay of my tool suite is descrambling the .GFF files so they can be edited. Because I don’t have a mechanism to re-create .GFF files, this software has to be used to program the controllers.

Normally the Parallel programmer is for PCB800099 and ROVA USB-TOOLS is for R.RMxxxx, but with this software, you can use either programmer to program either board. I wouldn’t recommend buying the Parallel programmer (aside from the obvious, how many PCs still have a Parallel port?) – The USB Programmer is just a much cleaner and easier solution.

The supported Parallel port programmer. There’s more than one design of these, and chances are, they’re not all compatible.Programming an RTD2660 based board with the Adafruit FT232H

Other benefits

Even if you don’t need to make an image for an unsupported LCD panel, there’s still some benefits of using my tools:

Ability to remove OSD popups which can pollute the display output

Up-to-date programmer software with 64-bit operating system support

No requirement for the ancient DLPortIO driver, for those concerned about the security vulnerabilities exposed by this package

OSD Popups making your project look unprofessional? Banish them with ROVAEdit 😉ROVATools comes with a built in EDID reader to read EDIDs directly from displays over the wire. Handy for the casual screen hacker.

Download

I’ve split the download of this into two files:

ROVATool – This is the programmer only, for both RTD2120 and RTD2660 platforms

ROVASuite – This is the programmer and editor, for only RTD2120 platforms

great work on Rovatool – seems to be just what I need to get this adapter here to output the correct 24 bits…

I’d like to try my hand at programming the board with an arduino instead of a parallel port programmer – I really don’t want to get the old box with a parallel port out of storage.
Would you be willing to elaborate a bit on the I2C programming (Addresses, commands, Datasheets etc?)

Sorry to hear that – there’s several projects to program these boards via a parallel port adapter, but for USB, we’re still stuck with a proprietary Chinese adapter. An expensive one, I might add, for what seems to be a basic USB->I2c interface that any 5 USD arduino clone would suffice. Now, I understand that part of the programmer cost is actually firmware development – but there is a russian open source firmware project for the RTD2662 http://openrtd2662.ru/

Apperantly you can talk to the I2c port in your vga adapter directly on Linux – that would be more interesting than doing it with an arduino – no additional hardware necessary.

Perhaps allow me one final question? Do you have a better source for the I2c commands to enter isp mode, etc, than the Postal2 source code? It’s pretty straight forward, but perhaps there’s an additional data sheet that I’ve been missing?

Thank you Matt very much for your effort. The tool looks great !!! I understand that I can change virtually any setting of existing configuration and upload it to the controller, but can I change the EDID signature on existing controller ?
I have R.RM5451 board and ROVA USB programmer. I do not want to change display setting, only the EDID signature. Is it somehow possible to download current settings from the controller, change the EDID and upload it back ? Or change the EDID only ? I am not sure what GFF is used and do not want to screw working panel. Thank you.

Matt, interesting read and nice write up of details for these boards. Like Tyberius Prime, I too have been looking into the possibility of flashing via Linux without any special interface board. I’ve managed to make progress in reading information of my current monitor via I2C on my Ubuntu server so I’m on the right track. I’m wondering if you and Tyberius ever got in touch and if they had any success in flashing directly under Linux. I’ve got a PCB800099 board on the way and have a few different LCD panels I’d like to test out. Being able to flash between configurations will be a must. Fallback plan of course is just to invest in the USB programmer (or Parallel port… think I can still dig up a PC that has one) and use your software, or I’ll just see about desoldering the W25X40 chip off the board for SPI programming.

Yep, understood. Maybe someone with the programming skills (I can hack around a bit but not much) will get in touch with your or other developers of applications for I2C programming and work something out. It certainly would be nice as it would then (hopefully) be dreadfully easy, maybe needing nothing more than the proper VGA cable, a computer with VGA output, and a bootable Linux disc/thumb drive.

For right now though I am all set. I continued my searching (and learning for that matter) and found info on doing SPI ISP (Serial Peripheral Interface In-System Programming in case I lost anyone there…) with the Raspberry Pi I already had to attach to my PCB800099. Five wires from the RPi to the W25X40, a couple minor software add-ons to Raspbian and I was good to go. I’ve now got my PCB800099 that was originally flashed to support some 7″ LED LCD screens via FFC interface able to control a Samsung LTN121XF-L01 12.1″ screen that was pulled from a Dell C400. At least it looks like it is controlling it OK, I don’t yet have an inverter for the CCFL of the screen to backlight it. Certainly a cool learning experience. I plan to do a write up either for an RPi forum or Wiki, if I get that done I’ll return here with a link.

As far as the binary ROMs for these controllers go, can you enlighten me any on the content? In particular when I was flashing my board I first did a read and backup of what was on the W25X40 and got a 512K ROM. All the alternate ROMs I had to flash were 256K. Since the flashrom program I was using required a matching sized ROM I had to experiment a bit. Some poking around in them has led me to believe that the first 256K on the chip is the necessary information for the screen itself (EEID, OSD, etc.) and the second 256K may just be where settings (last selected input, color controls, etc.) get saved. Backing this up is that if I write a 256K ROM I customized to 512K to the chip I can immediately read it back and verify a match, but after using the controller (in which I may or may not have done something like alter the input selection… I forget) if I try to verify the chip contents again it doesn’t match. Your take?

Thanks again for your write ups about these devices and the programming, as well as your input in the comments. It led me down the path where I have both learned some new tricks as well as accomplished something!

Roger, happy to share my knowledge with you by direct contact since I don’t have anything well organized to put out on the ‘net at this time. Drop me a line via the name I’ve used in this comments section, at craftech dot com. Still hope to have something in the future to throw to a forum or blog.

Matt, I can confirm that within the first 256k that may be the case. in the ROMs I was using, since that was the size of each file that was available for flashing. Since under Linux the flashrom program would only write a like-sized (full-chip I assume) file I had to figure out what to do with the second 256k. Since the earlier post I’ve done some more tinkering. I kind seller on eBay that had a Dell C400 laptop for sale worked with me to get some (rough) EDID data for that screen. So I was back into a hex editor to cram that into the 256k ROM I was playing with. After updating the multiple EDID locations I then padded the ROM out to 512k with 0xFF. I don’t believe I’ve modified settings and then read the ROM back but I’ll probably do so in the future. It will be much easier now, I’ve picked up an SOP8 clip. I really expect to find that the trailing 256k of 0xFF now has some alterations to it, but maybe I’m wrong. I am curious to find out!

Hi Matt!
Your work is great and ROVAtool works perfect, but I have some problems due to my lack of experience. I’m working with PCB800099 board and Keil project RTD2660_AV1_AV2_081015, trying to make some custom firmware. The main problem is that I have no idea how to use the output files after compilation, which are *.h00, *.h01, *.b00, *.b01 and *.gff but there’s nothing like *.bin or *.hex which are accepted by your ROVAtool. I tried to use Gff2Bin and Gff2BinCmd with generated gff file, but this software crashes everytime after opening any gff file.
So…. I’m stuck and will be very grateful for any help 🙁

You were right. In compiler’s options for target, there is checked an option for code banking with set two banks. But when I uncheck it, what suggest compiling without banking, compiler is linking for very long time, ending with billions of errors and target not created.

I’m using uVision4, but it’s unconnected. After my explorations of the “eastern side of the internet” I realised that there are two versions, or rather copies, of this project sharing the same name. “The broken one but easier to get” is missing some files and ending compilation with not finding a file BL.lin. The working one is a bit troublesome to achieve, so I can share a copy with you if you want.

Were you able to build working firmware for PCB800099?
Firmware I build works, but image on screen toggles few ms on and few seconds off…
There’s also size difference – all internet bins are 256 and source code is made to produce 128kB bin…

OK, I was able to build the (default) target. The end result is a GFF file and in my case gff2bin.exe also crashes on any gff file.
Clearly (from the build process) the .H00 and .H01 files are hex files for the 2 banks. Still a mystery how to create 256K binary out of it that ROVAtool will take…

I’m trying to understand the sources. Right now the big mystery is the multiple “panel” definitions in the include files. For example 640×480 and 800×600. Sure every panel has only one native resolution. Why “Panel0” and “Panel1”?

Tried different approach too. Desoldered Winbond 25x40BVNIG (eeprom) and checked its contents. What is inside seems to be just *.bin for particular LCD panel. But there is a catch…

Near address 0x7BFF8 there is area that could be checksum or some settings. Fresh *.bin files downloaded from manufacturer page have area filled with FFs there. Trying to program such *.bin with area filled with FFs causes device to not start. Copying that area from original eeprom content to new bin file also doesn’t help.

Area starting from 0x7C013 also changes when device is running… not sure what is hold there.

And I’m stuck now. Still trying to somehow get new bin (for my lcd) working.

Hi,
I have RTD2660 based board with TV tuner and jumpers for setting resolution/panel type. It bluescreens. Searched the web and found three versions of source code for it. All of them are on chinese websites.
1] KR2660_DMB_AV_TV_VGA_WJ_20100331.part01.rar
this one actually compiles in Keil, producing BIN but size is over 128k, so I can not fit it to my flash
2] RTD2660 AD Board.zip
this one is incomplete, it is missing BL.BIN and other files. But it have far more header files for different panels.
3] RTD2660_AV1_AV2_08.rar
RTD2660_AV1_AV2.rar
RTD2660_AV1_AV2.rar
RTD2660_AV1_AV2_081015.rar
one of these should be whole package. I was not able to find place on china internet where this can be downloaded. Could someone please send it to me to spam@kolins.cz ? (this is regular email, do not worry 🙂

I have backup of original firmware with multiple panel support. I searched whole internet back and forth and everything I downloaded is herehttps://kolins.cz/share/index.php?folder=UlREMjY2Mg==
Hope it helps someone.
Any information on how to compile, upload etc is welcomed.
Mirek

I was wondering if you could edit the blue screen away completely with your software? I am getting into First Person View (FPV) flying with quadcopters and often LCD monitors will go to blue, or black screen when the quadcopter is far away or behind trees because of a “weak” video signal. While the signal may be “weak” a pilot can still make out some features, and maneuver back to safety if they had a “snow screen”. Snow screens are incredibly hard to come by. Normally in the $200+ range, but from what I understand its all in firmware. Have you ever tried to do this?

I’m trying to get the LM R25 controller (declared as a new version of R3251) working with the AUO B121EW03 V8, haven’t got any result yet. The original dumped firmware (not working) is a BIN-file, the 2nd firmware from njytouch (not working as well) is a GFF-file but ROVAEdit generates parse error when I’m trying to open the XML-file generated by Gff2Bin. So I’m still confused.

I want to use the ROVASuite with a RTD2120 based LVDS controller, which is not exactly the same board as the R.RM5451 but has the same hardware (M25L-VDA3). I use a FTDI based interface with the FT2232H chip.

Now I have the problem that I do not have any working .gff files to start with because I did not buy the USB programmer from njytouch with the CD that contains these files (did not need it because I already have the FTDI interface and currently, it is not even available for sale). I downloaded some other .gff files from various sources and split them with gff2bin but the resulting files can not be opened with ROVAEdit (gives me parse error). Possibly, they would not work anyway even if the editor would be able to open them because they are not for LVDS converter boards with the RTD2120.

I have created a backup of the original firmware with the postal2 software that was also mentioned in the comments here but I do not know how to convert these files (1x 96K binary, 1x 266K hex) to the format that ROVAEdit needs (might not work at all). Could you please upload (or send me an email with) at least one of the gff files for the R.RM5451 from the CD that came with the USB programmer so that I have a file that the editor can work with? As far as I understand, one file would be enough to create all kind of different resolutions with the editor and the EDID designer. Is that correct?

I’m probably blind and just can’t see the option, but does the RovaTools suite allow for downloading firmware from the PCB800099 – RTD2660 controller? I have a working controller panel combo and couple of loose controller boards. I want to try cloning the good firmware to one of the loose boards so I can experiment with changing EDID values, testing alternate firmware and such without bricking the good board. If it makes a difference, I’m using the Adafruit FT232H as my programmer.

Thanks for the heads up. I’ve managed to get what I needed from Ghent’s project. I kludged together a python port of his/her source using Adafruit’s python library for the FT232H. Using that I was able to pull down the firmware and successfully match it against one of the known images. I flashed it with your tool to the other board and now Bob’s my uncle.

@el-sahef:
I’m also having problems with the M25l-VDA3 board in that my backup of the board has been lost (long story), and I currently have a blank board (no firmware at all). Does anyone have access to the firmware for this board that they would be willing to share? Or, does anyone know if there is an alternative firmware (such as one for a R.RM5451 board) that might get this working again?

I’ve been using this successfully with an RTD2660/PCB800099, but I’ve recently bought more boards and now I get “Error: Unsupported memory device: 0xEF134014” every time I try to program them. I can program the old board over and over, but if I try to program new boards it never works – even despite trying new boards 3 times… Has anyone any ideas what this might be? Or what this error means?

I spent quite some time years ago trying to add support for this. The NovaTek does some pretty ugly stuff during programming which rules out the use of I2C protocol programming, it has to be PIO/bitbang, frustrating my attempts to make progress on it.

Additionally, last time I looked at this there was no known documentation or example of an algorithm for these chips. I did some USBSnoop analysis using the Novatek EasyWriter tool, suffice to say that it is totally and utterly alien / different to the protocol used by Realtek chips. Very significant undertaking indeed.

If you know something I don’t, I am always prepared to work with others to enhance the capability of this tool, including handing out the source code in these cases!

Another thing to consider, is that the NovaTek writer tool isn’t *that* bad. In my view there was no real need to undertake this effort.

Hi
Could you send me a link to the Novatek tool? I can’t find it.
Also, I’d like to take a shot at the programming as I have a current need! Would you be willing to share source with me?jbdean@gmail.com
Take care,

Hello Matt, may ask a question? You may know.
I have R.RM5451 board and 5.6″ 1280×800 LCD panels – Toshiba LTD056EV7F and older HYDIS HV056WX1-100. They do have LED backlights. Toshiba panel has slightly slower response, but the colors and black is great. The black on HYDIS panel with the same R.RM5451 firmware/configuration is really not black, but somehow grayish. Brightness setting can make the “black” even less black and yellowish, with values above 50 (from 0 to 100 range) but does not seem to have any visible impact at lower values.
Are you aware of any configuration or even HW cable modification that could improve the black with the LCD?
Thank you!

Hi, I’m trying to modify the source code under the name Source1_081015_PCB800099. I have a problem that when VGA input is drawn only source of blue. Red and green not working. Does anyone have any advice on how to fix it. Somewhere there is an error in the source code, but I can not figure it out.

Last year I wrote an rtd266X programmer that uses the VGA connector on your PC to do the programming under linux. I don’t think anyone has noticed its existence, so thought I’d mention it here in case others find it useful. https://github.com/static-void/rtd266x_programmer

I did see your project. Particularly impressed with the GFF interpreter. I had a crack at writing one but gave up as I couldn’t quite figure out how the scrambling worked.

How did you figure out the programming protocol?

I first cracked it about 7 years ago, by studying ROVAWriter using USBSnoop and various other hatchet job tools. There was some I didn’t figure out the purpose of i.e. the writes in your SetupChipCommands() function.