

Author Topic: Is there such a thing as OpenNVR firmware?  (Read 8403 times)

  • No avatar
  • *
April 10, 2017, 03:47:22 pm
Hey folks,

I'm relatively new to this IPCam world and thanks to all of you I've managed to answer most of my questions.

I do still have a couple of questions that I'm hoping you can help with.

Question 1:
I recently picked up a few of the cheap chinese IPCams that are running this firmware:
They have an internal ID of H264 50H20L_S39.

Based on what I've read in these forums and others, I believe this means they are running the HI3516C System on a Chip. Can any of you confirm this?

Question 2:
I see that we have an open source camera firmware available. Is anyone working on an open source NVR firmware?

I'm specifically thinking that it would be great if we had firmware that supported these generic NVR boxes out of China. For example, firmware that supports the HI3535 chip would be pretty good for someone like me who just wants a a few cameras at 1080p.

For me, I'm less concerned about people viewing my cams and more concerned about opening a back door into my home network. Having an open source firmware that is known to be secure and not part of some bot army might alleviate some of the worries many people seem to have regarding the security of these generic NVRs.

And yes, I realize I can double or triple my budget and get a better NVR. I might just do that. But first I wanted to understand what the minimum viable setup looks like.

  • No avatar
  • *****
April 17, 2017, 10:06:25 pm
Not really (opennvr firmware)

What you'll need to do is get hold of the SDK for the chipset, so that you can compile a kernel and app's.
Once you have that, then you can start building firmware and flash.

Issues are that not all hardware is identical, so you will have different NAND types, flash sizes, gpio usage etc.
Not insurmountable, but you'll generally want to pick the same hardware to develop, and port to.

The SDK for the HI3615C is here - http://pan.baidu.com/s/1o8TWZ0Y----

Let me know if you have problems downloading, I can put elsewhere.

Generally speaking, you'll want to open up whatever hardware you have.  Add serial headers, and connect up serial for minimal debugging, and for more serious stuff JTAG.  Boot up the hardware, and see what it tells you.  Hopefully you'll be able to see a boot log and bootloader, and communicate with it.

Developing with just serial is viable though if the hardware isn't too locked.
i.e. hopefully the device will have an accessible bootloader, then you can flash kernels and filesystems without too many headaches.

The flash will generally contain a bootloader (don't overwrite this, otherwise you'll need to use an SPI flasher or similar to rewrite).
The bootloader will load a kernel from the flash into ram, then execute it.
The kernel will then mount a filesystem from flash, and run the OS + programs.

A BSP or SDK allows you to build a kernel and programs (BSP = board support package.  SDK = software development kit).

Thats a brief overview.

  • No avatar
  • *
April 21, 2017, 09:30:28 pm
Thanks for that. Sadly that's all beyond my skillset, though I do know some EEs who might take it on as a side project.

I was kind of hoping to find that some industrious folks had already started a replacement firmware for one or more of the generic NVRs out there.

Oh well. I guess I need to knuckle down and find an NVR with software that doesn't suck. If you have any recommendations, I'd like to hear them.

Thanks again.

  • No avatar
  • *
January 04, 2018, 06:37:36 am
I know this thread is a bit old but it seemed to be a relevant starting point.  I've read through the forums for a while now, but still don't get the answer to what's probably a pretty noob question.

Why hasn't anyone tried to define a standard spec that would allow cross camera firmware to be written?

Yes, I have some idea of the nightmare variations of hardware out there. But the thing is, this problem has been around in a lot of areas, and usually a specification is defined to allow HALs (hardware abstraction layers).  The idea being, if a manufacturer opted in, they would be compatible only by having to maintain a thin abstraction layer, on top of which higher level firmware abstractions were built.

A real life example of this is Android phones. Ever notice how lots of Android phones get slow updates or none at all?  It was partially due to a similar problem of many different hardware designs.

So now to try and address this, Google is investing in something called project treble, to make HALs more consistent, well defined, easier to maintain.  One quote about it: 

"To solve the hardware abstraction layer issue, Android O formalized the division between hardware sub systems like audio or camera, and their clients on the software side. These new formal divisions specify the interface between a HAL and its users. There are now around 60 formal interfaces for various hardware components, known as HIDLs. The goal of a HIDL is to allow the framework to be replaced without having to rebuild HALs. HALs will be built by vendors or SoC makers and put in a vendor partition on the device, enabling the framework to exist in its own partition..."

So the noob question is, why couldn't at least a basic HAL be spec'd out to allow cross camera firmware?

Is the only issue getting a company to build a camera that supports the spec?

Could a kickstarter gain enough traction to allow one to be built with the pitch being, the worlds first truly open IP camera?  It would seem like if just the one camera got enough orders, it would catch the attention of other manufacturers, maybe add some pressure to collaborate on some standards.

Ok I'm ready to know how crazy all this thinking is, if anyone doesn't mind helping me to understand.


« Last Edit: January 04, 2018, 06:39:58 am by lwl »

  • No avatar
  • *
January 19, 2018, 10:51:23 am


The sucky part about the things is the monolithic package containing the recorder and webserver components (It's Sophia for XiongMai-sourced stuff.) One of the first tasks is to pick it apart, see what the component programs are (it's effectively a distro inside a distro) and what they do.

These systems have wildly different functionality inside and outside China, if you read chinese you'll see there's a lot of things like automatic upload to central authority sites and similar stuff that isn't there in non-chinese mode. It could be that the binary is packed up tightly so that people can't see the level of snooping that goes on.

The actual Chipset linux distro itself is easily buildable from the SDK as mentioned.

What would be AWESOME would be to port zoneminder to these devices. If you check out the zoneminder website you'll understand why.