[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MCM boot-up problems - possible filesystem or flash issues?



I just checked. The console device seems to be pointing to ttyS0 as shown
below.

lrwxrwxrwx    1 mahmut   mahmut          5 Dec 12 17:39 console -> ttyS0

I had also tried the arp+ping method to see if the board is working, but it
did not respond to the ping's. So I think that it is hanging there..

Regards

Mahmut


> -----Original Message-----
> From: Magnus Mårtensson [mailto:magnus.martensson@xxxxxxx.com]
> Sent: Thursday, 12 December 2002 19:41
> To: 'Fettahlioglu, Mahmut'; dev-etrax
> Subject: RE: MCM boot-up problems - possible filesystem or 
> flash issues?
> 
> 
> Hi.
> Are you sure that your /dev/console pointing on the correct 
> serial port? Check it in 
> /any/dir/axis/e100lx_mcm/target/cris-axis-linux-gnu/dev/ .
> 
> Regards
> /Magnus
> 
> -----Original Message-----
> From: Fettahlioglu, Mahmut [mailto:Mahmut.Fettahlioglu@xxxxxxx.au]
> Sent: den 12 december 2002 09:31
> To: Axis development List (E-mail)
> Subject: RE: MCM boot-up problems - possible filesystem or 
> flash issues?
> 
> 
> > Can you send us the output from the debug port?
> 
> The kernel sends the following to the debug port (serial port 0):
> 
> Uncompressing Linux...
> Done. Now booting the kernel.
> Linux version 2.4.19 (mahmut@xxxxxxx.96 20000427
> (experimental)) #5 Wed Dec 11 16:36:19 EST 2002
> Setting up paging and the MMU.
> On node 0 totalpages: 1024
> zone(0): 1024 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Linux/CRIS port on ETRAX 100LX (c) 2001, 2002 Axis Communications AB
> Kernel command line: root=/dev/mtdblock3
> Enabling watchdog...
> Calibrating delay loop... 99.73 BogoMIPS
> Memory: 7032k/8192k available (701k kernel code, 1160k 
> reserved, 191k data,
> 32k init)
> kmem_create: Forcing size word alignment - mm_struct
> kmem_create: Forcing size word alignment - filp
> Dentry cache hash table entries: 1024 (order: 0, 8192 bytes)
> Inode cache hash table entries: 1024 (order: 0,8192 bytes)
> kmem_create: Forcing size word alignment - inode_cache
> Mount-cache hash table entries: 1024 (order: 0, 8192 bytes)
> kmem_create: Forcing size word alignment - bdev_cache
> kmem_create: Forcing size word alignment - cdev_cache
> Buffer-cache hash table entries: 2048 (order: 0, 8192 bytes)
> Page-cache hash table entries: 2048 (order: 0, 8192 bytes)
> POSIX conformance testing by UNIFIX
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> kmem_create: Forcing size word alignment - sock
> Initializing RT netlink socket
> Starting kswapd
> kmem_create: Forcing size word alignment - file lock cache
> JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
> kmem_create: Forcing size word alignment - jffs_node
> kmem_create: Forcing size word alignment - blkdev_requests
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> ETRAX 100LX 10/100MBit ethernet v2.0 (c) 2000-2001 Axis 
> Communications AB
> eth0 initialized
> eth0: changed MAC to 00:40:8C:CD:00:00
> ETRAX 100LX serial-driver 1.40 $, (c) 2000-2002 Axis Communications AB
> ttyS0 at 0xb0000060 is a builtin UART with DMA
> fast_timer_init()
> cse0: Probing a 0x04000000 bytes large window at 0xe0000000.
> cse0: Probing for AMD compatible flash...
> cse0: Found 1 x 2MiB Atmel AT49xV16x at 0x0
> cse1: Probing a 0x04000000 bytes large window at 0xe4000000.
> cse1: Probing for AMD compatible flash...
> cse1: Found no AMD compatible device at location zero
> CFI: Found no cse1 device at location zero
> cse0: 0x00200000 bytes of flash memory.
> Found a valid partition table at 0xf001000a-0xf0010056.
> /dev/flash1 at 0x00010000, size 0x001a0000
> /dev/flash2 at 0x001b0000, size 0x00050000
> Adding readonly flash partition for romfs image:
> /dev/flash3 at 0x0007ca1f, size 0x000f6000
> Creating 4 MTD partitions on "cse0":
> 0x00000000-0x00010000 : "part0"
> 0x00010000-0x001b0000 : "part1"
> 0x001b0000-0x00200000 : "part2"
> 0x0007ca1f-0x00172a1f : "romfs"
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> kmem_create: Forcing size word alignment - ip_dst_cache
> IP: routing cache hash table of 1024 buckets, 8Kbytes
> TCP: Hash tables configured (established 1024 bind 1024)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> VFS: Mounted root (cramfs filesystem) readonly.
> Freeing unused kernel memory: 32k freed
> 
> And it hangs after that. I had a look in the kernel source and it was
> looking like the kernel was hanging after calling execve() in 
> the init()
> function (os/linux/init/main.c:545). I put some debug 
> statements just before
> the kernel is trying to execute the "init" executable from one of the
> possible locations. This resulted in the following lines 
> being appended to
> the debug output:
> 
> Trying to execute /sbin/init
> Trying to execute /etc/init
> Trying to execute /bin/init
> 
> And it hangs after that. It seems like the kernel hangs after it calls
> execve() for "/bin/init". I then added some debug statements 
> to the init
> executable so that they should have been printed when the init process
> starts but they never get printed. BTW, I have determined the 
> reason for the
> other problem (not being able to boot in normal bootstrap 
> mode), and I think
> that the two problems can be linked as explained below..
> 
> 
> > >process. It just hangs without printing anything to the 
> > serial port at all.
> > 
> > Two possible reasons:
> > 
> > 1. e100boot executes its own SDRAM initialization sequence 
> > and the code
> >    then does the same. If your arch/cris/lib/dram_init.S is 
> incorrect
> >    the SDRAMs would not be initialized correctly and the startup
> >    would fail. As far as I can see the file supplied in 2.4.19 is
> >    correct. Did you build your 2.4.19 tree from scratch or did you
> >    upgrade an existing tree?
> > 2. The BS0 pin indicates the flash buswidth for ETRAX. If 
> that pin is
> >    high the ETRAX would try to access the flash as a 32 bit flash.
> 
> I found why this happens as explained below... I built the development
> environment from fresh e100lx_mcm-R1_0_0 and linux kernel 
> 2.4.19 tarballs
> and built everything from scratch.
> 
> > >0x00000000 : 0x20303034 0x20202020 0x20202020 0x33202020
> > >0x00000010 : 0x33323834 0x35343239 0xbea09301 0xffff0930
> > This is not correct. You expect the same data as in the fimage
> > file i.e. 050f 25f0 etc. When doing memdumps you should dump
> > uncached addresses (i.e. start at 0x80000000). This is because
> > the boot loader runs from cache and if you dump cached memory 
> > you may replace the code that prints the memory from the cache.
> 
> Yes, the flash contents after a flash write were not correct. 
> I initially
> realized that only the first 28 bytes of the flash contents 
> were incorrect,
> the rest was ok. Further investigation showed that while the client
> bootloader was loading the flash image file fimage (which is 
> 0x200018 bytes
> long) to the RAM starting at address 0xc0004000, the memory 
> was wrapping
> around after 0x200000 bytes and the last 28 bytes were 
> overwriting the start
> of the buffer!!
> 
> This can be observed from the following memory dumps. The 
> following dump is
> generated by the following command while network- booting the MCM:
> etrax100boot --setreg b0000000 000095f8 --setreg b0000004 
> 00000104 --setreg
> b000000c 00601515 --setreg b0000008 8000c002 --pause 20000 
> --setreg b0000008
> 8000c602 --setreg b0000008 8000c002 --setreg +0 7 --label 
> label1 --setreg
> b0000008 8000c402 --setreg b0000008 8000c002 --loop +0 label1 --setreg
> b0000008 8060c202 --setreg b0000008 8000c002 --setreg 
> b0000008 80008002
> --setreg b0000030 0000ff00 --setreg b0000038 0000ff00 --file 
> fimage c0004000
> --memdump c0004000 c00040ff --memdump c0204000 c02040ff
> 
> The output is:
> ---------------------------------------
> Using internal boot loader: INTERNAL_NW - Network boot (default).
> Starting boot...
> 
> 
> Device ID = 0xffffabb3
> This bootloader was built by mahmut on Thu Dec 12 17:37:21 EST 2002.
> Checksum of bootloader is 0x000a96cf
> Waiting for load info.
> Checksum of file is 0x00002323
> Got load info.
> SET_REGISTER
> 0xb0000000
> 0x000095f8
> SET_REGISTER
> 0xb0000004
> 0x00000104
> SET_REGISTER
> 0xb000000c
> 0x00601515
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> PAUSE_LOOP
> 0x00020000
> SET_REGISTER
> 0xb0000008
> 0x8000c602
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> SET_REGISTER
> 0x38001f00
> 0x00000007
> SET_REGISTER
> 0xb0000008
> 0x8000c402
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> LOOP
> 0x38001f00
> 0x38001f5c
> SET_REGISTER
> 0xb0000008
> 0x8000c402
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> LOOP
> 0x38001f00
> 0x38001f5c
> SET_REGISTER
> 0xb0000008
> 0x8000c402
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> LOOP
> 0x38001f00
> 0x38001f5c
> SET_REGISTER
> 0xb0000008
> 0x8000c402
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> LOOP
> 0x38001f00
> 0x38001f5c
> SET_REGISTER
> 0xb0000008
> 0x8000c402
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> LOOP
> 0x38001f00
> 0x38001f5c
> SET_REGISTER
> 0xb0000008
> 0x8000c402
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> LOOP
> 0x38001f00
> 0x38001f5c
> SET_REGISTER
> 0xb0000008
> 0x8000c402
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> LOOP
> 0x38001f00
> 0x38001f5c
> SET_REGISTER
> 0xb0000008
> 0x8000c402
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> LOOP
> 0x38001f00
> 0x38001f5c
> SET_REGISTER
> 0xb0000008
> 0x8060c202
> SET_REGISTER
> 0xb0000008
> 0x8000c002
> SET_REGISTER
> 0xb0000008
> 0x80008002
> SET_REGISTER
> 0xb0000030
> 0x0000ff00
> SET_REGISTER
> 0xb0000038
> 0x0000ff00
> PACKET_INFO
> 0xc0004000
> 0x00200018
> Checksum of file is 0x14c110f1
> MEM_DUMP
> 0xc0004000
> 0xc00040ff
> 0xc0004000 : 0x20303034 0x20202020 0x20202020 0x33202020
> 0xc0004010 : 0x39313834 0x37313736 0xbf55beda 0xffff0930
> 0xc0004020 : 0x0e6fffff 0x00000003 0x00980d7f 0x0be0b000
> 0xc0004030 : 0x95f80e6f 0x0d7f0000 0xb0000000 0x0e6f0be0
> 0xc0004040 : 0x00000104 0x00040d7f 0x0be0b000 0x0e6f6242
> 0xc0004050 : 0x00601515 0x000c0d7f 0x0be0b000 0x80022e6f
> 0xc0004060 : 0x2f2f8060 0x00ff0000 0x23f02056 0x00402e6f
> 0xc0004070 : 0x1e6f0000 0x80608002 0x1f2f3661 0x00000003
> 0xc0004080 : 0x10003f2f 0x30160000 0x1eef050f 0x00000000
> 0xc0004090 : 0x050f301c 0x00202f6f 0xe0120000 0x1eef050f
> 0xc00040a0 : 0x00000001 0x050f3008 0x00202f6f 0x1e6f0000
> 0xc00040b0 : 0x00601515 0x00001f2f 0x20040080 0x23e1050f
> 0xc00040c0 : 0x80021e6f 0x1f2f8060 0x8000f9ff 0x00001f6f
> 0xc00040d0 : 0x56618000 0xc0001f6f 0x23d00000 0x0d7f1762
> 0xc00040e0 : 0xb0000008 0x2e6f1be1 0x00002710 0x228120ff
> 0xc00040f0 : 0x012e2e6f 0x3e6f0000 0x00000142 0x4e428674
> MEM_DUMP
> 0xc0204000
> 0xc02040ff
> 0xc0204000 : 0x20303034 0x20202020 0x20202020 0x33202020
> 0xc0204010 : 0x39313834 0x37313736 0xbf55beda 0xffff0930
> 0xc0204020 : 0x0e6fffff 0x00000003 0x00980d7f 0x0be0b000
> 0xc0204030 : 0x95f80e6f 0x0d7f0000 0xb0000000 0x0e6f0be0
> 0xc0204040 : 0x00000104 0x00040d7f 0x0be0b000 0x0e6f6242
> 0xc0204050 : 0x00601515 0x000c0d7f 0x0be0b000 0x80022e6f
> 0xc0204060 : 0x2f2f8060 0x00ff0000 0x23f02056 0x00402e6f
> 0xc0204070 : 0x1e6f0000 0x80608002 0x1f2f3661 0x00000003
> 0xc0204080 : 0x10003f2f 0x30160000 0x1eef050f 0x00000000
> 0xc0204090 : 0x050f301c 0x00202f6f 0xe0120000 0x1eef050f
> 0xc02040a0 : 0x00000001 0x050f3008 0x00202f6f 0x1e6f0000
> 0xc02040b0 : 0x00601515 0x00001f2f 0x20040080 0x23e1050f
> 0xc02040c0 : 0x80021e6f 0x1f2f8060 0x8000f9ff 0x00001f6f
> 0xc02040d0 : 0x56618000 0xc0001f6f 0x23d00000 0x0d7f1762
> 0xc02040e0 : 0xb0000008 0x2e6f1be1 0x00002710 0x228120ff
> 0xc02040f0 : 0x012e2e6f 0x3e6f0000 0x00000142 0x4e428674
> END
> Exiting with code 0
> ---------------------------------------
> 
> I tried the same thing with the developer board. I used the following
> command to generate the dump:
> etrax100boot --setreg b0000000 000095f8 --setreg b0000004 
> 00000104 --setreg
> b000000c 1a200040 --setreg b0000008 00005611 --setreg 
> b0000030 00001df0
> --setreg b0000038 00001ef3 --bootfile DBG2 --file fimage 
> c0004000 --memdump
> c0004000 c00040ff --memdump c0204000 c02040ff
> 
> From the serial port of the developer board, I got the 
> following output:
> ---------------------------------------
> SET_REGISTER
> 0xB0000038
> 0x00001EF3
> PACKET_INFO
> 0xC0004000
> 0x00200018
> Checksum of file is 0x15CE690A
> MEM_DUMP
> 0xC0004000
> 0xC00040FF
> 0xC0004000 : 0x25F0050F 0x000A0D3F 0x0D7F0000 0x0000001E
> 0xC0004010 : 0x0EEF0A60 0xFFFFFFFF 0x050F3008 0xFFFF0930
> 0xC0004020 : 0x0E6FFFFF 0x00000003 0x00980D7F 0x0BE0B000
> 0xC0004030 : 0x95F80E6F 0x0D7F0000 0xB0000000 0x0E6F0BE0
> 0xC0004040 : 0x00000104 0x00040D7F 0x0BE0B000 0x00400E6F
> 0xC0004050 : 0x0D7F1A20 0xB000000C 0x0E6F0BE0 0x00005611
> 0xC0004060 : 0x00080D7F 0x0BE0B000 0x00003E6F 0x0A630001
> 0xC0004070 : 0x050F0EEF 0x2066F025 0x320A050F 0x0EDF0E53
> 0xC0004080 : 0x205ABEEF 0x2C53050F 0x821C8662 0x16634E63
> 0xC0004090 : 0x01A2BD3F 0x46E00000 0x050F2044 0x1E63727F
> 0xC00040A0 : 0x050F200C 0x2E631668 0xE00C26A8 0x1EEF050F
> 0xC00040B0 : 0xFFFFFFFF 0x2E6330D4 0x4E635E63 0x43903210
> 0xC00040C0 : 0x050F60DD 0x60044391 0x7661050F 0x00001E2F
> 0xC00040D0 : 0xBD3F0001 0x000001A2 0x30C356E0 0x0E4F050F
> 0xC00040E0 : 0x0D7F001D 0xB0000031 0x0E4F0BC0 0x0D7F00F0
> 0xC00040F0 : 0xB0000030 0x0E4F0BC0 0x0D7F001E 0xB0000039
> MEM_DUMP
> 0xC0204000
> 0xC02040FF
> 0xC0204000 : 0x20303034 0x20202020 0x20202020 0x33202020
> 0xC0204010 : 0x34383536 0x39333138 0x72E4091A 0xB07BB3B5
> 0xC0204020 : 0x602C832D 0xBCE9B8F9 0xD915BB3B 0x2E0BEC34
> 0xC0204030 : 0xB205418B 0xA95B1698 0x14627B04 0x2526599D
> 0xC0204040 : 0x88FCF992 0xF8D33918 0xBA7CC964 0x93DFCF80
> 0xC0204050 : 0x74F87BCC 0x13A44775 0x2EF3DCD5 0xB9A2CE6B
> 0xC0204060 : 0x5878BBE6 0xB60C7927 0xD07493A5 0x571970B1
> 0xC0204070 : 0x58FE802A 0x6F292694 0x04DCBD38 0x9620BC90
> 0xC0204080 : 0x477B38C8 0xABB51FC7 0xEA158875 0x60E4D499
> 0xC0204090 : 0xE7825CFC 0x448D7F7A 0xE7906E76 0x48191D65
> 0xC02040A0 : 0xBD006812 0x1524D0CA 0x6E767DD8 0x968ED082
> 0xC02040B0 : 0xD1156F60 0xA7DBDE12 0xE125DDF5 0x9824DA07
> 0xC02040C0 : 0xC5321BC1 0x1666387F 0xBF131C37 0x3398EBEF
> 0xC02040D0 : 0xB780B931 0x919C4A4E 0xB4296D06 0x5A85AF82
> 0xC02040E0 : 0xF7ACEE16 0x13DD0D31 0xFCEF73E5 0xBDE7BBDC
> 0xC02040F0 : 0xF3E51354 0x0AFA6435 0xFEA1160F 0xB369D8C7
> END
> ---------------------------------------
> 
> This shows that the memory addresses 0xc0004000 and 
> 0xc0204000 in the MCM
> chip are actually pointing to the same physical memory while on the
> developer board they are not.
> 
> To experiment further, I removed the last 28 bytes from the 
> fimage file, and
> I then downloaded and flashed this image file to the MCM (the 
> last 28 bytes
> were only some FF's, device id and file checksum, which did not break
> anything if removed). Now, when I print the flash contents at 
> 0x80000000, I
> get exactly the same contents with the fimage file. With that flash
> contents, the MCM can now boot in normal bootstrap mode as 
> well. Of course,
> it also does not get through the problem of cannot starting the "init"
> process.
> 
> I think that "the problem of not being able to start the 
> 'init' process" is
> possibly linked with this situation. If the kernel expects a 
> separate memory
> at the 0xc0204000 address but this actually wraps around and 
> overwrites the
> memory at 0xc0004000 when accessed, it is normal for the 
> machine to hang
> when accessing this memory.
> 
> Is it normal for all MCMs to have this sort of memory 
> configuration, or is
> it peculiar to our board only? Our hardware engineer has told 
> me that he has
> done exactly the same thing as the serial-device example in the axis
> web-site. We are not using any external RAM or flash as in 
> that example. Do
> you think we need to change something in our hardware 
> connections, or will
> changing some settings in the software fix our problem (such 
> as the base
> memory address to copy the flash image, and contigious memory 
> blocks for the
> kernel to use)?
> 
> Regards,
> 
> Mahmut
> 
> > -----Original Message-----
> > From: Mikael Starvik [mailto:mikael.starvik@xxxxxxx.com]
> > Sent: Wednesday, 11 December 2002 18:14
> > To: 'Fettahlioglu, Mahmut'; dev-etrax
> > Cc: 'fredrik.norrman@xxxxxxx.com'
> > Subject: RE: MCM boot-up problems - possible filesystem or 
> > flash issues?
> > 
> > 
> > Hi,
> > 
> > Great that you have come this far!
> > 
> > > R_SDRAM_CONFIG = 00601515
> > > R_SDRAM_TIMING = 80608002 (Changing this to 80008002 as 
> > suggested in some
> > >emails in the list did not work).
> > 
> > Looks correct 
> > 
> > >a) the file is present in the filesystem TOC but its 
> > contents are invalid
> > >b) the system hangs when trying to access the flash, the 
> > partition, or the
> > >filesystem driver
> > 
> > Can you send us the output from the debug port?
> > 
> > >A network boot using the flashitall script works well, 
> > 
> > The first time you should run boot_linux -F to write the rescue 
> > partition.
> > 
> > >2- When we are not network booting, the system does not even 
> > do the above
> > >process. It just hangs without printing anything to the 
> > serial port at all.
> > 
> > Two possible reasons:
> > 
> > 1. e100boot executes its own SDRAM initialization sequence 
> > and the code
> >    then does the same. If your arch/cris/lib/dram_init.S is 
> incorrect
> >    the SDRAMs would not be initialized correctly and the startup
> >    would fail. As far as I can see the file supplied in 2.4.19 is
> >    correct. Did you build your 2.4.19 tree from scratch or did you
> >    upgrade an existing tree?
> > 2. The BS0 pin indicates the flash buswidth for ETRAX. If 
> that pin is
> >    high the ETRAX would try to access the flash as a 32 bit flash.
> > 
> > 
> > Bit 31 indicates that the cache shouldn't be used. This means
> > that 0x80000000 and 0x00000000 is the same except that the cache
> > is used for 0x00000000. 
> > 
> > >0x00000000 : 0x20303034 0x20202020 0x20202020 0x33202020
> > >0x00000010 : 0x33323834 0x35343239 0xbea09301 0xffff0930
> > 
> > This is not correct. You expect the same data as in the fimage
> > file i.e. 050f 25f0 etc. When doing memdumps you should dump
> > uncached addresses (i.e. start at 0x80000000). This is because
> > the boot loader runs from cache and if you dump cached memory 
> > you may replace the code that prints the memory from the cache.
> > 
> > Good luck
> > /Mikael
> > 
> > -----Original Message-----
> > From: owner-dev-etrax@xxxxxxx.com]On">mailto:owner-dev-etrax@xxxxxxx.com]On
> > Behalf Of Fettahlioglu, Mahmut
> > Sent: Wednesday, December 11, 2002 7:50 AM
> > To: dev-etrax
> > Cc: 'fredrik.norrman@xxxxxxx.com'
> > Subject: MCM boot-up problems - possible filesystem or flash issues?
> > 
> > 
> > We have recently puchased a number of MCM chips, and built 
> a board as
> > suggested in the reference design. Now we are in a stage 
> > where we can test
> > their boot-up and operation, however we are having some 
> > problems during the
> > bootup process. I have followed the "Linux installation to 
> > MCM" document
> > step-by-step in order not to cause any problems, so I'm using the
> > e100lx_mcm-R1_0_0 and linux kernel 2.4.19 without making any 
> > modifications
> > to their configurations. We are not using any external RAM or 
> > flash, so I
> > did not have to modify the related kernel configuration. So, 
> > I'm using 
> >  R_SDRAM_CONFIG = 00601515
> >  R_SDRAM_TIMING = 80608002 (Changing this to 80008002 as 
> > suggested in some
> > emails in the list did not work).
> > 
> > 1- A network boot using the flashitall script works well, and 
> > we can see
> > that the new flash contents being written and the CPU jumping 
> > to 0x00000000.
> > After this, the serial port output from the MCM works ok, and 
> > the kernel
> > initializes without problems until it comes to the stage of 
> > executing the
> > "init" process. After putting some extra debug statements to 
> > the relevant
> > code, I've seen the kernel executing /bin/init, and the 
> > system hangs there
> > afterwards. I've put a debug statement to the beginning of 
> > main() in the
> > init process, and it never gets printed out. Possible reasons 
> > I can think of
> > are:
> > a) the file is present in the filesystem TOC but its contents 
> > are invalid
> > b) the system hangs when trying to access the flash, the 
> > partition, or the
> > filesystem driver
> > 
> > 2- When we are not network booting, the system does not even 
> > do the above
> > process. It just hangs without printing anything to the 
> > serial port at all.
> > I've read that during normal bootup, the CPU jumps to 0x80000002 and
> > executes instructions from there. When I've used e100boot to 
> > have the CPU
> > jump to  0x80000002, it hangs there either. When I use 
> > e100boot to have the
> > CPU jump to  0x00000000, I get the results of (1). I did a 
> > memdump using
> > e100boot on both these locations, and saw that 0x80000000 and 
> > 0x00000000
> > contain the same data, they are probably mapped to the same 
> > physical memory.
> > So the only difference between jumping to the two different 
> > addresses is
> > that the instruction at 0x0 is not executed when the CPU jumps to
> > 0x80000002. This address contains the instruction "2030" as 
> > shown below:
> > 
> > 0x00000000 : 0x20303034 0x20202020 0x20202020 0x33202020
> > 0x00000010 : 0x33323834 0x35343239 0xbea09301 0xffff0930
> > 0x00000020 : 0x0e6fffff 0x00000003 0x00980d7f 0x0be0b000
> > 0x00000030 : 0x95f80e6f 0x0d7f0000 0xb0000000 0x0e6f0be0
> > 0x00000040 : 0x00000104 0x00040d7f 0x0be0b000 0x0e6f6242
> > 0x00000050 : 0x00601515 0x000c0d7f 0x0be0b000 0x80022e6f
> > 0x00000060 : 0x2f2f8060 0x00ff0000 0x23f02056 0x00402e6f
> > 0x00000070 : 0x1e6f0000 0x80608002 0x1f2f3661 0x00000003
> > 0x00000080 : 0x10003f2f 0x30160000 0x1eef050f 0x00000000
> > 0x00000090 : 0x050f301c 0x00202f6f 0xe0120000 0x1eef050f
> > 0x000000a0 : 0x00000001 0x050f3008 0x00202f6f 0x1e6f0000
> > 0x000000b0 : 0x00601515 0x00001f2f 0x20040080 0x23e1050f
> > 0x000000c0 : 0x80021e6f 0x1f2f8060 0x8000f9ff 0x00001f6f
> > 0x000000d0 : 0x56618000 0xc0001f6f 0x23d00000 0x0d7f1762
> > 0x000000e0 : 0xb0000008 0x2e6f1be1 0x00002710 0x228120ff
> > 0x000000f0 : 0x012e2e6f 0x3e6f0000 0x00000142 0x4e428674
> > 
> > I was assuming this should probably be a NOP operation, but I 
> > have yet to
> > investigate this as well.
> > 
> > Did anyone experience a similar situation? I would appreciate any
> > suggestions on what's happening.
> > 
> > Regards,
> > 
> > Mahmut
> >  
> > --------------------------------------------------------------
> > --------------
> > ---------------------
> > Mahmut Fettahlioglu
> > Senior Software Engineer
> > 
> > Open Access Pty Ltd
> > PO Box 301
> > Crows Nest NSW 1585
> >  
> > Phone		02 9978 7009
> > Fax		02 9978 7099
> > Email		<mahmut.fettahlioglu@xxxxxxx.au>
> > --------------------------------------------------------------
> > --------------
> > ---------------------
> > This email is intended only for the use of the individual or entity
> > named above and may contain information that is confidential and
> > privileged. If you are not the intended recipient, you are hereby
> > notified that any dissemination, distribution or copying of this
> > email is strictly prohibited. If you have received this email in
> > error, please notify us immediately by return email or telephone 
> > 02 9978 7009 and destroy the original message.
> > 
>