creating flashable firmware

[hbfs]

Requirements to create an open source firmware image include:

1) Build SDK 2) Write to NAND flash

Anything else I'm missing?

Base features would include:

• WiFi
• SSH
• RTSP
• Web interface
• IR control
• MIC control
• Motion detection

Feel free to include other features you would like and if they should be included in base or optional.

[studioBeaver]

Motion detection on camera would be super nice feature!

[samtap]

FYI: I have no intention to spend any time on this. I'd be happy to cooperate with someone who wants to create a fully functioning standalone firmware and share my thoughts on it. But I don't really see the point (and I doubt if people requesting features realize how much work is actually involved, and what benefits that work would bring as opposed to how it is currently done with stuff on the sdcard).

I'll leave this open for a while (I've closed a similar issue only a couple days ago) for you to discuss things but I recommend you create a new github project to take it any further.

[hbfs]

@studioBeaver good call! added motion detection.

@samtap: the SD solution is a great starting point and I'd like to have a permanent solution without requiring an SD card.

how much work is actually involved

Can you explain in more detail?

I've closed a similar issue only a couple days ago

I saw that post. This is a specific firmware image for this camera, not a generic framework for all cameras. It could become a generalized blueprint in the future but there are so many different hardware types and requirements and that doesn't make sense to me at this time.

I recommend you create a new github project to take it any further.

It seems detrimental to fracture the community as both projects have nearly all the same goals -- only difference being one is writing to SD card and one to serial flash.

[samtap]

I really don't want to waste any more time on this so this will hopefully be my last comment on this topic.

No offense, but the fact that you have to ask me how much work is involved, shows you have no idea. I'd be happy to join forces with someone willing to create a flashable image, all I'm saying it that I'm not planning to spend any time on it, therefore it does not belong on my github. Worrying about a 'fracture in the community' is silly since there's no community to speak of, just a bunch of users. And I'd be happy to link to any related projects, prominently on the main page.

If I have to decide between spending 5 bucks on an sdcard that has i.e. 16GB of fully writeable space, that I can swap to my laptop for debugging etc, or spending hours upon hours to create a flashable image (with no clear benefits??), risk damaging the flash and/or bricking my device, the choice is simple for me. Besides that we're talking about a camera device so using an sdcard for snapshots and recordings makes sense anyway... Even if you do want to get rid of the sdcard, it's very easy to change some scripts, copy binaries to device and you're done (others have done that already), you really don't need a flashable image for that.

There're also lots of practical considerations, i.e. the SNX libs is simply not opensource. You will have to copy the libraries etc. from the proprietary image if you want to do anything with the camera hardware. You'll also find you will not be able to satisfy all user requests. The internal flash is simply too small to contain everything that users want. You don't have to worry about all of this nasty stuff like bricking the device by accidentally filling up the flash when you have GiBs of gratuitous space on external flash (sdcard).

For me, the 'OS' part of the device does exactly what I want. I can run whatever I want, switch cloud on/off without too much hassle, transfer files, access shells etc. The challenge for me is the camera part, not the Linux OS part. I want to spend my time on application features to make it perform at least on par with the cloud apps, create a lightweight (web) user interface etc.

[hbfs]

Not sure what your hostility is about. This wasn't a feature request. A few folks and myself are happy to work on this. I wanted to hear from other users if we missed anything.

I was hoping you had something insightful to add regarding firmware about this device and if there was anything unique about the platform.

The difficulties you've mentioned (binary libs, no datasheets/SDK) are standard for hardware you dont create yourself. You can look into how linux-rockchip and linux-sunxi overcame this over the past few years to get to open source drivers.

Fortunately, this wont take a few years. It was easy to get in touch with the folks at SoniX. I plan to have the official SDK in the next few days. Whats practical for you and others is quite different.

Its great that you want to focus on the application layer. Many features and performance can be had if you can hack deeper. Only a thorough integration of both sides will make this amazing.

A bunch of what you wrote is misinformed or incorrect.

You don't have to worry about all of this nasty stuff like bricking the device by accidentally filling up the flash

Device bricks are hardware failures or boot loader being overwritten/corrupt or missing. Even on the current firmware if you fill it up will not brick the device, it will start spamming "device full" errors when you try to re-mount it r/w or write to it.

If you can flash the device, its unlikely you can even brick the device. SoCs such as this often have a boot from SD / USB as part of the init sequence so you can always recover. The public SDK someone found seems to indicate this.

switch cloud on/off without too much hassle

Thats unnecessary. With firmware change you can enable multi-streaming. Alternatively you could instantiate a lock and mmap the video interface for both cloud and RTSP allowing someone to switch between apps without manually starting and stopping the services over SSH.

Given the option, I suspect most users prefer a 1-click flashable stable firmware image vs a development SD card that requires a lot of manual tweaking.. I'll create a fork with this goal in mind.

Feel free to leave open for comments or close.

[gonzoblue]

I think the main problem is you created this under the ISSUES section, which is not where this should be. I don't think anyone is against you trying to do what you said, but also like you said, create your own project or maybe discuss it in the wiki, but this area is for actual problems with this project.

[samtap]

@hbfs I'm sorry if I sounded hostile. You have to understand I'm spending a lot of time answering 'issues' here and on discord which often turn out to be user errors, instead of working on the application which is what I want to do. I fully support your idea to fork (this is github after all) and obviously a 1-click flashable image is much more friendly for end-users.

I assume you've found the thread on the yi-hacks page? There're some comments regarding flashing an image. The bootloader checks for firmware on sdcard but I don't think anyone was successful in actually flashing it, yet. Until someone is, there's a risk to do damage. It happened to my in different ways, requiring a serial console to recover, which is obviously not something you can expect users to go through.

My current image is simply a platform that allows experimentation and further development in a 'safe' way. One of my goals was to attract folks like you since I'll never be able to unlock the full potential of the device by myself alone. But for now I'm reasonably happy with the core, while the rtsp server leaves a lot to be desired, let alone features like recording, snapshots and motion detection which are not present at all.

I look forward to downloading your image with multi streaming cloud app + rtsp server from your github project shortly!

[conradhagemans]

I tried to compile a new version with the SDK mentioned on the yi-hacks page. But that SDK is missing the correct libraries. I want to create a snx_rtsp_server with authentication. So if we can get the correct SDK I will give it a try.