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

Instructions for building uClinux (20110810) and Linux Kernel 3.1 for NUC7xx.

Preface

This document explains how to setup a build environment to compile the latest (as of 10/28/2011) uClinux for the NUC700 platform. I imported the contents of the uClinux-dist-20110810 archive as the first commit in my GIT repository, and applied patches on top of that. Rebasing onto newer uClinux releases will be very easy this way, and it helps keep track of the changes between the mainline uClinux and the NUC700 specific stuff.

I ported Wan ZongShun's Linux kernel patches (http://nuc700.sourceforge.net/) to the current kernel 3.1-rc9. As my nuc700 branch is branched from Linus Torvalds' kernel branch, we can merge in upstream changes into the nuc700 branch by running "git merge master" or "git rebase master".


Toolchains

Picking the correct toolchain(s) is tricky and you can spend a lot of time running into all sorts of weird compilation and linking problems. Then, on the device, you might end up with executables that either don't load at all or crash instantly or when they execute a particular function call.

I experimented with the following toolchains:

1. arm-uclinux-tools-base-gcc3.4.0-20040713
2. arm-linux-tools-20080623
3. arm-linux-tools-20061213
4. arm-2011.03 (Code Sourcery)

2004 toolchain (gcc 3.4.0) for userland and 2008 toolchain (gcc 4.2.4) for kernel:
Problems with userland: something wrong with dropbear (don't remember the details).

2006 toolchain (gcc 3.4.4) for userland and 2008 toolchain (gcc 4.2.4) for kernel:
Problems with userland: had to patch elf2flt.c to get rid of these errors:

Code: [Select]

ERROR: reloc type R_ARM_PC24 unsupported in this context
However, "long long" seems to produce code that makes executables go from "ram" (good) to "gotpic" (bad).

2011 toolchain (gcc 4.5.2) for both userland and kernel:
The kernel hangs on "Uncompressing Linux", never printing "done, booting the kernel".

2011 toolchain (gcc 4.5.2) for userland and 2008 toolchain (gcc 4.2.4) for kernel:
This combination works great and is what I am using and recommend.

So the bottom line is that you need two toolchains, one for the kernel, one for the userland. Download and unpack these two archives:

1. "Sourcery G++ Lite 2011.03-46 for ARM uClinux" from https://sourcery.mentor.com/sgpp/lite/arm/portal/release1804 (direct link: https://sourcery.mentor.com/sgpp/lite/arm/portal/package8744/public/arm-uclinuxeabi/arm-2011.03-46-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2)
2. http://ftp.snapgear.org/pub/snapgear/tools/arm-linux/arm-linux-tools-20080623.tar.gz


Environment

In order to use the Code Sourcery toolchain for the userland and the arm-linux-tools-2008 toolchain for the kernel, you have to place the appropriate directories in your PATH variable:
 

Code: [Select]

$ export PATH="/path/to/arm-2011.03/bin:/path/to/arm-linux-tools-20080623/usr/local/bin:$PATH"
  Check that the toolchains are installed properly by running:
 

Code: [Select]

$ arm-linux-gcc -v
(...)
gcc version 4.2.4

$ arm-uclinuxeabi-gcc -v
(...)
gcc version 4.5.2 (Sourcery G++ Lite 2011.03-46)

Install dependencies

libssl needs makedepend, which you can find in xutils-dev.

Further, you need genromfs so the build system can create a romfs.img file which can be flashed, and some other tools:

Code: [Select]

$ sudo apt-get install xutils-dev genromfs libtool texinfo

Clone the uClinux distribution at git://github.com/rhuitl/uClinux.git

Code: [Select]

$ git clone git://github.com/rhuitl/uClinux.git uClinux-dist-nuc700
$ git submodule init
This repository is based on uClinux-dist-20110810 (or newer versions in the future) and has a few nuc700-specific patches. Further, the folders linux-2.0.x, linux-2.4.x and linux-3.x have been removed to save ~780 MiB space.

We will use our own kernel which is based on Linus Torvalds' kernel branch (3.1-rc9 at the moment), with a lot of patches by Wan ZongShun and a few of my own.

The 3.0.0 kernel that ships with uClinux has a lot of patches applied, but at first glance, none of them seem relevant for the nuc700 platform. Might be interesting to add their patchset to our kernel, too.

Git's submodule feature is used for libraries and programs I added. They allow pulling in upstream changes in these projects without losing our own patches, e.g., for no-MMU compatibility and static linking.


Clone the kernel tree at git://github.com/rhuitl/linux.git

Code: [Select]

$ cd uClinux-dist-nuc700
$ git clone git://github.com/rhuitl/linux.git linux-3-nuc700

Checkout my nuc700 branch

Code: [Select]

$ git checkout nuc700

Create a symlink to fulfill the uClinux build system's expectations

Code: [Select]

$ ln -s linux-3-nuc700 linux-3.1

Configure uClinux (don't enter the kernel directory)

Code: [Select]

$ make menuconfig
Select "Customize Application/Library Settings", then exit and save. In the following menu, you can just exit and save again.

WARNING:

Don't enable lots of applications at once. Try to get a successful build using a minimum set of applications first, and once that works, select one more application and rebuild. This way it is easy to spot applications that don't build on our platform, and unfortunately, due to static linking and the lack of a MMU, there are a lot of programs in the uClinux distribution that don't build out of the box.

Code: [Select]

$ make
You might need to run make a second time if the romfs directory didn't exist before and it complains about missing targets for romfs.img (needs fixing).

Don't do parallel makes (e.g., make -j4), the uClinux build system is broken in this regard and will mess up the order how packages are compiled. Parallel builds of the kernel work fine, of course.

Finally, the build process should complete with these lines:

Code: [Select]

genromfs -f romfs.img -d romfs
The ROMFS image romfs.img is ready
The kernel zImage is at linux-3.1/arch/arm/boot/zImage, the romfs image at ./romfs.img.


Final remarks

Note: I am using a FOSCAM FI8904W, so you may need to make modifications as appropriate
 for your device.

Note: The Wifi driver (Via vt6656, in the staging area) does not work. I've spent some days debugging it, but I never got lucky. At least the kernel panics I used to get in response to "ifconfig eth1 up" are gone with the upgrade from 2.6.38 to 3.1. There have been some no-MMU related patches, so maybe one of them cured the kernel panic that I suspect was because of a corruption of the kernel's timer list.

Now, I get this error message:

Code: [Select]

# ifconfig eth1 up
Config_FileOperation file Not exist
kernel BUG at mm/nommu.c:415!
So far I couldn't track down who called vunmap() and why, guess I need to print a backtrace.
Note that the Config_FileOperation message is unrelated to the problem.

Made into a sticky.

Good post robert!
Mind if I import the git repo to here?

Thanks, no I don't mind, please go ahead and use it for the repository here.

A few more comments. The current kernel .config mounts the root filesystem as a ROMFS, i.e., a read-only filesystem that you need to flash to the device. I have some scripts that automate the communication with the bootloader to do this, I can post them if interested. The partition to use for the ROMFS is specified like this:

Code: [Select]

CONFIG_CMDLINE="console=ttyS0,115200n8 rdinit=/bin/init mem=16M root=1f02"
Where 1f is the device number of a mtd device (/dev/mtdX) in hexadecimal, and 02 makes it /dev/mtd2. My partition layout is setup like this, so mtd2 is the ROMFS partition.

Code: [Select]

Image: 0 name:BOOT INFO base:0x7F010000 size:0x00000048 exec:0x7F010000 -f
Image: 1 name:linux base:0x7F020000 size:0x001105B0 exec:0x00008000 -acx
Image: 2 name:romfs base:0x7F140000 size:0x0026FC00 exec:0x7F140000 -a

The problem with having a ROMFS as root filesystem is that it is readonly. As I packed /dev into the ROMFS, an application cannot use device nodes in a read-write way, even if the device node's permissions are read-write. Turns out that a lot of libc functions rely on using device nodes in a read-write manner, for example mmap() on a Video4Linux device fails if the device nodes are on a read-only filesystem.

This is why I mount a tmpfs filesystem at /tmp, copy all device nodes into this directory, and then mount it on top of /dev. I consider this a hack, and I'm still looking into a better way to have a ROMFS and an overlay on top of that in RAM, maybe overlayfs or something like that.

For developing purposes, it is convenient to boot both the kernel and the userland from RAM (e.g., mt or mx in the bootloader). This can be achieved by changing the .config file like this:

Code: [Select]

diff --git a/.config b/.config
index ab0b048..e709b0f 100644
--- a/.config
+++ b/.config
@@ -74,7 +74,17 @@ CONFIG_PID_NS=y
 CONFIG_NET_NS=y
 # CONFIG_SCHED_AUTOGROUP is not set
 # CONFIG_RELAY is not set
-# CONFIG_BLK_DEV_INITRD is not set
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE="/path/to/uClinux-dist-nuc700/romfs"
+CONFIG_INITRAMFS_ROOT_UID=1000
+CONFIG_INITRAMFS_ROOT_GID=1000
+CONFIG_RD_GZIP=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_INITRAMFS_COMPRESSION_NONE is not set
+CONFIG_INITRAMFS_COMPRESSION_GZIP=y
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
 CONFIG_EXPERT=y
 CONFIG_EMBEDDED=y
@@ -308,7 +318,7 @@ CONFIG_FORCE_MAX_ZONEORDER=11
 #
 CONFIG_ZBOOT_ROM_TEXT=0
 CONFIG_ZBOOT_ROM_BSS=0
-CONFIG_CMDLINE="console=ttyS0,115200n8 rdinit=/bin/init mem=16M root=1f02"
+CONFIG_CMDLINE="console=ttyS0,115200n8 rdinit=/bin/init mem=16M"
 CONFIG_CMDLINE_FROM_BOOTLOADER=y
 # CONFIG_CMDLINE_EXTEND is not set
 # CONFIG_CMDLINE_FORCE is not set
 # CONFIG_XIP_KERNEL is not set
 # CONFIG_KEXEC is not set
@@ -1298,6 +1308,7 @@ CONFIG_GENERIC_FIND_LAST_BIT=y
 CONFIG_ZLIB_INFLATE=y
 # CONFIG_XZ_DEC is not set
 # CONFIG_XZ_DEC_BCJ is not set
+CONFIG_DECOMPRESS_GZIP=y
 CONFIG_HAS_IOMEM=y
 CONFIG_HAS_IOPORT=y
 CONFIG_HAS_DMA=y

This way, the root filesystem is compiled into the kernel as a so-called INITRAMFS (not to be confused with an INITRD). This filesystem happens to be read-write, so the problems with /dev on a read-only filesystem don't exist in this case. The traditional uClinux build order (compile kernel, then userland) does not suffice, as the userland must already have been built before the kernel is compiled. This is why there's a patch for the Makefile that invokes the kernel build a second time (build kernel -> uClinux -> kernel).

You may want to look at using a ramfs -  e.g.

http://www.openipcam.com/forum/index.php?topic=162.0

and take a look at the notes on what I've been working on  layout wise.

http://wiki.openipcam.com/index.php/Memory_Layout_considerations_and_Hardware_Requirements

And finally some of my modifications to the kernel and the userland:

Kernel

• Switches the second USB host controller on the nuc700 to host-mode (it defaults to gadget mode). This is why the USB Wifi module didn't show up before.
• Add support for mmap() on no-MMU systems to the GSPCA drivers (e.g. the zc3xx for the FI8904W)

Userland

• Allow programs to link to libssl. See https://github.com/rhuitl/uClinux/commit/bb66bc8e01c5ee7ebb6e7610b35b610e328b0e67.
• Add latest dropbear version (SSH server)
• Add latest hostap version for wpa_supplicant
• Add libmicrohttpd and "long long" patch
• Fix bad relocs in wireless_tools
• Various fork() -> vfork() and dynamic -> static linking patches

For a complete list of changes, see https://github.com/rhuitl/linux/commits/nuc700 and https://github.com/rhuitl/uClinux/commits/master.

You may want to look at using a ramfs -  e.g.

http://www.openipcam.com/forum/index.php?topic=162.0

Are you flashing this RAMFS to the flash partition? When you mount it, it has to be copied to RAM completely. I wonder if applications started from that RAM filesystem are copied a second time (again to RAM) by the BFLT loader. That would probably waste some precious RAM. I'd rather have the files stored on flash and loaded into RAM on demand. Nevertheless thanks for the hint, I will read up more on ramfs & co later.

and take a look at the notes on what I've been working on  layout wise.

That layout is fine if you're trying to build something similar to the original firmware. For my experiments, I needed all the space I could get for the userland, this is why I didn't adopt your layout in the first place:

Code: [Select]

536K bin/wpa_supplicant
4,0K bin/init
48K bin/inetd
336K bin/dropbear
84K bin/iwspy
96K bin/iwconfig
76K bin/dhcpcd
292K bin/busybox
760K bin/crypttest
88K bin/iwgetid
104K bin/iwlist
84K bin/iwpriv

That sums up to around 2.6 M already. But I guess if you drop dropbear, wireless_tools and inetd, and don't include heavy dependencies like libssl in your camera binary, 1 M could suffice.

I fixed the Wifi problem, but unfortunately, the kernel panic came back

The first problem is that if the firmware loader could not find the requested firmware, it ended up calling vunmap(NULL). The second problem I fixed was that the VIA firmware file vntwusb.fw wasn't included in the kernel (CONFIG_EXTRA_FIRMWARE="vntwusb.fw" was missing). Now the vt6656 driver can load the firmware, but crashes just like it did on 2.6.38 *sigh*

I pushed the fixes for the firmware trouble to my github repo. The vntwusb.fw file needs to be downloaded manually, though:

Code: [Select]

wget http://anonscm.debian.org/viewvc/kernel/dists/trunk/firmware-nonfree/linux-nonfree/vntwusb.fw?view=co -O firmware/vntwusb.fw
I was debugging this kernel panic before, it crashes in run_timer_softirq when it removes a bogus element from the kernel's timer list. This element has probably been overwritten somewhere else, which makes it really tough to debug... 

Code: [Select]

Linux version 3.1.0-rc9-on+ (robert@LinuX42) (gcc version 4.2.4) #25 Sun Oct 30 23:08:32 CET 2011
CPU: Nuvoton-nuc700 [41807000] revision 0 (ARMv4T), cr=00000000
CPU: VIVT data cache, VIVT instruction cache
Machine: NUC745EVB
CPU type 0x00000745 is NUC745
The GPIO_CFG2 is 0x55555,  not equal to 0x0, maybe using by boot!
The GPIO_CFG4 is 0x55555,  not equal to 0x155555, maybe using by boot!
The GPIO_CFG5 is 0x15555555,  not equal to 0x0, maybe using by boot!
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4064
Kernel command line: console=ttyS0,115200n8 rdinit=/bin/init mem=16M
PID hash table entries: 64 (order: -4, 256 bytes)
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 16MB = 16MB total
Memory: 12500k/12500k available, 3884k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0x00000000 - 0x00001000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0x00000000 - 0xffffffff   (4095 MB)
    lowmem  : 0x00000000 - 0x01000000   (  16 MB)
    modules : 0x00000000 - 0x00f00000   (  15 MB)
      .text : 0x00008000 - 0x0020c000   (2064 kB)
      .init : 0x0020c000 - 0x0036a000   (1400 kB)
      .data : 0x0036a000 - 0x0037ca20   (  75 kB)
       .bss : 0x0037ca44 - 0x003a3bac   ( 157 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:31
Console: colour dummy device 80x30
Calibrating delay loop... 39.32 BogoMIPS (lpj=196608)
pid_max: default: 4096 minimum: 301
Mount-cache hash table entries: 512
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP reno registered
NET: Registered protocol family 1
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 24
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xfff80000 (irq = 9) is a 16550
console [ttyS0] enabled
physmap platform flash device: 00400000 at 7f000000
Using physmap partition information
Creating 3 MTD partitions on "physmap-flash":
0x000000010000-0x000000020000 : "BOOT_INFO"
0x000000020000-0x000000140000 : "linux (1152 KiB)"
0x000000140000-0x000000400000 : "romfs (2.75 MiB)"
uclinux[mtd]: RAM probe address=0xf00000 size=0x1000
Creating 1 MTD partitions on "RAM":
0x000000000000-0x000000001000 : "ROMfs"
Generic platform RAM MTD, (c) 2004 Simtec Electronics
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
nuc700-ohci nuc700-ohci: NUC700 OHCI
nuc700-ohci nuc700-ohci: new USB bus registered, assigned bus number 1
nuc700-ohci nuc700-ohci: irq 15, io mem 0xfff05000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: NUC700 OHCI
usb usb1: Manufacturer: Linux 3.1.0-rc9-on+ ohci_hcd
usb usb1: SerialNumber: ohci_hcd
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Linux video capture interface: v2.00
gspca: v2.13.0 registered
usbcore: registered new interface driver zc3xx
VIA Networking Wireless LAN USB Driver 1.19_12
usbcore: registered new interface driver vt6656
TCP cubic registered
Freeing init memory: 1400K
usb 1-1: new full speed USB device number 2 using nuc700-ohci
usb 1-1: New USB device found, idVendor=0ac8, idProduct=303b
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1: Product: PC Camera
usb 1-1: Manufacturer: Vimicro Corp.
/proc/sys/vm/min_free_kbytes: cannot create
nuc700-emc nuc700-emc: eth0 is OPENED


BusyBox v1.10.2-uc0 (2011-10-30 22:04:12 CET) built-in shell (msh)
Enter 'help' for a list of built-in commands.

# input: zc3xx as /devices/platform/nuc700-ohci/usb1/1-1/input/input0
usb 1-2: new full speed USB device number 3 using nuc700-ohci
usb 1-2: New USB device found, idVendor=160a, idProduct=3184
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-2: Product: VNT USB-802.11 Wireless LAN Adapter
usb 1-2: Manufacturer: VIA Networking Technologies, Inc.
VIA Networking Wireless LAN USB Driver Ver. 1.19_12
Copyright (c) 2004 VIA Networking Technologies, Inc.
usb 1-2: reset full speed USB device number 3 using nuc700-ohci
nuc700-emc nuc700-emc: eth0: Link now 100-FullDuplex

# ifconfig eth1 up
Read Zonetype file success,use default zonetype setting[02]
Zone=[2][E][U]!!
Unhandled fault: vector exception (0x800) at 0x00000000
Internal error: : 800 [#1]
CPU: 0    Not tainted  (3.1.0-rc9-on+ #25)
PC is at run_timer_softirq+0x15c/0x27c
LR is at run_timer_softirq+0x1c/0x27c
pc : [<0001c424>]    lr : [<0001c2e4>]    psr: 80000093
sp : 0095fd30  ip : 0095fd30  fp : 0095fd84
r10: 0000009c  r9 : 0012ee40  r8 : 0095e000
r7 : 0039d700  r6 : 95fd5000  r5 : 95fd5000  r4 : 008e213f
r3 : 0039d7d0  r2 : 0095fd50  r1 : 008e213f  r0 : 0039d7dc
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Process ifconfig (pid: 40, stack limit = 0x0095e270)
Stack: (0x0095fd30 to 0x00960000)
fd20:                                     0095fd8c 00000004 008e0340 0095fd50
fd40: 0039da8c 0039da0c 0039d98c 0039d90c 008e213f 008e213f 00000001 00000001
fd60: 00000101 0095e000 00000004 00000021 0039d604 0000000a 0095fdbc 0095fd88
fd80: 0001902c 0001c2d8 00000000 ffffffff ffffffff 60000013 008e0044 001cacc4
fda0: 00001002 00dbfa0c 00000000 008e0000 0095fdd4 0095fdc0 00019108 00018fc0
fdc0: 0095fdec 008e0000 0095fdec 0095fdd8 00019724 000190d0 008e0044 008e0000
fde0: 0095fe04 0095fdf0 001578f8 000196a8 00000000 008e0000 0095fe24 0095fe08
fe00: 001598d8 001578e4 001578f8 00000041 008e0000 00001043 0095fe44 0095fe28
fe20: 00157a9c 001597f0 008e0000 00001002 0095fe80 00dbfa00 0095fe64 0095fe48
fe40: 00159124 00157a14 0095fe64 00000001 00000000 0095fe80 0095fecc 0095fe68
fe60: 0019bf88 00159118 00a4bec0 00008914 31687465 00000000 00000000 00000000
fe80: 01001043 1a131100 170f1200 00000016 01001043 1a131100 170f1200 00000016
fea0: 170f1200 00000003 00008914 00a4bec0 003a20fc 00008de4 0095e000 00a4bec0
fec0: 0095fedc 0095fed0 0019cca0 0019bd1c 0095fefc 0095fee0 0014a480 0019cbec
fee0: 00000003 00ff8a00 00008914 00ff8a00 0095ff0c 0095ff00 0005e574 0014a2d4
ff00: 0095ff7c 0095ff10 0005ea90 0005e558 00c3cb40 0095ff2c 0095ff64 0095ff28
ff20: 001495b8 00052938 0095e000 00000000 00000000 001fa8c0 00c07600 00cbb500
ff40: 00000000 00000002 0000000c 00000119 00008de4 00000003 00a4bec0 00008914
ff60: 00ff8a00 00008de4 0095e000 00000000 0095ffa4 0095ff80 0005eb2c 0005e670
ff80: 00149e54 00000000 00a42213 00a4bf7c 00a421b4 00000036 00000000 0095ffa8
ffa0: 00008c60 0005eafc 00a42213 00a4bf7c 00000003 00008914 00a4bec0 00a4be9c
ffc0: 00a42213 00a4bf7c 00a421b4 00000036 00a49e60 00000000 00000000 00000000
ffe0: 00000000 00a4be80 00a21514 00a03a28 20000010 00000003 00000000 00000000
Backtrace:
[<0001c2c8>] (run_timer_softirq+0x0/0x27c) from [<0001902c>] (__do_softirq+0x7c/0x110)
[<00018fb0>] (__do_softirq+0x0/0x110) from [<00019108>] (do_softirq+0x48/0x54)
[<000190c0>] (do_softirq+0x0/0x54) from [<00019724>] (local_bh_enable+0x8c/0xb0)
 r4:008e0000
[<00019698>] (local_bh_enable+0x0/0xb0) from [<001578f8>] (dev_set_rx_mode+0x24/0x28)
 r4:008e0000
[<001578d4>] (dev_set_rx_mode+0x0/0x28) from [<001598d8>] (__dev_open+0xf8/0x114)
 r4:008e0000
[<001597e0>] (__dev_open+0x0/0x114) from [<00157a9c>] (__dev_change_flags+0x98/0x120)
 r6:00001043 r5:008e0000 r4:00000041
[<00157a04>] (__dev_change_flags+0x0/0x120) from [<00159124>] (dev_change_flags+0x1c/0x4c)
 r7:00dbfa00 r6:0095fe80 r5:00001002 r4:008e0000
[<00159108>] (dev_change_flags+0x0/0x4c) from [<0019bf88>] (devinet_ioctl+0x27c/0x674)
 r6:0095fe80 r5:00000000 r4:00000001
[<0019bd0c>] (devinet_ioctl+0x0/0x674) from [<0019cca0>] (inet_ioctl+0xc4/0xf4)
[<0019cbdc>] (inet_ioctl+0x0/0xf4) from [<0014a480>] (sock_ioctl+0x1bc/0x20c)
[<0014a2c4>] (sock_ioctl+0x0/0x20c) from [<0005e574>] (vfs_ioctl+0x2c/0x48)
 r7:00ff8a00 r6:00008914 r5:00ff8a00 r4:00000003
[<0005e548>] (vfs_ioctl+0x0/0x48) from [<0005ea90>] (do_vfs_ioctl+0x430/0x48c)
[<0005e660>] (do_vfs_ioctl+0x0/0x48c) from [<0005eb2c>] (sys_ioctl+0x40/0x60)
[<0005eaec>] (sys_ioctl+0x0/0x60) from [<00008c60>] (ret_fast_syscall+0x0/0x2c)
 r7:00000036 r6:00a421b4 r5:00a4bf7c r4:00a42213
Code: e59f0104 ebffe324 ea000004 e3560103 (95865004)
---[ end trace ac1007ef7c17d836 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Backtrace:
[<0000befc>] (dump_backtrace+0x0/0x108) from [<0000c390>] (dump_stack+0x18/0x1c)
 r6:0095fbe7 r5:00000000 r4:00000001
[<0000c378>] (dump_stack+0x0/0x1c) from [<00013f38>] (panic+0x5c/0x1a8)
[<00013edc>] (panic+0x0/0x1a8) from [<0000c1e8>] (die+0x1e4/0x234)
 r3:00000100 r2:001fa8c0 r1:00000000 r0:001f63f8
[<0000c004>] (die+0x0/0x234) from [<0000c300>] (arm_notify_die+0x58/0x5c)
[<0000c2a8>] (arm_notify_die+0x0/0x5c) from [<000082cc>] (do_DataAbort+0x90/0xa4)
[<0000823c>] (do_DataAbort+0x0/0xa4) from [<0000892c>] (__dabt_svc+0x2c/0x40)
Exception stack(0x0095fce8 to 0x0095fd30)
fce0:                   0039d7dc 008e213f 0095fd50 0039d7d0 008e213f 95fd5000
fd00: 95fd5000 0039d700 0095e000 0012ee40 0000009c 0095fd84 0095fd30 0095fd30
fd20: 0001c2e4 0001c424 80000093 ffffffff
 r8:95865004 r7:05000000 r6:ffffffff r5:80000093 r4:0001c424
[<0001c2c8>] (run_timer_softirq+0x0/0x27c) from [<0001902c>] (__do_softirq+0x7c/0x110)
[<00018fb0>] (__do_softirq+0x0/0x110) from [<00019108>] (do_softirq+0x48/0x54)
[<000190c0>] (do_softirq+0x0/0x54) from [<00019724>] (local_bh_enable+0x8c/0xb0)
 r4:008e0000
[<00019698>] (local_bh_enable+0x0/0xb0) from [<001578f8>] (dev_set_rx_mode+0x24/0x28)
 r4:008e0000
[<001578d4>] (dev_set_rx_mode+0x0/0x28) from [<001598d8>] (__dev_open+0xf8/0x114)
 r4:008e0000
[<001597e0>] (__dev_open+0x0/0x114) from [<00157a9c>] (__dev_change_flags+0x98/0x120)
 r6:00001043 r5:008e0000 r4:00000041
[<00157a04>] (__dev_change_flags+0x0/0x120) from [<00159124>] (dev_change_flags+0x1c/0x4c)
 r7:00dbfa00 r6:0095fe80 r5:00001002 r4:008e0000
[<00159108>] (dev_change_flags+0x0/0x4c) from [<0019bf88>] (devinet_ioctl+0x27c/0x674)
 r6:0095fe80 r5:00000000 r4:00000001
[<0019bd0c>] (devinet_ioctl+0x0/0x674) from [<0019cca0>] (inet_ioctl+0xc4/0xf4)
[<0019cbdc>] (inet_ioctl+0x0/0xf4) from [<0014a480>] (sock_ioctl+0x1bc/0x20c)
[<0014a2c4>] (sock_ioctl+0x0/0x20c) from [<0005e574>] (vfs_ioctl+0x2c/0x48)
 r7:00ff8a00 r6:00008914 r5:00ff8a00 r4:00000003
[<0005e548>] (vfs_ioctl+0x0/0x48) from [<0005ea90>] (do_vfs_ioctl+0x430/0x48c)
[<0005e660>] (do_vfs_ioctl+0x0/0x48c) from [<0005eb2c>] (sys_ioctl+0x40/0x60)
[<0005eaec>] (sys_ioctl+0x0/0x60) from [<00008c60>] (ret_fast_syscall+0x0/0x2c)
 r7:00000036 r6:00a421b4 r5:00a4bf7c r4:00a42213


Why don't you just try compiling your own kernel module instead of using a binary module?

eg
http://cse.yeditepe.edu.tr/~sgoren/spring2011/CSE326/lab4_new.pdf

I didn't have issues compiling up for my kernels.. (I think I might have documented it in the uclinux section of the forum).

Why don't you just try compiling your own kernel module instead of using a binary module?

I do compile the vt6656 driver myself, its located in drivers/staging/vt6656. However, I decided to compile it into the kernel and disable loadable module support altogether. I will probably try loading it as a module, but I don't think that will change anything.

No matter how you compile the driver, it always needs the firmware binary image, which it uploads to the Wifi chip. The VIA driver release you linked stores the binary image in the firmware.c file. As the kernel has an infrastructure for dealing with firmware images, the driver in the kernel has been modified to use that instead, and not include any binary blobs with uncertain licensing in the source code. This is why I have to download the firmware file manually.

But if you're successfully used the external vt6656 driver on 2.6 before, I will try that, too.

Have you got the WiFi sorted out yet?

I tried to build the version 1.20.03 from VIA, but it doesn't seem to build out of the box on 3.1.

Have you got the WiFi sorted out yet?

I tried to build the version 1.20.03 from VIA, but it doesn't seem to build out of the box on 3.1.

No, unfortunately not, I gave up on the VIA driver, and (once again) decided to stay away from VIA hardware and their crappy drivers. I also tried the driver from the VIA Homepage you're referring to, it seems to be a bit older than what's in the kernel, but in the end it just crashed the same way the staging driver did

Ralf, I just read about odd USB problems in your other thread, I didn't have these with the GSPCA webcam driver, but they remind me of the Wifi bug. Could both crashes possibly have the same cause? When I was debugging the Wifi crash, I ended up in the kernel timer code where an invalid (overwritten?) element was removed from the pending timer list (AFAIR). Couldn't find out where it was overwritten, I was looking for problems in the Wifi driver all the time, but USB could very well be the culprit here, too.

Are you up to a fully functional camera or just a Linux shell?

Depends on what you mean by "fully functional" ;-)

It's definitely not fully functional as the original stock firmware, in terms of features supported, like FTP upload, DynDNS updates, user-configurability, etc.

What I have running is the kernel, which works fine as long as you stay away from the Wifi device. The camera device is exposed to userland and all three modes (mmap(), user-allocated pages and read()) are working. I wrote an HTTP server based on libmicrohttpd that serves the MJPEG stream to multiple clients. It's quite stable, had it running without interruptions for a couple of days (with wget fetching the stream).

However, it does not offer a nice user interface for configuration, so it's no good for end users.

Other things I got working:
- dhcpcd
- dropbear (working but probably not worth the effort, handshake takes ~20s, needs quite a lot of RAM and the binary is ~330K)
- libssl (tried hashing and signing)
- libjpeg
- compiled wpa_supplicant