Target CPU selection for Real time Embedded Linux
On Thu, Dec 05, 2002 at 04:48:32PM +0530, Alexander.J at lntinfotech.com wrote: Hi all, We would like to build a Router software engine using Real Time Embedded linux. The alternatives that immediately come to Mind are: - Xilinx Virtex II Pro with Linux (Linux port posted 2 months ago and on ftp.mind.be) - Intel IXP425 with Linux (Linux port expected Jan 2003) I believe both those chips where targeted specifically to build high-end, modern one-chip routing solutions. They have high speed connections on them. What is the bandwidth and number of interfaces you are targeting ? In this process, we need to freeze the target CPU. Could anyone help me in this regard? In the telecom sector PowerPC is the standard (the optimized power consumption of the ARM family is less relevant in switches; and PowerPC is high-performant). XScale (ARM derived) is also a new performant platform that is available at high frequencies in certain chips (80200 e.g.). Typical operation frequencies of PowerPC405 and XScale in both chips are 300 MHz I believe. Please note that the use of the FPGA created some very spectacular possibities, such as the idea to build-in a wirespeed firewall in the FPGA logic, where you could reprogram the rules through a reconfiguration of the FPGA filters (this is not a SW firewall, but it is still reprogrammable). Peter Thanks Alex -- .. | Mind: Embedded Linux and eCos Development. | | Mind is looking for Embedded Linux and eCos Developers | || | Peter Vandenabeele, CEO email: peter at mind.be | | Mind (http://mind.be)tel: +32-16-30.96.66 | | Vaartkom 11 fax: +32-16-30.96.44 | | B-3000 Leuven, Belgium gsm: +32-478-27.40.69 | '' ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
4xx critical exceptions
On Thu, 2002-12-05 at 00:00, Brian Kuschak wrote: I'm interested in using the watchdog interrupt as a critical exception. I have somthing that sort-of works, in that I get wdt interrupts and service them appropriately, but I'm getting panics on a regular basis. I thought this was strange as I had seen a watchdog driver in the kernel for 405 but after reading the source of said driver I no longer think that:( I have not tried the driver but from the look of it I would say it's not doing anything useful. I'm guessing we don't have any unused SPRGx registers to use here. I was thinking about temporarily disabling CE until saving SPRG0,1, but that can't be done without using at least one register, and none of them are saved at that point. Any ideas? Not really. Do you want to try to set up a c environment or do you plan on just doing the thing in asm directly? The code in the exception handler do not have to do much something like if(wdt_count++ max_wdt_loops) clear_wdt_ENW(); return should do. Then if userspace or whatever it is that kicks the dog has not reset the wdt_count we let the hardware just do the reset. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot flash problem,
Hello, all, I meet a strange problem of boot flash and want some advice here. I have searched the archives but with no result. So bear with me if this is too silly question. I designed a mpc860T(D4, 50Mhz)board. I used the ppcboot 0.9.2 as bootloader and the hardhat linux pe 2.1(with the kernel of 2.4.17). My board has a 2MB flash(intel te28f160c3-90) as bootrom,and everything works okay. Now i want to use a larger flash(intel te28f320c3-110, which is pin-to-pin compatible to te28f160 ).I mounted the flash on the board, and prog the ppcboot (in elf format) with my bdi2000.The erasing and programming operation works with no error found.Then i restart the board without bdi', i find minicom has no response. I check the board and find that the cpu's clockout is 25Mhz(i use a 5M clock in, and mf=5). It seems that the ppcboot in flash has not work at all. I then check the board with my bdi2000. Everything works okay. I read the datasheet of intel 28f160/320 c3 carefully, and do not find anything special to be treated. Here is my seting of bdi and in ppcboot,any suggestion is appreciated. bdi configuration file: .. WM320xFF000100 0xFFE00801 ;BR0 WM320xFF000104 0xFFC00160 ;OR0 : 2MB, all accesses, CS early negate, 6ws, time relax .. ;unlock intel flash here WM16 0xFFe0 0x0060 ;unlock block 0 WM16 0xFFe0 0x00D0 WM16 0XFFE02000 0x0060 ;unlock block 0 WM16 0XFFE02000 0x00D0 WM16 0XFFE04000 0x0060 ;unlock block 0 WM16 0XFFE04000 0x00D0 WM16 0XFFE06000 0x0060 ;unlock block 0 WM16 0XFFE06000 0x00D0 WM16 0XFFE08000 0x0060 ;unlock block 0 WM16 0XFFE08000 0x00D0 WM16 0XFFE0a000 0x0060 ;unlock block 0 WM16 0XFFE0a000 0x00D0 WM16 0XFFE0c000 0x0060 ;unlock block 0 WM16 0XFFE0c000 0x00D0 WM16 0XFFE0e000 0x0060 ;unlock block 0 WM16 0XFFE0e000 0x00D0 WM16 0XFFE1 0x0060 ;unlock block 0 WM16 0XFFE1 0x00D0 WM16 0xFFe0 0x0060 ;unlock block 0 WM16 0xFFe0 0x00D0 WM16 0xFFe1 0x0060 ;unlock block 1 WM16 0xFFe1 0x00D0 WM16 0xFFe2 0x0060 ;unlock block 0 WM16 0xFFe2 0x00D0 WM16 0xFFe3 0x0060 ;unlock block 1 WM16 0xFFe3 0x00D0 .. [FLASH] CHIPTYPEI28BX16 ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16|I28BX32) CHIPSIZE0x40 ;The size of one flash chip in bytes (e.g. AM29F010 = 0x2) BUSWIDTH16 ;The width of the flash memory bus in bits (8 | 16 | 32) configuration of ppcboot: #define CFG_REMAP_OR_AM 0xFFE0 /* OR addr mask */ #define CFG_PRELIM_OR_AM0xFFC0 /* OR addr mask */ #define CFG_OR_TIMING_FLASH (OR_BI | OR_SCY_6_CLK) #define CFG_OR0_REMAP (CFG_REMAP_OR_AM | CFG_OR_TIMING_FLASH) #define CFG_OR0_PRELIM (CFG_PRELIM_OR_AM | CFG_OR_TIMING_FLASH) /* 16 bit, bank valid */ #define CFG_BR0_PRELIM ((FLASH_BASE BR_BA_MSK) | BR_PS_16 | BR_V ) i make modification only in my configuration file, shall i change settings in other files? Best regards. Li Xiangrong lixiangrong at china.com 2002-12-06 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Embedded Planet RPX LICC_E board and Timesys
I am currently working on a research project involving the RPX MPC850SR LICC_E board from Embedded Planet. I tried the BSP provided by Timesys for the 850 but after tftping the image to the board and 'go' nothing happened. I spoke to the reps from timesys and embedded planet and found that the 850 BSP was compiled for the LITE_CW versions of the Embedded Planet boards. These differed due to the existence of NVRAM and an RTC. I recompiled the kernel using several different configurations and was able to get the kernel to boot when the NVRAM option was turned off. I can boot the kernel and load the NFS root with the initrd and ramdisk options turned off but when I enable these options, the kernel stops booting at the ramdisk creation. Can anyone provide any insight about this problem? Thank You Donald MacArthur dmacarth at ufl.edu ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
Hi Can someone tell what is the deal with these functions? consistent_alloc et. al. are very useful to me now that I'm cleaning up my QMC driver. But they are exported. Is there any reason why they are not exported for use by modules? Also they appear to be tied to the PCI bus, a reduntant dependancy IMHO. Regards -- Pantelis Antoniou INTRACOM S.A. Greece I read slashdot because it's so hard to find anything else intelligent to read. Keep searching... -- as seen on slashdot -- ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Embedded Planet RPX LICC_E board and Timesys
I built the Timesys Linux for the 850 and ran it on a LICC_E, it booted into the initrd just fine. -Original Message- From: Donald MacArthur [mailto:[EMAIL PROTECTED] Sent: Friday, December 06, 2002 7:25 AM To: linuxppc-embedded at lists.linuxppc.org Subject: Embedded Planet RPX LICC_E board and Timesys I am currently working on a research project involving the RPX MPC850SR LICC_E board from Embedded Planet. I tried the BSP provided by Timesys for the 850 but after tftping the image to the board and 'go' nothing happened. I spoke to the reps from timesys and embedded planet and found that the 850 BSP was compiled for the LITE_CW versions of the Embedded Planet boards. These differed due to the existence of NVRAM and an RTC. I recompiled the kernel using several different configurations and was able to get the kernel to boot when the NVRAM option was turned off. I can boot the kernel and load the NFS root with the initrd and ramdisk options turned off but when I enable these options, the kernel stops booting at the ramdisk creation. Can anyone provide any insight about this problem? Thank You Donald MacArthur dmacarth at ufl.edu ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
Hi If you implement the performance improvement I suggested earlier, I don't think you need them. Another thing with consistent_xxx() is that you can not use __pa() and __va() on addresses returned by the consistent_alloc et. al. I think Dan Malek and/or Tom Rini knows more about these functions. Jocke Pantelis Antoniou wrote: Hi Can someone tell what is the deal with these functions? ^ me consistent_alloc et. al. are very useful to me now that I'm cleaning up my QMC driver. But they are exported. ^ not Is there any reason why they are not exported for use by modules? Also they appear to be tied to the PCI bus, a reduntant dependancy IMHO. Regards -- Pantelis Antoniou INTRACOM S.A. Greece I read slashdot because it's so hard to find anything else intelligent to read. Keep searching... -- as seen on slashdot -- Sigh, Maybe I should read the mail more before hitting send. -- Pantelis Antoniou INTRACOM S.A. Greece I read slashdot because it's so hard to find anything else intelligent to read. Keep searching... -- as seen on slashdot -- ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
On Fri, Dec 06, 2002 at 03:18:21PM +0200, Pantelis Antoniou wrote: Hi Can someone tell what is the deal with these functions? consistent_alloc et. al. are very useful to me now that I'm cleaning up my QMC driver. But they are exported. Is there any reason why they are not exported for use by modules? They are exported in the development trees I use, linuxppc_2_4_devel and linuxppc-2.5. Also they appear to be tied to the PCI bus, a reduntant dependancy IMHO. How so? consistent_alloc/consistent_free are independent of pci bus. Use those. pci_* are, by definition, pci-specific and only exported on PCI-based systems. Regards, -- Matt Porter porter at cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
On Fri, Dec 06, 2002 at 03:25:48PM +0100, Joakim Tjernlund wrote: If you implement the performance improvement I suggested earlier, I don't think you need them. Another thing with consistent_xxx() is that you can not use __pa() and __va() on addresses returned by the consistent_alloc et. al. Um, well if you are doing a consistent_alloc() then surely you are keeping the dma_handle around which is your physical address. If you want the kernel virtual address then you can apply __va to that. So, you have the cache inhibited mapping in vmalloc space returned to you, the physical address provided in dma_handle, and a kernel virtual address that can be trivially generated. Regards, -- Matt Porter porter at cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
Matt Porter wrote:
If you
want the kernel virtual address then you can apply __va to that.
Errrno, you can't. That would give you the cached mapping.
You need to hang on to both the dma_handle (the phys address token)
and the virtual address returned by the function. That's why both
are returned.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
boot flash problem,
bdi configuration file: .. WM320xFF000100 0xFFE00801 ;BR0 WM320xFF000104 0xFFC00160 ;OR0 : 2MB, all If you use a flash of 4MB, then move the base address from 0xFFE0 to 0xFFC0. Set the base address in BR0 to 0xFFC0, not 0xFFE0. Your BDI probably programmed the boot loader at the wrong place. Regards, Jean-Denis Boyer, B.Eng., Technical Leader Mediatrix Telecom Inc. 4229 Garlock Street Sherbrooke (Qu?bec) J1L 2C8 CANADA (819)829-8749 x241 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
On Fri, Dec 06, 2002 at 05:08:22PM +0100, Joakim Tjernlund wrote: On Fri, Dec 06, 2002 at 03:25:48PM +0100, Joakim Tjernlund wrote: If you implement the performance improvement I suggested earlier, I don't think you need them. Another thing with consistent_xxx() is that you can not use __pa() and __va() on addresses returned by the consistent_alloc et. al. Um, well if you are doing a consistent_alloc() then surely you are keeping the dma_handle around which is your physical address. If you want the kernel virtual address then you can apply __va to that. So, you have the cache inhibited mapping in vmalloc space returned to you, the physical address provided in dma_handle, and a kernel virtual address that can be trivially generated. m8xx_cpm_hostalloc() does not keep the DMA handle and __pa() does not work on addresses returned by m8xx_cpm_hostalloc(). I just found that out the hard way when upgrading from MV 2.4.2 to linuxppc_2_4_devel 2.4.20. My SPI driver that's a problem with m8xx_cpm_hostalloc() (or how you are using it) if it doesn't keep around the values you need. Yes and no, someone changed the m8xx_cpm_hostalloc() implementation and now it does not behave as it used to. Earlier both __pa(adr) and __va(__pa(adr)) worked on addresses returned by m8xx_cpm_hostalloc(). I think in it's current form it's useless and should either be changed back to what it was or die. Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
On Fri, Dec 06, 2002 at 11:56:22AM -0500, Dan Malek wrote:
Matt Porter wrote:
If you
want the kernel virtual address then you can apply __va to that.
Errrno, you can't. That would give you the cached mapping.
You need to hang on to both the dma_handle (the phys address token)
and the virtual address returned by the function. That's why both
are returned.
That's what I said...but you clipped it out. Once again,
consistent_alloc provides the caller everything they need.
An uncached mapping, a phys address, and from that you can use
__va() to get the cached mapping.
Seemed clear enough to me the first time. My definition of a
kernel virtual address is the lowmem cached mapping. If
I meant the uncached mapping I would have said it was a kernel
vmalloc address or something. :)
Regards,
--
Matt Porter
porter at cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
On Fri, Dec 06, 2002 at 05:08:22PM +0100, Joakim Tjernlund wrote: On Fri, Dec 06, 2002 at 03:25:48PM +0100, Joakim Tjernlund wrote: If you implement the performance improvement I suggested earlier, I don't think you need them. Another thing with consistent_xxx() is that you can not use __pa() and __va() on addresses returned by the consistent_alloc et. al. Um, well if you are doing a consistent_alloc() then surely you are keeping the dma_handle around which is your physical address. If you want the kernel virtual address then you can apply __va to that. So, you have the cache inhibited mapping in vmalloc space returned to you, the physical address provided in dma_handle, and a kernel virtual address that can be trivially generated. m8xx_cpm_hostalloc() does not keep the DMA handle and __pa() does not work on addresses returned by m8xx_cpm_hostalloc(). I just found that out the hard way when upgrading from MV 2.4.2 to linuxppc_2_4_devel 2.4.20. My SPI driver that's a problem with m8xx_cpm_hostalloc() (or how you are using it) if it doesn't keep around the values you need. -- Matt Porter porter at cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
On Fri, Dec 06, 2002 at 07:15:15PM +0100, Joakim Tjernlund wrote: On Fri, Dec 06, 2002 at 05:08:22PM +0100, Joakim Tjernlund wrote: that's a problem with m8xx_cpm_hostalloc() (or how you are using it) if it doesn't keep around the values you need. Yes and no, someone changed the m8xx_cpm_hostalloc() implementation and now it does not behave as it used to. Earlier both __pa(adr) and __va(__pa(adr)) worked on addresses returned by m8xx_cpm_hostalloc(). I think in it's current form it's useless and should either be changed back to what it was or die. The 8xx-specific stuff is clearly Dan's area...I was just commenting on your generic concerns about consistent_*. Regards, -- Matt Porter porter at cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
Matt Porter wrote: That's what I said...but you clipped it out. Once again, consistent_alloc provides the caller everything they need. An uncached mapping, a phys address, and from that you can use __va() to get the cached mapping. Well, in my defense...I think you said you can use __va() to get a kernel virtual address :-) To further confuse thing, yes it will give you a virtual address, but it isn't one that you want to use. Seemed clear enough to me the first time. My definition of a kernel virtual address is the lowmem cached mapping. It wasn't clear to me, and kernel virtual address really can't carry any other attributes since they are used to map a variety of address spaces, including non-cached and highmem :-) You need to update your glossary :-) Thanks. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
Joakim Tjernlund wrote: Yes and no, someone changed the m8xx_cpm_hostalloc() implementation and now it does not behave as it used to. Earlier both __pa(adr) and __va(__pa(adr)) worked on addresses returned by m8xx_cpm_hostalloc(). I changed it a while back so single large pages could be used to map the kernel space. Just use iopa() on the virtual address to get the physical address. I don't understand the current condition of commproc.c today, but I'm not the only one that updates it anymore. The bk comments are quite useless since all they indicate is some obscure patch was applied. I think in it's current form it's useless and should either be changed back to what it was or die. It seems quite useful to the drivers that currently use it.It's only purpose is to provide small non-cached objects like uart fifos and control areas. Don't try to use it for things not intended. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Unloved MPC hardware wanted
I know this isn't development related but it seems like an appropriate place to post this request. Does anyone have unloved, unwanted, 8xx or 82xx development systems laying around? We are trying to put together a testing/validation lab for these platforms. We will pay all expenses associated with shipping for anyone willing to share. PS: Has anyone considered creating a virtual platform test environment? Thoughts on how this may be implemented are welcome. TIA Allen Curtis | All good things come to those Ones and Zeros, Inc. | who wait. Some of us have to mailto:acurtis at onz.com| wait a little longer. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Regarding consistent_alloc
Joakim Tjernlund wrote: Yes and no, someone changed the m8xx_cpm_hostalloc() implementation and now it does not behave as it used to. Earlier both __pa(adr) and __va(__pa(adr)) worked on addresses returned by m8xx_cpm_hostalloc(). I changed it a while back so single large pages could be used to map the kernel space. Just use iopa() on the virtual address to get the physical address. I don't understand the current condition of commproc.c today, but I'm not the only one that updates it anymore. The bk comments are quite useless since all they indicate is some obscure patch was applied. I think in it's current form it's useless and should either be changed back to what it was or die. It seems quite useful to the drivers that currently use it.It's only purpose is to provide small non-cached objects like uart fifos and control areas. Don't try to use it for things not intended. Exacly, I was using it as a small fifo for my SPI driver(not really mine, I found it on the net). Since __pa() and __va() doesn't work anymore, it should be documented becauase I think most people expect __pa() and __va() to work on kernel memory and it did work in 2.4.2. Anyway, I have fixed my driver now so this is not a problem for me anymore. Jocke PS. Dan, are you still working/testing my 8xx_io/enet.c patch? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root woes: No init found
I am having a problem with NFS mounting the root filesystem. It seems that init is not being executed. However, the problem may be with rootpath not being set. Should that parameter be set from the kernel command nfsroot=? ## Booting image at 0040 ... Image Name: Linux-2.4.19-pre6 Created: 2002-12-06 17:44:09 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:901003 Bytes = 879 kB = 0 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:mapin_ram done MMU:setio MMU:exit setup_arch: enter setup_arch: bootmem arch: exit Linux version 2.4.19-pre6 (cpagnotta at lb-deviant-linux) (gcc version 2.95.4 20010 319 (prerelease/franzo/20011204)) #8 Fri Dec 6 09:28:29 PST 2002 On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. Kernel command line: root=/dev/nfs nfsroot=/tftpboot/powerpc-rootfs ip=172.25.59 .11:172.25.59.15::255.255.0.0:vib::off Calibrating delay loop... 263.78 BogoMIPS Memory: 127092k available (1524k kernel code, 676k data, 212k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Mount-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) POSIX conformance testing by UNIFIX PCI: Probing PCI hardware Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd devfs: v1.12 (20020219) Richard Gooch (rgooch at atnf.csiro.au) devfs: boot_options: 0x1 Installing knfsd (copyright (C) 1996 okir at monad.swb.de). JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB. i2c-core.o: i2c core module i2c-dev.o: i2c /dev entries driver module i2c-core.o: driver i2c-dev dummy driver registered. i2c-proc.o version 2.6.1 (20010825) pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI en abled ttyS00 at 0xef600300 (irq = 0) is a 16550A ttyS01 at 0xef600400 (irq = 1) is a 16550A ttyS02 at 0xf410 (irq = 26) is a ST16650V2 ttyS03 at 0xf420 (irq = 26) is a ST16650V2 PPC 405 watchdog driver v0.5 IBM gpio driver version 02.01.21.d GPIO #0 at 0xc900d700 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) eth0: Phy @ 0x1, type LXT971A (0x001378e2) pcnet32.c:v1.27a 10.02.2002 tsbogend at alpha.franken.de Equalizer1996: $Revision: 1.2.1 $ $Date: 1996/09/22 13:52:00 $ Simon Janes (simo n at ncm.com) Universal TUN/TAP device driver 1.4 (C)1999-2001 Maxim Krasnyansky NFTL driver: nftlcore.c $Revision: 1.85 $, nftlmount.c $Revision: 1.25 $ NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 8192 bind 8192) IPv4 over IPv4 tunneling driver GRE over IPv4 tunneling driver Reset ethernet interfaces eth0: IBM EMAC: link up, 10 Mbps Half Duplex, auto-negotiation complete. eth0: IBM EMAC: MAC 00:60:c2:0a:00:1f. eth0: IBM EMAC: open completed IP-Config: Complete: device=eth0, addr=172.25.59.11, mask=255.255.0.0, gw=255.255.255.255, host=vib, domain=, nis-domain=(none), bootserver=172.25.59.15, rootserver=172.25.59.15, rootpath= ip_conntrack (1024 buckets, 8192 max) ip_tables: (C) 2000-2002 Netfilter core team arp_tables: (C) 2002 David S. Miller NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 13/2 on 172.25.59.15 Looking up port of RPC 15/1 on 172.25.59.15 VFS: Mounted root (nfs filesystem). Mounted devfs on /dev Freeing unused kernel memory: 212k init Kernel panic: No init found. Try passing init= option to kernel. 0Rebooting in 180 seconds..NULL ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
