HOWTO: Compiling Linux 3.1 kernel and uClinux-dist-20110810 for NUC700 platforms

As a note.. I found that an easy alternative to a flash based filesystem for storing user settings, is to just tar those files that needs to be customizable, like rc scripts /etc/passwd etc. directly to /dev/mtdX.

When the camera starts up /dev/mtdX is untar'ed on top of unionfs, and the rc scripts is then executed.

This way I can change IP address, camera parameters, etc. without having to re-flash the device, and at the same time avoiding the overhead a flash based filesystem gives.

For saving the settings I have a script to tar the files back to the flash.

Nice solution! And saving configuration is probably something like "tar c /etc/* > /dev/mtdX"? Did you have to erase the blocks first?

I used the MTD directly from my application, similar to how the original firmware stores its configuration:

Code: [Select]

#define CONFIG_MTD      "/dev/mtd3"

struct cam_config {
        char valid;              /* 0 => run init_config() */
        char version;            /* config version. valid versions: 0 */
        unsigned int ip;         /* 0 = dhcp */
        char cam_name[10];
};


Code: [Select]

        int f = open(CONFIG_MTD, O_RDONLY);
        int ret = read(f, c, sizeof(*c));
        close(f);

However, you need to erase the MTD before writing new data:

Code: [Select]

        struct mtd_info_user mtd_info;
        struct erase_info_user erase_info;

        if(ioctl(f, MEMGETINFO, &mtd_info))
                return -1;

        erase_info.length = mtd_info.erasesize;
        for (erase_info.start = 0;
                erase_info.start < mtd_info.size;
                erase_info.start += mtd_info.erasesize) {

                ioctl(f, MEMUNLOCK, &erase_info);
                if(ioctl(f, MEMERASE, &erase_info))
                        return -1;
        }


Yes you have to erase the flash beforehand, I have a /bin/savesettings script:

Code: [Select]

#!/bin/sh

