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

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
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.


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.