[uClinux-dev] Re: [uClinux-dev] problem of execve("/bin/init"...)

Michael Varga mike.varga at cavium.com
Thu Feb 6 10:48:28 EST 2003 

Where do I find distrubutions of
uC-libc that support arm?

----- Original Message -----
From: "Steve Lin" <stevelin at avalent.com>
To: <uclinux-dev at uclinux.org>
Sent: Friday, January 24, 2003 11:47 AM
Subject: Re: [uClinux-dev] Re: [uClinux-dev] problem of
execve("/bin/init"...)


> Try rolling back to uC-libc and choose sash as your shell. Also edit your
> etc/rc so that it does simpler commands first that you can verify
> e.g
>
> cat /etc/motd
> hostname uClinux
>
> Good luck and let me know how it goes.
>
>         --Steve
>
> ----- Original Message -----
> From: "Michael Varga" <mike.varga at cavium.com>
> To: <uclinux-dev at uclinux.org>; <stevelin at avalent.com>
> Sent: Friday, January 24, 2003 10:01 AM
> Subject: Re: [uClinux-dev] Re: [uClinux-dev] problem of
> execve("/bin/init"...)
>
>
> > Hi:
> >
> > Thanks for the help.
> >
> > What I have done
> > was add some printfs
> > to init and sh. The
> > "in init" messages show
> > that the execv of sh
> > within the do_rc() function
> > results in the two Unhandled fault
> > messages between "in init 3"
> > and "in init 4". Also the printfs
> > I added to sh are never displayed.
> >
> >
> >
> > *********************************************************************
> >
> >
> > fsload
> > uncompress... Free up zstream...
> > Succ: uncompress...
> > s3c2510# f go 40000
> > ## Starting application at 0x00040000 ...
> > Linux version 2.4.17-uC-pre5 (root at localhost.localdomain) (gcc version
> > 2.95.3 20010315 (release)) #46 Thu Jan 23 16:31:21 PST 2003
> > Processor: Samsung s3c2500(arm940T)s revision 1
> > Architecture: SMDK2510-AN
> > On node 0 totalpages: 8192
> >
> > *** bit_mapsize =0x2000, zones_size[0]=0x800, zones_size[1]=0x1800
> > *** bit_map =0x209040, lmem_map=0x189000
> > *** normal map/size=0x209040/ 0x1800, dma map/size =0x209340, 0x800
> > *** start of dma page =0x1800
> > *** first_usable_page_normal /dma= 0x209/ 0x1800
> > *** first_usable_page = 0x209, p= 0x209000
> > zone(2): 0 pages.
> > zone(1): 6144 pages.
> > zone(0): 2048 pages.
> > Kernel command line: root=/dev/rom0
> > Calibrating delay loop... 147.04 BogoMIPS
> > Memory: 32MB = 32MB total
> > Memory: 30680KB available (1025K code, 222K data, 60K init)
> > Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
> > Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
> > Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> > Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
> > Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
> > POSIX conformance testing by UNIFIX
> > S3C2510 PCI Host Controller Initializing...
> > External Clock is used !!!
> > Found 00:00 [144d/a510] 000600 00
> > Fixups for bus 00
> > PCI: bus0: Fast back to back transfers enabled
> > got res[2000000:20000ff] for resource 2 of PCI device 144d:a510
> > got res[0:1ffffff] for resource 0 of PCI device 144d:a510
> > got res[2000000:20001ff] for resource 1 of PCI device 144d:a510
> > Linux NET4.0 for Linux 2.4
> > Based upon Swansea University Computer Society NET3.039
> > Initializing RT netlink socket
> > Initializing S3C2510 buffer pool for DMA workaround
> > Starting kswapd
> > S3C2510X Serial I/O driver. Version 2.5.23 <oleks at arcturusnetworks.com>
> > ttyS0: at 0xf0060000 (IRQs: Tx=11 Rx=12) is a builtin Console UART
> > ttyS1: at 0xf0070000 (IRQs: Tx=07 Rx=08) is a builtin High-Speed UART
> > ttyS2: at 0xf0080000 (IRQs: Tx=09 Rx=10) is a builtin High-Speed UART
> > block: 64 slots per queue, batch=16
> > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> > s3c2510.c: v$Revision: 1.2 $ $Date: 2002/11/13 10:55:31 $ Ted Ma
> > (mated at sympatico.ca)
> >
> > eth0: S3c2510-1 found at f00c0000, 00.09.30.28.12.24.
> >
> >
> > ***** FrameDescArea =0x1ff1000
> >
> > SetupTxFDs-for eth0, First buff 1ff2004, Last 1ff23fc
> > SetupRxFDs-for eth0
> >
> > eth1: S3c2510-0 found at f00a0000, 00.09.30.28.12.22.
> >
> >
> > ***** FrameDescArea =0x1ff1000
> >
> > SetupTxFDs-for eth1, First buff 1ff2404, Last 1ff27fc
> > SetupRxFDs-for eth1
> > Blkmem copyright 1998,1999 D. Jeff Dionne
> > Blkmem copyright 1998 Kenneth Albanowski
> > Blkmem 1 disk images:
> > 0: 80020000-801E63FF [VIRTUAL 80020000-801E63FF] (RO)
> > loop: loaded (max 8 devices)
> > NET4: Linux TCP/IP 1.0 for NET4.0
> > IP Protocols: ICMP, UDP, TCP
> > IP: routing cache hash table of 512 buckets, 4Kbytes
> > TCP: Hash tables configured (established 2048 bind 2048)
> > IPv4 over IPv4 tunneling driver
> > ip_conntrack (256 buckets, 2048 max)
> > ip_tables: (c)2000 Netfilter core team
> > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> > NET4: Ethernet Bridge 008 for NET4.0
> > VFS: Mounted root (cramfs filesystem) readonly.
> > Starting init
> > Starting /bin/init
> > in init 1
> > in init 2
> > in init 3
> > do_rc 1
> > do_rc _PATH_BSHELL=/bin/sh,_PATH_RC=/etc/rc 2
> >
> > (none)
> >
> > ffffffff:Unhandled fault: external abort on linefetch (1761FF4) at
> > 0x0000936c
> > fault-common.c(97): start_code=0x262040, start_stack=0x27cf64)
> > Bus error
> >
> > ffffffff:Unhandled fault: external abort on linefetch (1761FF4) at
> > 0x0000936c
> > fault-common.c(97): start_code=0x262040, start_stack=0x27cf64)
> > Bus error
> >
> > S3C2510-PHY reset
> > S3C2510: **** We believe NO Cable is connected to MAC eth0 f00c0000
> > S3C2510-PHY reset
> > S3C2510-PHY: set for 10 Mbps,  HALF Duplex Mode.
> > S3C2510-PHY: Cable detected
> >
> > /proc/sys/net/ipv4/ipUnhandled fault: external abort on linefetch
> (17A1FF4)
> > at 0x002471e4_
> > fofault-common.c(97): start_code=0x240040, start_stack=0x251fb8)
> > rward: cannot create
> > in init 4
> > in init 5
> > in init 6
> > in init 7
> >
> >
> > ***************************************************************
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "Steve Lin" <stevelin at avalent.com>
> > To: <uclinux-dev at uclinux.org>
> > Sent: Thursday, January 23, 2003 8:54 PM
> > Subject: [uClinux-dev] Re: [uClinux-dev] problem of
execve("/bin/init"...)
> >
> >
> > > Hi Michael,
> > >
> > > Are you exec'ing /bin/init and then trying to load /bin/sh?
> > > Send a dump of your output with the DEBUG statements turned on.
> > > Check your cpsr/spsr. Are they turning into 0 when you enter user
> > > space?
> > >
> > >             --Steve
> > >
> > > ----- Original Message -----
> > > From: "Michael Varga" <mike.varga at cavium.com>
> > > To: <uclinux-dev at uclinux.org>
> > > Sent: Thursday, January 23, 2003 6:27 PM
> > > Subject: [uClinux-dev] Re: [uClinux-dev] Re: [uClinux-dev] Re:
> > [uClinux-dev]
> > > problem of execve("/bin/init"...)
> > >
> > >
> > > > I have tracked my
> > > > problem to /bin/sh.
> > > >
> > > > For some reason the
> > > > execv(/bin/sh)
> > > > call never enters
> > > > nor returns with an error.
> > > >
> > > > The first thing I do
> > > > in main() of sh1.c is a
> > > > printf(). But I never see
> > > > the printf(), I see all printf()s
> > > > on up to sh1.c, i.e. the ones
> > > > I inserted in init(), but
> > > > not the printf in main() of
> > > > sh1.c.
> > > >
> > > > I am sure it exists in
> > > > my romfs.
> > > >
> > > > > > Put debug statements in your init function in main.c.
> > > > > > You might also want to look at the start_thread function
> > > > > > in your /include/asm/proc/hardware.h to see if your user
> > > > > > stack is being set up properly and turn on #DEBUG in
> > > > > > /drivers/block/blkmem.c.
> > > >
> > > > Could this be a stack issue? What
> > > > should I look for?
> > > >
> > > > thanks.
> > > >
> > > > ----- Original Message -----
> > > > From: "Michael Varga" <mike.varga at cavium.com>
> > > > To: <uclinux-dev at uclinux.org>
> > > > Sent: Thursday, January 23, 2003 3:23 PM
> > > > Subject: [uClinux-dev] Re: [uClinux-dev] Re: [uClinux-dev] problem
of
> > > execve
> > > > ("/bin/init"...)
> > > >
> > > >
> > > > > I also have a similar
> > > > > problem with my board,
> > > > > SMDK2510 with a s3c2510
> > > > > arm processor from Samsung.
> > > > >
> > > > > I tried your ideas and put
> > > > > additional printks in the
> > > > > init function and found
> > > > > that it is hanging on the execve
> > > > > call. I also checked my file system
> > > > > and I do have a rc file. I also
> > > > > added, as the first command in the
> > > > > rc an echo, but the message is
> > > > > not printed.
> > > > >
> > > > > I defined the DEBUG symbol in
> > > > > blkmem.c, but no additional messages
> > > > > where printed.
> > > > >
> > > > > Armboot has an ls command
> > > > > that I use to list the
> > > > > contents of my romfs in
> > > > > flash. The contents are what I would expect.
> > > > > I created it by using mkcramfs and
> > > > > loaded it with tftp and copied it
> > > > > to flash with flwrite.
> > > > >
> > > > > I believe the problem is with
> > > > > my userland /bin/init. I
> > > > > am using a userland tar file
> > > > > from Samsung but with uClibc-0.9.16
> > > > > that I downloaded and built.
> > > > >
> > > > > Can anyone suggest some changes to
> > > > > uClibc that might solve the problem.
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Steve Lin" <stevelin at avalent.com>
> > > > > To: <uclinux-dev at uclinux.org>
> > > > > Sent: Thursday, January 23, 2003 12:31 PM
> > > > > Subject: [uClinux-dev] Re: [uClinux-dev] problem of execve
> > > > ("/bin/init"...)
> > > > >
> > > > >
> > > > > > Put debug statements in your init function in main.c.
> > > > > > You might also want to look at the start_thread function
> > > > > > in your /include/asm/proc/hardware.h to see if your user
> > > > > > stack is being set up properly and turn on #DEBUG in
> > > > > > /drivers/block/blkmem.c.
> > > > > >
> > > > > > This will help you trace down the problem. Also check that
> > > > > > you have an /etc/rc built into your romfs and that it has
> > > > > > simple entries e.g. hostname uClinux or cat /etc/motd.
> > > > > >
> > > > > > Your debug statements in the blkmem.c and start_thread should
> > > > > > help you see if your userspace is starting correctly & also
> > > > > > help you determine if the other binaries in your rc script
> > > > > > are getting parsed and loaded. Let me know how it goes.
> > > > > >
> > > > > >             --Steve
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: <zdw1025 at sina.com.cn>
> > > > > > To: <uclinux-dev at uclinux.org>
> > > > > > Sent: Monday, December 30, 2002 6:30 AM
> > > > > > Subject: [uClinux-dev] problem of execve("/bin/init"...)
> > > > > >
> > > > > >
> > > > > > >    hi,i try to run the uclinux kernel(2.0.39) and the romfs
from
> > > > sdram.
> > > > > My
> > > > > > development board use mcf5272.
> > > > > > > print of bootsequence is that:
> > > > > > > linux/coldfire(m5272)
> > > > > > > coldfire port done by greg ungerer,gery at snapgear.com
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ttyS0 at 0x10000100(irq=73) is a builtin coldfire uart
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > vfs:mounted root(romfs filesystem)readonly.
> > > > > > > __program hang up__
> > > > > > >
> > > > > > > it seems /bin/init hang up,how to resolve it?
> > > > > > > anyone give me some idea?
> > > > > > > thanks.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >         zdw1025 at sina.com.cn
> > > > > > >           2002-12-30
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > uClinux-dev mailing list
> > > > > > > uClinux-dev at uclinux.org
> > > > > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > > > > > This message was resent by uclinux-dev at uclinux.org
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > uClinux-dev mailing list
> > > > > > uClinux-dev at uclinux.org
> > > > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > > > > This message was resent by uclinux-dev at uclinux.org
> > > > >
> > > > > _______________________________________________
> > > > > uClinux-dev mailing list
> > > > > uClinux-dev at uclinux.org
> > > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > > > This message was resent by uclinux-dev at uclinux.org
> > > >
> > > > _______________________________________________
> > > > uClinux-dev mailing list
> > > > uClinux-dev at uclinux.org
> > > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > > This message was resent by uclinux-dev at uclinux.org
> > > >
> > >
> > > _______________________________________________
> > > uClinux-dev mailing list
> > > uClinux-dev at uclinux.org
> > > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > > This message was resent by uclinux-dev at uclinux.org
> >
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev at uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev at uclinux.org
> >
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org

More information about the uClinux-dev mailing list