HitchHacker Guide to ENP-2611

"Dont' panic: your own kernel will be running on IXP-2400 very soon"

Basic Information

This page is a companion for HitchHiker Guide to ENP-2611, and i will assume that you already have your Radisys ENP card "up and running" ... Especially, make sure you can reboot your card in less than 30 seconds through PCI or development will be a nightmare. We will focus on the (potentially) more ambitious goal of compiling our own Linux kernel (and later ENP-specific drivers) ...

As in the HitchHiker's Guide, i'm using the MontaVista filesystem and cross-compilation tools as a reference.

When the going gets tough ...

There are a couple of "weird" situations you could encounter while building (and loading) your own kernel for the radisys card:

$T050f:0C028000;0d:01000000
After having loaded and executed the kernel, your minicom console only displays those weird characters (or similar). And if you type something, you just get more garbage characters. e.g.

RedBoot> go $T050f:00080044;0d:0ffd0fec;#1b$T050f:00080044;0d:0ffd0fec;#1b$T050f:00080044;0
Don't panic (not yet): this is just the GDB debugging protocol. Chances are that you're not feeding RedBoot with the proper executable (e.g. a zImage) but with an ELF file (vmlinux ? or vmlinuz ?) instead.
Out of curiousity, you could quit minicom, start xscale_be-gdb vmlinux and invoke

gdb> target remote /dev/ttyS0

that will then let you see where things have gone bad. But don't expect miracles here and rather check your zImage.

"Unrecognized image type: 0xe1a00000"
RedBoot do not know the "format" of a zImage file ... actually, it has no format :P A proper zImage starts with instructions that unpack the kernel at a 'proper' location (that is, your load address and the execute addresses are the same) so the "0xe1a00000" thing is nothing else that the equivalent of "NOOP" on the XScale processor ... you might wish to disassemble head.o (found in $LINUX/arch/arm/boot/compressed) and compare this with the start of the zImage

hexdump -C zImage 00000000 e1a00000 e1a00000 e1a00000 e1a00000 * 00000020 ea000002 016f2818 00000000 000bafbc 00000030 e1a07001 e3a08000 e10f2000 e3120003 00000040 1a000001 e3a00017 ef123456 e10f2000 00000050 e38220c0 e121f002 e3cf201f e2823801 00000060 e4920020 e1320003 1afffffc ee070f9a 00000070 ee070f17 ee110f10 e3c00005 e3c00a01 00000080 ee010f10 e3a070f2 ee110f10 e3800080
objdump -drS head.o 00000000 <start>: 0: e1a00000 nop (mov r0,r0) 4: e1a00000 nop (mov r0,r0) 8: e1a00000 nop (mov r0,r0) * 20: ea00000a b 30 <start+0x30> 20: R_ARM_PC24 .start 24: 016f2818 cmneq pc, r8, lsl r8 ... 28: R_ARM_ABS32 .start 2c: R_ARM_ABS32 _edata 30: e1a07001 mov r7, r1 34: e3a08000 mov r8, #0 ; 0x0 38: e10f2000 mrs r2, CPSR 3c: e3120003 tst r2, #3 ; 0x3

there's no need to be worried, though: RedBoot doesn't need to understand the image, just load it as raw bytes (-r option) and execute the first byte.

Whoops ... minicom gets crazy
You just seen "uncompressing linux............", and then the display seems to get crazy ? displaying non-sense characters (even non alphanumeric ones) at full speed, clearing again and again ? That's just an artefact of poorly adjusted ttyS0 speed. Remember we had to change minicom speed from 11Kbps to 57600 to have RedBoot display working fine ? The reverse happens here: the Linux kernel is pre-configured with a default value of 11Kbps for serial console, so you should make menuconfig again (or make xconfig, depending on what you prefer) and set up

console=ttyS0,57600 ip=bootp root=/dev/nfs gdbbaud=57600 gdbttyS=1 nohalt

Recompiling a kernel from sources

http://ixp2xxx.sourceforge.net/kernel/kernel.html provide valuable instructions for building your own kernel, yet here's the steps i took:

wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.15.5.tar.bz2

wget http://ixp2xxx.sourceforge.net/kernel/patch-2.6.15-lb1

tar jxvf linux-2.6.15.5.tar.bz2

ln -s linux-2.6.15.5 linux-2.6.15

patch -p0 < patch-2.6.15-lb1

