tm-robinson
commented
6 years ago Ok I have managed to get strace cross compiled and running using the SDK. This was the method I used that worked:
- Install the SDK, so that
/opt/hisi-linux-nptl/arm-hisiv100-linux/target/bincontains all the compiler binaries e.g.arm-hisiv100nptl-linux-gcc - Set cross compiler environment variables:
export PATH=/opt/hisi-linux-nptl/arm-hisiv100-linux/target/bin:$PATH export ARCH=arm export CROSS_COMPILE=arm-hisiv100nptl-linux-(Not sure if these are required or not)
- Download buildroot and run the compile process on the website, with strace turned on, which downloads the strace source code.
- Locate the strace source code directory within buildroot (for me this was
~/buildroot-2018.05/output/build/strace-4.21) - Run the configure command specifying the target host type so the SDK cross compiler is used:
./configure --host=arm-hisiv100nptl-linux - Run
make - Copy the resultant
stracebinary to the camera using FTP - Attach
straceto one of the existing processes e.g. tormm:/tmp/sd # ./strace -p 923 ./strace: Process 923 attached nanosleep(0xfffffffc, 0xbef0caa0) = 0 open("/dev/isp_dev", O_RDONLY) = 28 ioctl(28, _IOC(_IOC_WRITE, 0x49, 0, 0x4), 0xbef0c234) = 0 ioctl(28, _IOC(_IOC_WRITE, 0x49, 0xa, 0x4), 0xbef0c238) = 0 ioctl(28, _IOC(_IOC_READ, 0x49, 0x9, 0x4), 0xbef0c23c) = 0 mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0x81621000) = 0xb5f70000 munmap(0xb5f70000, 16384) = 0 ioctl(28, _IOC(_IOC_WRITE, 0x49, 0xa, 0x4), 0xbef0c238) = 0 close(28) = 0 rt_sigaction(SIGCHLD, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 nanosleep({tv_sec=1, tv_nsec=0}, 0xbef0caa0) = 0 open("/dev/isp_dev", O_RDONLY) = 28 ioctl(28, _IOC(_IOC_WRITE, 0x49, 0, 0x4), 0xbef0c234) = 0 ioctl(28, _IOC(_IOC_WRITE, 0x49, 0xa, 0x4), 0xbef0c238) = 0 ioctl(28, _IOC(_IOC_READ, 0x49, 0x9, 0x4), 0xbef0c23c) = 0 mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0x81621000) = 0xb5f70000 munmap(0xb5f70000, 16384) = 0 ioctl(28, _IOC(_IOC_WRITE, 0x49, 0xa, 0x4), 0xbef0c238) = 0 close(28) = 0 rt_sigaction(SIGCHLD, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0 nanosleep({tv_sec=1, tv_nsec=0}, ^C./strace: Process 923 detached <detached ...>
Initial guess is that rmm is opening the camera device (/dev/isp_dev?), reading a still image (the ioctl and mmap2 commands), closing the camera device and then sleeping for 1 second. I assume it compares the still image with the previous still image to detect motion.
I am not sure how the output of this gets fed into other processes though, as from the strace output, rmm doesn't seem to be writing to any queues. However the dispatch process does receive data from the /ipc_dispatch queue including some of the messages mentioned in my previous post.
xarnze
au-arms
dvv
I've managed to get yi-hack-v3 up and running on a YiHome 720p (the 47US variant) and it's all working nicely. I can access the camera via telnet/ftp and download the MP4 files that are recorded whenever motion is detected.
I also want to be able to "trigger" the recording of an MP4 file at an arbitrary time (maybe on a schedule, or from some other external event that I can wire up via telnet later).
I thought of doing this via the existing processes that are already running on the camera, to keep it as non-invasive as possible, as I still want to use the camera in the "normal" way, to look at live video and play recorded video via the iPhone/android/native apps.
Through examining the running processes via ps, lsof and /proc, and looking at the log file (/tmp/log.txt) I have noticed a few things:
The main processes that run that seem to be of interest are:
mp4record- I assume it does what the name suggests, i.e. records an mp4 file whenever motion is detected. In log.txt it writes messages such as "main stream record finish", which makes sense.dispatch- from the name it sounds like some kind of "controlling" process that triggers tasks for other processes to complete.rmm- maybe motion detection as it writes messages into the log like "got a new motion start" (after which the dispatch process usually writes "g_dispatch_info.mmap_info->motion_type=0"cloud- presumably to do with syncing recording metadata into the cloud? or responding to requests for connections from the mobile/desktop apps?p2p_tnp- not sure about this one but maybe it handles sending data to apps once connected?watch_process- seems to be responsible for ensuring all the other processes are running, and restarting them if any of them die(If anyone has any more info on the above or can make any corrections please do!)
By looking at lsof I can see that these processes are communicating via a number of POSIX mqueue message queues:
However if you check these in /dev/mqueue they seem to be always empty e.g.:
I wondered if these were indeed being used to communicate between processes, so as an experiment I killed the
mp4recordprocess (and then thewatch_processprocess to stop it from restarting it 👍 ).Sure enough, when I waved my hand in front of the camera, the ipc_dispatch queue seemed to start to fill with messages.
I thought it would be interesting to examine the contents of these messages and observe exactly when they were being sent. There are no command line tools to interact with the POSIX message queues, so I wrote a small C program to dump the messages from a particular queue:
This compiles with the Hi3518E V100R001C01SPC0B0 SDK using the command:
arm-hisiv100nptl-linux-gcc dump_mq.c -o dump_mq -lrt -lpthreadAnd then when FTP'd onto the camera, it seems to run fine and dumps out messages from the queue (specified on the command line) onto the console and also into a log file called dump_mq.log. This screws up the camera behaviour as other processes that were expecting to receive messages now don't receive them as they have been grabbed by the dump_mq process. I did experiment (as can be seen in the code) with grabbing the messages and then immediately writing them back onto the same queue again after they've been examined, and then waiting 0.1 seconds to ensure the same message isn't written back straight away, but that has the possibility of "missing" messages as other processes could get there first (which could happen anyway, but sleeping makes it more likely I suppose).
So far I've observed /ipc_rmm seems to get a message whenever there is a motion detection event. This message (hex dumped) comes in at the same time (roughly) as the log entry below:
And then /ipc_dispatch seems to contain pretty regular messages which I think may be heartbeats from processes like mp4record (looking at the log entries that show up at similar times):
This is as far as I've got. I'd like to be able to find out more about what all the processes are doing that cause them to send the messages and confirm my assumptions about what is causing various messages to be sent. I assume I could use
stracefor this but I'm not sure how to cross-compile it (I have the source code in a buildroot project but need to compile it using the Hi3518 SDK, not sure how to do this yet).It would also be great if I had a way to understand what the contents of the messages means. They don't print nicely using printf (hence the empty quotemarks in the pasted messages above) so I've hex dumped them. The /ipc_rmm messages do contain the text '/tmp/motion.jpg' which could be a clue (I converted them using https://www.rapidtables.com/convert/number/hex-to-ascii.html ) but the /ipc_dispatch ones don't seem to contain anything immediately useful.
If I'm going to create "fake" messages to put onto one of the ipc queues to trigger a detected motion, I expect I need another message to also trigger the "end" of the motion, otherwise the mp4 recording will continue forever. I haven't yet observed any message that looks like an example of a 'motion stopped' message.
Hopefully someone can build on the above or suggest some next steps. In the meantime I'll keep playing and post any further updates here.
Finally if anyone has any suggestions for better ways to tackle this, in a nice non-invasive manner, that would be good. I had considered trying to directly capture an image from the sensor (along the lines of this: https://mark4h.blogspot.com/2017/09/hi3518-camera-module-part-3-capturing.html or this https://github.com/mark4h/HI3518-SC1035 or potentially this https://github.com/samtap/fang-hacks/issues/87 ) but I am nervous that because the Yi apps are still running, they would still have the sensor "open" and these other tools would be unable to access it, so I haven't put any effort into trying to get these to compile etc yet.