/bin/flash_erase /dev/mtd3 0 0
/bin/tar -cf /dev/mtdblock3 /etc/resolv.conf /etc/rc.d/* /bin/savesettings /etc/passwd /etc/group /etc/HOSTNAME /etc/camserver.conf

And my init.late:

Code: [Select]

#!/bin/sh

# Restore volatile files from flash
echo Restoring files from flash
/bin/tar -xvf /dev/mtdblock3 -C /

/etc/rc.d/rc.ip
/etc/rc.d/rc.camserver
/etc/rc.d/rc.crap

Only problem with flash_erase is that the partition information is lost so you cant see it in the bootloader, but it works just fine anyway. I have googeled this problem a bit, but haven't found a solution yet.

This also means that when you flash the camera from the bootloader, and the partition isn't visible, you have to upload it, erase it, and then upload it again, to make sure it it properly erased.

And another thing I found, is that you can save ~600k of mem, by running busybox directly from init, instead of running it from init.late:

Code: [Select]

chroot /mnt/union /bin/sh /bin/init.late
chroot /mnt/union /bin/busybox sh
directly in /bin/init works just fine, and saves an instance of /bin/sh and thus the ~600k mem.

were the original git repositories removed?
I tried setting up a new build environment but the urls didnt work.
has this been abandoned?

Hi, I just checked the repositories from my first post, they work fine. Which repos aren't working for you?

ok, somehow magically it works...
none of the git repos were working, so I was assuming that they had been taken down & work on the 3.1 kernel was abandoned...

are you still actively working on this?
about a year ago, i cloned your repos and had a good, working kernel & solid config (no panics, networking was functional). unfortunately, that depo i had was 'destroyed', and that's why I've been forced to start all over.

I recently cloned your repos, but now it seems Im having more problems with kernel panics and trying to get the network up (just ethernet, dont care about wifi yet...).

fyi, a couple of other users & I are looking into getting 'buildroot' to work for our platform, so that we can get a more updated toolkit & kernel built, in case this is of any interest to you...see this post for more info: http://www.openipcam.com/forum/index.php/topic,602.0.html

No I'm not working on this anymore. I've never got the VIA Wifi working, and the signal quality on the Foscam I used was way too bad even with the stock firmware, so this became yet another abandoned spare time project for me ;-)

I did write an HTTP server capable of serving the MJPG stream to multiple HTTP clients at the same time. It has a few experimental features like motion detection and SSL-signing of video frames, but that's still work in progress. If there's interest in it, I can upload the source somewhere.

ok, sorry to hear you've lost hope/interest hehehe...
Im on the verge of doing the same, or perhaps I'll just give up on trying to get the 3.x kernel going, and drop back down to 2.6. Im starting to run into 'low memory', poor performance, & kernel panic issues now that Im actually trying to get the camera to actually do something useful.

Can you please post or upload your http server code?
if u need a place to put it, pm me and I can setup an ftp or dropbox for you to place it in.
I managed to compile & run uvc-streamer, but the performance is rather poor (heavy load on the camera), and more than one connection will crash the app and cause a kernel panic. Again, perhaps this is an issue with the 3.1 kernel and/or the configuration Im running, so maybe it would work on 2.6? anyway, I'd like to try your server and see how it goes...

I didn't really lose hope from a technical point of view, but for sure developing for these devices is not for the faint of heart ;-) You're right it's very tedious and the non-MMU environment is not really forgiving or pleasing at all, but I got the basic functionality working and it was quite stable (I had the HTTP server running without interruption for 24+ hours serving images over Ethernet).

Further, the decoding of a JPEG frame (DC only, i.e., 1/8 width and 1/8 height) is fast enough and a simple motion detection algorithm using a moving average background image is implemented and seems to be working, however I never got around to test that functionality thoroughly.

I uploaded my local branch "ipcamd" of the uClinux repository to Github. This is were I keep the source files of my HTTP server: https://github.com/rhuitl/uClinux/tree/ipcamd/user/ipcamd

Command line options:

Code: [Select]

Options:
-d | --device name   Video device name [/dev/video]
-h | --help          Print this message
-m | --mmap          Use memory mapped buffers
-r | --read          Use read() calls
-u | --userp         Use application allocated buffers
-p | --private       Use private mapping (use with -m)
-c | --count         Number of frames to grab
-w | --width         Set width (640 or 320), height is auto-selected
-j | --decode-jpeg   Decode DC coefficients of JPEG, repeat to save as /tmp/test.pgm
-s | --sign-jpeg     Sign SHA1 hash of JPEG data
-D | --dhcp          Start dhcpcd to handle network setup
-v | --verbose       Be verbose, e.g., print video frames

If it works with your webcam driver, you should use mmap() (-m instead of -r or -u) in order to minimize copying of image data.

Good luck with your project. I'll be happy to hear about your progress or problems you have with ipcamd.

P.S.: on the other thread I read about using XIP. I tried that briefly but quickly abandoned the idea because I had problems getting it to work and it is said to hurt performance a lot. The problem is there's no cache between the flash memory and the CPU, so each instruction needs to be fetched from flash, which is a lot slower than RAM.

ok thanks for the info on setting up an XIP kernel, and I now realize that its not feasible.

I compiled the ipcamd code, and ran it on my 3.1 kernel.
Aside from a couple of changes that I needed to make to the code in order to get it to run, it seems to work fine. However, Im consistently seeing a frame drop rate of '2 frames per capture'

Code: [Select]

mainloop
Frame dropped (jumping from 20 to 22) for client 0x003ff004
Frame dropped (jumping from 30 to 32) for client 0x003ff004
Frame dropped (jumping from 34 to 36) for client 0x003ff004
Frame dropped (jumping from 40 to 42) for client 0x003ff004
Frame dropped (jumping from 42 to 44) for client 0x003ff004
Frame dropped (jumping from 45 to 47) for client 0x003ff004
Frame dropped (jumping from 47 to 49) for client 0x003ff004
Frame dropped (jumping from 52 to 54) for client 0x003ff004
Frame dropped (jumping from 60 to 62) for client 0x003ff004
Frame dropped (jumping from 62 to 64) for client 0x003ff004
Frame dropped (jumping from 67 to 69) for client 0x003ff004
Frame dropped (jumping from 69 to 71) for client 0x003ff004
Frame dropped (jumping from 74 to 76) for client 0x003ff004
Frame dropped (jumping from 76 to 78) for client 0x003ff004
Frame dropped (jumping from 82 to 84) for client 0x003ff004
Frame dropped (jumping from 85 to 87) for client 0x003ff004
Frame dropped (jumping from 87 to 89) for client 0x003ff004
Frame dropped (jumping from 89 to 91) for client 0x003ff004
FPS: 23.2
Frame dropped (jumping from 94 to 96) for client 0x003ff004
Frame dropped (jumping from 96 to 98) for client 0x003ff004
Frame dropped (jumping from 100 to 102) for client 0x003ff004
Frame dropped (jumping from 102 to 104) for client 0x003ff004

any idea why this is happening or how it can be fixed?
FYI, Im running my kernel with a HZ setting of '1000', in order to be able to run the stepper motors at full speed. I dont know if this could possibly affect the frame capture and/or frame processing routines. Also, I noticed that when I tried running the kernel with a HZ value of '2000' I got higher frame rates, @ around 30 fps.

- a couple of changes that I needed to make to the code:

1) my foscam clone has the onboard MJPG encoder, so the code that tries to set the format to

Code: [Select]

V4L2_PIX_FMT_JPEG needed to be changed to

Code: [Select]

V4L2_PIX_FMT_MJPEG in order for the capture to succeed, otherwise Id get an 'invalid argument' error message.
2) I needed to disable the 'enumerate_controls' routine because it was erroring out trying to read the JPEG quality value (I assume that this attribute doesnt apply to MJPEG V4L2 streams?)

3) the ipcamd code doesnt seem to provide a method to do 'continuous capturing'; you must specify a fixed number of frames to capture (I didnt really understand your intention here, how would a streaming server be setup using this method?). So, I modified the 'mainloop' routine in order to be able to run an infinite capture loop:

Code: [Select]

static void mainloop(void)
{
int fps_counter = 0;
struct timeval begin;
gettimeofday(&begin, NULL);

while ((count == -1 || count-- >= 0) && !restart_cam) {
for (;;) {
so, by passing a value of '-1' for the 'count' argument, the capture loop will run infinitely and continue to capture frames. Perhaps this is not the most elegant method, but it seems to work.

However, Im consistently seeing a frame drop rate of '2 frames per capture'

Code: [Select]

mainloop
Frame dropped (jumping from 20 to 22) for client 0x003ff004
Frame dropped (jumping from 30 to 32) for client 0x003ff004

any idea why this is happening or how it can be fixed?

Sending video frames doesn't keep up with the frame rate of the V4L device. What happens is that your client is being sent frame 20, then by the time this has completed the most recent frame available is 22, so frame 21 is dropped (http_frame_reader() always sends the most recent frame to a client, otherwise low-bandwidth links would result in ever-growing delays). You could try inreasing BUFFER_COUNT in config.h, but I doubt this is going to make a difference. What HTTP client do you use, and what kind of network connection? If you need to avoid frame drops at all costs, check http_frame_reader() and make it send out not the most recent buffer, but the buffer with the lowest frame id still larger than the previous frame's id.

FYI, Im running my kernel with a HZ setting of '1000', in order to be able to run the stepper motors at full speed. I dont know if this could possibly affect the frame capture and/or frame processing routines. Also, I noticed that when I tried running the kernel with a HZ value of '2000' I got higher frame rates, @ around 30 fps.

Interesting find, but I don't see how this could cause the frame drops. Are you running other processes in parallel? Do you still see the drops when ipcamd is the only process running?

1) my foscam clone has the onboard MJPG encoder, so the code that tries to set the format to

Code: [Select]

V4L2_PIX_FMT_JPEG needed to be changed to

Code: [Select]

V4L2_PIX_FMT_MJPEG in order for the capture to succeed, otherwise Id get an 'invalid argument' error message.
2) I needed to disable the 'enumerate_controls' routine because it was erroring out trying to read the JPEG quality value (I assume that this attribute doesnt apply to MJPEG V4L2 streams?)

MJPEG certainly has a quality setting as well, but it might not be easy to change it. I'm not sure if setting jpeg quality worked with my Foscam and the GSPCA driver.

3) the ipcamd code doesnt seem to provide a method to do 'continuous capturing'; you must specify a fixed number of frames to capture (I didnt really understand your intention here, how would a streaming server be setup using this method?). So, I modified the 'mainloop' routine in order to be able to run an infinite capture loop:

Yeah, that's right, the setting is a left-over from the early days. The intention was to avoid reboots during development. As Ctrl+C didn't work, I needed a way to quit the program and download the new binary afer recompilation (thus the dlipcamd script). Your patch is fine, just default the -c parameter to -1 and it will run forever :-)

I ran through the instructions here and installed the kernel on my FI8910W.  I am getting the following kernel oops when I connect a client to the telnet server running on the camera.  Can anyone point me in the direction I should be looking to see what is going on here?

# Bad mode in prefetch abort handler detected
Internal error: Oops - bad mode: 0 [#1]
CPU: 0    Not tainted  (3.1.0-rc9-on+ #2)
PC is at 0xc
LR is at 0x7374702e
pc : [<0000000c>]    lr : [<7374702e>]    psr: 20000097
sp : 00ff7fb0  ip : 00fdd800  fp : 00fdda54
r10: 00fded24  r9 : 00fdeca4  r8 : 00fdc984
r7 : 00fdda50  r6 : 00fdda44  r5 : 00000000  r4 : 00000001
r3 : 7374702f  r2 : 00fdcc20  r1 : 00fd6900  r0 : 00000001
Flags: nzCv  IRQs off  FIQs on  Mode ABT_32  ISA ARM  Segment kernel
Process telnetd (pid: 44, stack limit = 0x00ff6270)
Stack: (0x00ff7fb0 to 0x00ff8000)
7fa0:                                     00000001 00fd6900 00fdcc20 7374702f
7fc0: 00000001 00000000 00fdda44 00fdda50 00fdc984 00fdeca4 00fded24 00fdda54
7fe0: 00fdd800 00ff7fb0 7374702e 0000000c 20000097 ffffffff 00000100 00000000
Backtrace: frame pointer underflow
[<fffffff0>] (0xfffffff0) from [<00000000>] (  (null))
Backtrace aborted due to bad frame pointer <00fdd904>
Code: 00000000 ef9f0000 ea0000dd e59ff410 (ea0000bb)
---[ end trace bc7310895415bf9d ]---

I followed the instructions, and got kernel compiling, however I cannot make the thing boot. My camera is FI8910W, and when I boot I'm getting nothing on the console:

Code: [Select]

W90P745 Boot Loader [ Version 1.1 $Revision: 1 $ ] Rebuilt on May 11 2010
Memory Size is 0x1000000 Bytes, Flash Size is 0x400000 Bytes
Board designed by Winbond
Hardware support provided at Winbond
Copyright (c) Winbond Limited 2001 - 2006. All rights reserved.
Boot Loader Configuration:

MAC Address         : 00:0D:C5:DB:46:96
IP Address          : 0.0.0.0
DHCP Client         : Enabled
CACHE               : Enabled
BL buffer base      : 0x00300000
BL buffer size      : 0x00100000
Baud Rate           : -1
USB Interface       : Disabled
Serial Number       : 0xFFFFFFFF


For help on the available commands type 'h'

Press ESC to enter debug mode ......
Cache enabled!
Processing image 1 ...
Executing image 1 ...
... and here it hangs.

I use following commands to write partitions:

Code: [Select]

fx 1 linux 0x7f020000 0x8000 -acx
fx 2 romfs 0x7F140000 0x7F140000 -a
After flashing, my partition table looks like this:

Code: [Select]

Press ESC to enter debug mode .....

bootloader > ls
Image: 0 name:BOOT INFO base:0x7F010000 size:0x00000038 exec:0x7F010000 -af
Image: 1 name:linux base:0x7F020000 size:0x00107900 exec:0x00008000 -acx
Image: 2 name:romfs base:0x7F140000 size:0x00135900 exec:0x7F140000 -a
My kernel and romfs are coming from:

Code: [Select]

        /usr/local/src/uClinux-dist-nuc700/linux-3.1/arch/arm/boot/zImage
        /usr/local/src/uClinux-dist-nuc700/romfs.img > romfs.img
Can anyone tell me what am I doing wrong?