(oh, i know, this certainly extremely common to anyone else, but i'm not that used to patching linux kernels, so i'd rather have the exact steps listed here). kernel.html then says that i should "make sure you have a proper ARM cross-toolchain" and "Set CROSS_COMPILE in your top-level Makefile to your toolchain's prefix".

The make ARCH=arm enp2611_defconfig then sets up all the parameters automatically for our specific target. Good thing to have: that makes the settings i gathered below almost useless :)
Note that you'll also be required to do "make ARCH=arm zImage" after. If you happen to do just "make zImage" or even just "make dep" (which is apparently not required ??), you might end up with include/asm pointing to i386 host instead of arm target :P

note: you may save the pain of repeating "ARCH=arm" by simply stating "ARCH?=arm" in the top makefile, just near "CROSS_COMPILE ?=" ...

Well, it's compiling right now, so i'll sign off and grab some soup ^_^

You'll notice in the "walk through configuration options" that, even if module support is activated, all of the IXP "standard" devices are compiled "straight in" rather than as modules.

include/linux/jiffies.h:213:31: division by zero in #if

This, aswell as "warning: `regparm' attribute directive ignored" or " error: unknown register name `dx' in `asm'" is an evidence of a wrong "include/asm" symbolic link. Just rm include/asm and make sure you properly use ARCH=arm in all your make commands, or better, hardcode it in the top makefile.

xscale_be-ld:arch/arm/kernel/vmlinux.lds:1608: parse error
The auto-generated linker script, instructing the compilation tools where to put every bits compiled so far into the vmlinux ELF file has "ASSERT((...))" macros at the end of it. The vmlinux.lds claims that "if you have to comment them, your binutils is too old" yet all i have so far to build ARM stuff is the MontaVista binutils, so let's just comment them ... Note that ixp2xxx.sourceforge.net also provide pre-compiled cross toolchain on their site, which will support the ASSERT and won't complain.

note: the toolchain is sometimes a bit hard to retrieve from the website. An automated tool such as wget will be your friend to resume interrupted downloads. Just in case, here's the MD5 sum of the file i finally gathered.
3c4b805632601c20627a21ab21e2d768 ../armeb-unknown-linux-gnu-gcc-3.3.3-glibc-2.3.2.tar.bz2

