If you remember my last post, I had finished sorting out the hardware, and had just taken the plunge with fishing around for working embedded software. I’ll be honest, it didn’t take many attempts to find a “working” solution, but each attempt felt like an age due to the switching between programs to use XMODEM. For some reason RealTerm doesn’t support XMODEM, and TeraTerm simply wouldn’t send the data. I found ClearTerminal, which although managed absolutely fine with XMODEM there were issues with interrupting the boot process of the camera; a necessary step when dealing with experimental Linux images.
I hit various brick walls, including the camera having a “Kernel panic”, and numerous I2C errors. The Kernel Panic was due to a completely incompatible firmware, and the I2C error seemed to be triggered by some “missing” hardware. Missing in that the camera would support it, but it simply wasn’t included in this model.
On the forth attempt I tried software designed for the HooToo camera – and not only had the camera booting up, but I also had a web interface to use. This wasn’t the nicest interface in the world, but at least I could see the video stream and control the camera. The hardware was fixed, some software was running; job done, or so I thought.
This camera originally came with some software that when installed prompted the user to enter the camera’s serial number. This serial number is used to tie together the camera and a DDNS service. DDNS stands for Dynamic Domain Name Service, and once set up it allows you to view the IP camera from anywhere in the world. The HooToo software has an unknown DDNS hard coded, or allows you to specify a different DDNS service. Unfortunately, this was restricted to DynDNS.org and a couple dodgy Chinese services that my browser warned me against visiting.After some digging around I realised that the DDNS information is held in the romfs.bin file, and that it might be possible to use parts of my original extracted romfs.bin file to overwrite HooToo’s default DDNS service information.
At which point it struck me, I already had a working webui.bin and romfs.bin as it was just my linux.zip file that the camera had decided it didn’t need anymore. So I reflashed my original working files and the working linux.zip from HooToo and … it didn’t work. Well, that is not strictly true. The camera was working, and I could use an additional piece of software to control the camera, and get its video feed, but the website was a pink background with “Page not found” plastered on it. I assume there are some checks in the implementation of that uCLinux that checks the versions of romfs.bin and webui.bin.
For me, the challenge had been won with the HooToo firmware. I had traced the problem back to some shorted pins, and theorised that the problem was with the position of the ARM processor relative to the mounting hole of the camera. The camera was now in a usable state, and the intellectual challenge was over.All that was left was to brute force the firmware issues. I emailed StorageOptions on the off chance that they would take me at my word, and not think of me as a backstreet manufacturer too lazy to play with embedded software. They have yet to reply to me, so I have resorted to creating a table of every possible combination of linux.zip, romfs.bin and webui.bin to find other working combinations. If nothing, this will be some potentially useful information to feed back into the community.
And now, I stalled again. I made the mistake of sharing my progress with the customer (i.e. my father-in-law), and he was so impressed that I’d brought his camera back from the dead that he wanted it back. The website and DDNS functionality weren’t working, but he is fine with that at the moment as you can still view the stream and control the camera from an additional piece of software. I would be surprised if a mobile app wasn’t in existence or in progress, and the DDNS issue can be resolved by remembering your home’s IP address. So it is with a heavy heart that I bid farewell to the camera. It has been fun.