xscale_be-nm : no such file
The toolchain provided my MontaVista (at least, the previewkit 3.1 i have) do not feature the "nm" tool (required to build the list of exported symbols "Sytem.map"). Mixing xscale_be-xxx binutils with armeb-unknown-linux-gnu-nm tool might not be the best idea (you're probably better to restart kernel compilation with armeb-* tools only), but it worked as soon as i defined
setenv CONFIG_KALLSYMS_EXTRA_PASS 1
to avoid inconsistent symbols map. You'll be prompted to do so if it's really required, anyway ...

ENP-specific drivers

Drivers provided by Radisys for pm3386 (the gigabit Ethernet ports), spi3br (the FPGA bridge to Ethernet ports, also known as 'caleb') and the microengine assume a 2.4.xx kernel. There's another patch for kernel 2.6.15 on ixp2xxx.sourceforge.net that offers network devices for the ENP-2611 board. After patching, make enp2611_defconfig now lists more options related to ENP-2611:

wget http://ixp2xxx.sourceforge.net/kernel/netdev/ixp2000-netdev-0.2-2.6.15.diff

patch -p0 < ixp2000-netdev-0.2-2.6.15.diff

make ARCH=arm enp2611_defconfig

they are however disabled by default, as we can see through the log below, but using make ARCH=arm xconfig, we can enable them (preferably as modules)

lx26155/linux-2.6.15> make ARCH=arm enp2611_defconfig | grep IXP 9. IXP4xx-based (ARCH_IXP4XX) > 10. IXP2400/2800-based (ARCH_IXP2000) * Intel IXP2400/2800 Implementation Options * IXP2400/2800 Platforms Support broken PCI I/O on older IXP2000s (IXP2000_SUPPORT_BROKEN_PCI_IO) [N/y/?] n CFI Flash device mapped on Intel IXP2000 based systems (MTD_IXP2000) [Y/n/m/?] y IXP2000 Watchdog (IXP2000_WATCHDOG) [Y/n/m/?] y IXP2000 thread interrupt driver (IXP2000_THD) [N/m/y/?] (NEW) n IXP2000 GPIO-Based I2C Interface (I2C_IXP2000) [Y/n/m/?] y lx26155/linux-2.6.15> make ARCH=arm enp2611_defconfig | grep ENP Support Radisys ENP-2611 (ARCH_ENP2611) [Y/n/?] y Radisys ENP2611 MSF network interface support (ENP2611_MSF_NET) [N/m/y/?] (NEW) n

IXP2000 thread interrupt driver (IXP2000_THD)
(under DeviceDrivers/CharacterDevices ; the module will be called ixp2000_thd)
If you say Y here and create a character special file /dev/ixp2000_thd with major number 10 and minor number 194 using mknod ("man mknod"), you will be able to send signals from the IXP2000's microengines to userspace applications without having to resort to polling.

mknod dev/ixp2000_thd c 10 194 should then make it...

Radisys ENP2611 MSF network interface support (ENP2611_MSF_NET)
(hm. documentation for that one is not very helpful :P)
This is a driver for the MSF network interface unit in the IXP2400 on the Radisys ENP2611 platform.

Unable to handle kernel paging request at virtual address fe901000 pgd = c0454000 [fe901000] *pgd=00000000 Internal error: Oops: f5 [#1] Modules linked in: enp2611_mod ixp2000_thd CPU: 0 PC is at ixpdev_init+0x30/0x3d4 [enp2611_mod] LR is at 0xc0212874
when i try to load that module, i get segmentation fault at 0xfe901000 ... it seems this has been discussed on the mailing list, but the closest i find is:
 Decided to give it a try, and I see this too.  The problem seems to
> occur whenever you specify a size that is not a multiple of 1 megabyte
> -- if you use 0x00100000 for .length it works fine.  I'll check out
> what is causing this.

For the other readers -- it turns out that you can't mix page (4K)
and section (1MB) mappings within the same aligned 2MB virtual region
because of an implementation detail.  Doing an 1MB mapping at
0xfe200000 and a 4K mapping at 0xfe400000 works fine.

Yuppiii!! It works! (Not crashes!)

SRAM 1Mb at 0xFA000000 and scratch 4Kb at 0xFA200000
unfortunately, that doesn't help me to find out what should be changed to avoid those errors... it appears that http://ixp2xxx.sourceforge.net/kernel/netdev/patch-2.6.15-rc1-ue1 might contain patches for those stuff, so i should probably have patched the kernel with that rather than "netdev" patch described above.
The mappings for virtual addresses are defined in arch/arm/mach-ixp2000/core.c. If you experienced issues while applying successive patches, check that file, and especially the ixp2000_io_desc[] table which should have definitions for

IXP2000_CAP_VIRT_BASE

IXP2000_INTCTL_VIRT_BASE

IXP2000_PCI_CREG_VIRT_BASE

IXP2000_PCI_CSR_VIRT_BASE

IXP2000_MSF_VIRT_BASE

IXP2000_SCRATCH_RING_VIRT_BASE

IXP2000_SRAM0_VIRT_BASE

IXP2000_PCI_IO_VIRT_BASE

IXP2000_PCI_CFG0_VIRT_BASE

IXP2000_PCI_CFG1_VIRT_BASE

The bold mappings were missing from ixp2000-netdev-0.2-2.6.15.diff ... with those added, i can now enjoy
# insmod /lib/modules/ixp2000_thd.ko Using /lib/modules/ixp2000_thd.ko IXP2000 thread interrupt driver v0.3 # insmod /lib/modules/enp2611_mod.ko Using /lib/modules/enp2611_mod.ko IXP2000 MSF ethernet driver 0.2 * 192 receive buffers from 0 [..................] * 192 transmit buffers from ff8f000 [................] * preparing ring registers * load microengine[0] * load microengine[1] eth1: IXP2000 MSF ethernet (port 0), 00:00:50:11:60:d3. eth2: IXP2000 MSF ethernet (port 1), 00:00:50:11:60:d4. eth3: IXP2000 MSF ethernet (port 2), 00:00:50:11:60:d5. eth1: NIC Link is Down eth2: NIC Link is Down eth3: NIC Link is Down

Recompiling IXA Microengines Drivers

The intel IXA SDK comes with libraries, drivers and tools to work with microengines, including microcode loading. This is achieved by three modules for linux 2.4.xx.

A pre-alpha patch allowing you to use /dev/MeDrv0 for linux 2.6.15 is available from this site. major changes include:

modified build system (which i'll have to return to normal later)

a final makefile that generates a module for kernel 2.6

-fno-common compilation flag, as required by kernel modules

getting rid of MOD_XXX_USE_COUNT related calls

fixing modified headers names

replaced mem_map_reserve() by SetPageReserved()

replaced remap_page_range() by remap_pfn_range()

rearranged modinit/modcleanup to build a single .ko file

provided a "setup" file where you define your environment.

Structure of the IXA-based driver:

LxMeDrv.ko (home-built drawing inspiration from IXA .mak files)
uclo.a, the microcode loader library compiled for kernel-mode
XSC_CoreLibs/uclo/*
XSC_CoreLibs/uclo/uclo_kernel.mak
utils_kernel.a some generic features (also compiled for kernel mode)
Utils/*
Utils/utils_kernel.mak
halMev2_lib.o
halMev2_kernel.mak
k_halMev2.o
k_halMeLinuxUsr.o
k_halOs.o
halMeDrv.o
k_halMeDrv.o
k_linuxMeDrv.o
k_halMeDrvKsem.o
k_halMmap.o
libossl.o
k_ossl.o

The IXA makefile system is designed for many platforms (vxworks, qnx, embedded linux, win32 simulator) and has to produce the user-side part of the drivers as well as the kernel side, most of the time the same sources are used and will build either user-side or kernel-side depending on some compilation flags (__KERNEL__, obviously). It also assumes that there will be several directories: LIB_DIR where ready-to-use libraries go, BIN_DIR where intermediate (e.g. pre-linked) components go and the OBJ_DIR where compiled individual sources go. That means if one does not take care, halMeDrv.o grouping k_*.o (in BIN_DIR) might collide with the user-side part of k_halMeDrv.o (in OBJ_DIR). Since i had to patch makefiles to have k_... prepended, i guess the intel make system was actually managing to build two subset of directories, one for kernel stuff and the other for userlevel stuff.

Moreover, the BSP_DIR should be pointing at your linux-for-arm source tree.

LxMeDrv.ko vs enp-2611.ko
One should note that both ENP-enabled kernel and IXA's driver LxMeDrv build a mapping between IXP's devices and the virtual memory. while these redundant mappings aren't a real issue, it could be interresting to come with an unified framework where the IXA driver could detect and benefit of built-in support for the ENP card in the kernel.

It's unfortunately not as simple as it might look at first sight. For instance, halMeDrv uses several mappings for SRAM to allow atomic operations (e.g. accessing physical address 0x80000000 is "normal" read/write access to SRAM, 0x84000000 is "bit set" atomic operation, 0x88000000 is "bit clear" atomic, etc). One could thus modify mach-ixp2000/core.c to enable them, as already discussed in the ixp2xxx mailing list.

A Walk through kernel compile-time options.

# linux-2.6.15.5/Makefile # Cross compiling and selecting different set of gcc/bin-utils # --------------------------------------------------------------------------- # # When performing cross compilation for other architectures ARCH shall be set # to the target architecture. (See arch/* for the possibilities). # ARCH can be set during invocation of make: # make ARCH=ia64 # Another way is to have ARCH set in the environment. # The default ARCH is the host where make is executed. # CROSS_COMPILE specify the prefix used for all executables used # during compilation. Only gcc and related bin-utils executables # are prefixed with $(CROSS_COMPILE). # CROSS_COMPILE can be set on the command line # make CROSS_COMPILE=ia64-linux- # Alternatively CROSS_COMPILE can be set in the environment. # Default value for CROSS_COMPILE is not to prefix executables # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile ARCH ?= $(SUBARCH) CROSS_COMPILE ?=	so in this case, we shoud have CROSS_COMPILE defined to xscale_be- and /opt/montavista/previewkit/ arm/xscale_be/bin in our path ... additionnally, the ARCH should be set to "arm enp2611_defconfig" according to kernel/kernel.html
`<edit> ARCH ?= arm CROSS_COMPILE ?= xscale_be- </edit> setenv PATH /opt/montavista/previewkit/arm/xscale_be/bin:$PATH`	that should make it :)
`lx26155/linux-2.6.15> make ARCH=arm enp2611_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/split-include HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o HOSTCC scripts/kconfig/mconf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o ...`	the enp2611_defconfig will automatically answer to a setup parameters you (at least, I) normally enter with make menuconfig or make xconfig. KOBJECT_UEVENT enabled CC_OPTIMIZE_FOR_SIZE enabled EMBEDDED enabled :P MODULES, MODULE_UNLOAD and KMOD enabled, of course ;)
`* * Userspace binary formats * Kernel support for ELF binaries (BINFMT_ELF) [Y/n/?] y Kernel support for a.out and ECOFF binaries (BINFMT_AOUT) [N/m/y/?] n Kernel support for MISC binaries (BINFMT_MISC) [N/m/y/?] n RISC OS personality (ARTHUR) [N/m/y/?] n`	system type selected is (in ARM systems) ARCH_IXP2000, and ENP-2611 platform is selected. Binaries will be big-endian, without the 'thumb' instruction set support. Note that only ELF format is supported.
`* * Boot options * Compressed ROM boot loader base address (ZBOOT_ROM_TEXT) [0x0] 0x0 Compressed ROM boot loader BSS address (ZBOOT_ROM_BSS) [0x0] 0x0 Default kernel command string (CMDLINE) [console=ttyS0,57600 root=/dev/nfs ip=bootp mem=192M@0x04000000 pci=firmware] console=ttyS0,57600 root=/dev/nfs ip=bootp mem=192M@0x04000000 pci=firmware Kernel Execute-In-Place from ROM (XIP_KERNEL) [N/y/?] n`	as we have seen earlier, the kernel is loaded in DRAM of the IXP -- not in the flash. the "mem=192M@0x04000000" instruction lets me somehow clueless.
* * Networking options * Packet socket (PACKET) [Y/n/m/?] y Packet socket: mmapped IO (PACKET_MMAP) [Y/n/?] y Unix domain sockets (UNIX) [Y/n/m/?] y TCP/IP networking (INET) [Y/n/?] y IP: kernel level autoconfiguration (IP_PNP) [Y/n/?] y IP: DHCP support (IP_PNP_DHCP) [Y/n/?] y IP: BOOTP support (IP_PNP_BOOTP) [Y/n/?] y IP: RARP support (IP_PNP_RARP) [N/y/?] n IP: TCP syncookie support (disabled per default) (SYN_COOKIES) [Y/n/?] y INET: socket monitoring interface (INET_DIAG) [Y/n/m/?] y	non-shown options are disabled. Among them, we should note that -- on the xscale at least, routing has been desactivated by default... DHCP and BOOTP will of course be mandatory to get our card bootstrapped smoothly in our config. Netfilters, IPv6, fair queueing and multicasting are also disabled...
`* * Memory Technology Devices (MTD) * Memory Technology Device (MTD) support (MTD) [Y/n/m/?] y MTD partitioning support (MTD_PARTITIONS) [Y/n/?] y RedBoot partition table parsing (MTD_REDBOOT_PARTS) [Y/n/m/?] y Location of RedBoot partition table (MTD_REDBOOT_DIRECTORY_BLOCK) [-1] -1 Include unallocated flash regions (MTD_REDBOOT_PARTS_UNALLOCATED) [Y/n/?] y Force read-only for RedBoot system images (MTD_REDBOOT_PARTS_READONLY) [Y/n/?] y`	This is why "exec xxxxxx" should be used instead of "go xxxx" : for RedBoot table parsing. Direct char, and block access to MTD are enabled, aswell as the "Common Flash Interface". Note also the activated options MTD_CFI_INTELEXT, MTD_IXP2000 and MTD_COMPLEX_MAPPINGS.
`RAM disk support (BLK_DEV_RAM) [Y/n/m/?] y Default number of RAM disks (BLK_DEV_RAM_COUNT) [16] 16 Default RAM disk size (kbytes) (BLK_DEV_RAM_SIZE) [8192] 8192 Initial RAM disk (initrd) support (BLK_DEV_INITRD) [Y/n/?] y`	now, this is intriguing me, since, in radisys manual, the ramdisk support was disabled and that shipped kernels from ixp2xxx.sf.net didn't need it either.
* * Network device support * Network device support (NETDEVICES) [Y/n/?] y Dummy net driver support (DUMMY) [Y/n/m/?] y Ethernet (10 or 100Mbit) (NET_ETHERNET) [Y/n/?] y Generic Media Independent Interface device support (MII) [Y/?] y EISA, VLB, PCI and on board controllers (NET_PCI) [Y/n/?] y EtherExpressPro/100 support (eepro100, original Becker driver) (EEPRO100) [Y/n/m/?] y * * Wan interfaces * Wan interfaces support (WAN) [Y/n/?] y Generic HDLC layer (HDLC) [Y/n/m/?] y Raw HDLC support (HDLC_RAW) [Y/n/?] y Cisco HDLC support (HDLC_CISCO) [Y/n/?] y Frame Relay support (HDLC_FR) [Y/n/?] y Synchronous Point-to-Point Protocol (PPP) support (HDLC_PPP) [Y/n/?] y Frame Relay DLCI support (DLCI) [Y/n/m/?] y Max open DLCI (DLCI_COUNT) [24] 24 Max DLCI per device (DLCI_MAX) [8] 8	So we have support for the "management port" of the ENP-2611 (which happens to be a legacy intel Ethernet 100Mbps chip), and (likely) generic support for the media switch framing interface, but i do not see explicit support for the pm_3386 or the SPI-3 devices. There are instructions about them in appendix B of radisys manual, which i'll have to inspect later.
`8250/16550 and compatible serial support (SERIAL_8250) [Y/n/m/?] y Console on 8250/16550 and compatible serial port (SERIAL_8250_CONSOLE) [Y/n/?] y Maximum number of 8250/16550 serial ports (SERIAL_8250_NR_UARTS) [2] 2 Extended 8250/16550 serial driver options (SERIAL_8250_EXTENDED) [N/y/?] n`	is the UART on the ENP card one of these ?
`* * Non-8250 serial port support * Digi International NEO PCI Support (SERIAL_JSM) [N/m/y/?] n Unix98 PTY support (UNIX98_PTYS) [Y/n/?] y Legacy (BSD) PTY support (LEGACY_PTYS) [Y/n/?] y Maximum number of legacy PTY in use (LEGACY_PTY_COUNT) [256] 256`	this is the "ptys/ptmx" support flag that is mentionned in the questions about telnet not working properly. Nice to see it enabled here :P
`Watchdog Timer Support (WATCHDOG) [Y/n/?] y IXP2000 Watchdog (IXP2000_WATCHDOG) [Y/n/m/?] y I2C support (I2C) [Y/n/m/?] y I2C device interface (I2C_CHARDEV) [Y/n/m/?] y I2C bit-banging interfaces (I2C_ALGOBIT) [Y/?] y IXP2000 GPIO-Based I2C Interface (I2C_IXP2000) [Y/n/m/?] y`	a bit more IXP-specific options activated here
Second extended fs support (EXT2_FS) [Y/n/m/?] y Ext2 extended attributes (EXT2_FS_XATTR) [Y/n/?] y Ext2 POSIX Access Control Lists (EXT2_FS_POSIX_ACL) [Y/n/?] y Ext3 journalling file system support (EXT3_FS) [Y/n/m/?] y Ext3 extended attributes (EXT3_FS_XATTR) [Y/n/?] y Ext3 POSIX Access Control Lists (EXT3_FS_POSIX_ACL) [Y/n/?] y Inotify file change notification support (INOTIFY) [Y/n/?] y Dnotify support (DNOTIFY) [Y/n/?] y Journalling Flash File System v2 (JFFS2) support (JFFS2_FS) [Y/n/m/?] y JFFS2 debugging verbosity (0 = quiet, 2 = noisy) (JFFS2_FS_DEBUG) [0] 0 JFFS2 write-buffering support (JFFS2_FS_WRITEBUFFER) [Y/n/?] y JFFS2 summary support (EXPERIMENTAL) (JFFS2_SUMMARY) [N/y/?] n Advanced compression options for JFFS2 (JFFS2_COMPRESSION_OPTIONS) [N/y/?] n NFS file system support (NFS_FS) [Y/n/m/?] y Provide NFSv3 client support (NFS_V3) [Y/n/?] y NFS server support (NFSD) [N/m/y/?] n Root file system on NFS (ROOT_NFS) [Y/n/?] y	aha ? surprisingly enough, we will build EXT2/EXT3 support on a kernel that is meant to be run on a diskless chip that access stuff purely through NFS ... Journalized flash filesystem is somehow i understand better to be here :P Support for DOS/BIOS partitions is also activated ... probably a mistake from the patchers ...
`* * Pseudo filesystems * /proc file system support (PROC_FS) [Y/n/?] y sysfs file system support (SYSFS) [Y/n/?] y Virtual memory file system support (former shm fs) (TMPFS) [Y/n/?] y`