I built the GIT kernel exactly the same way you did, and I have exactly the
same problem when it boots up. Once it writes INIT, I have to press ENTER
many times, or it just hangs and does all the strange things you described.
I have reverted to using the montavista kernel which came with dvevm1.00.
Both montavista kernels that I have boot cleanly, compared to the GIT
kernel.
Does anyone know why this is happening?
Bobby
From: Andy Ngo <[EMAIL PROTECTED]>
To: "davinci-linux-open-source @linux.davincidsp.com"
<[email protected]>
Subject: GIT kernel boot up stalls at INIT: until I hit Enter several times
Date: Fri, 9 Mar 2007 05:23:52 -0800 (PST)
Hi,
I recently switched over from the Montavista Linux Pro edition to the GIT
kernel. After building the
kernel with the default configuration:
make ARCH=arm CROSS_COMPILE=arm_v5t_le- davinci_evm_dm644x_defconfig
make ARCH=arm CROSS_COMPILE=arm_v5t_le- uImage
I loaded the new kernel and am getting weird problems with the GIT kernel
booting up (as
seen on the serial terminal). It would boot up fine until it stalls at
INIT:
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on hda1, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing init memory: 100K
INIT:
at which point I have to manually press Enter several times to force it to
continue booting up to the
login prompt. If I just leave it alone it would take like 6 minutes before
I get the login prompt.
Even then I can't login because the input to the console doesn't seem to
respond
to what I type correctly. I would try to type "root" at the login prompt,
but it would just keep
on displaying another login prompt, with my attempt to enter "root" all
jumbled up. Really
weird. At this point, I gave up and just telnet into the board, which
works fine. FYI, the hard drive
filesystem contains that of the contents dvevm 1.10.
Anyone else has this problem with the GIT kernel booting up? Am I doing
something wrong?
By the way, with the GIT kernel, I was able to parse the MTD NOR JFFS2
partitions correctly:
physmap platform flash device: 01000000 at 02000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
NOR chip too large to fit in mapping. Attempting to cope...
Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming
top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code
brokenness.
Reducing visibility of 32768KiB chip to 16384KiB
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition information
Creating 4 MTD partitions on "physmap-flash.0":
0x00000000-0x00040000 : "bootloader"
0x00040000-0x00050000 : "params"
0x00050000-0x00250000 : "kernel"
0x00250000-0x01000000 : "filesystem"
I was then able to mount the 4th partition as a JFFS2 partition and put
stuff on it:
# mkdir /mnt/rootfs
# mount -t jffs2 -o noatime /dev/mtdblock3 /mnt/rootfs
Regards,
Andy
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_________________________________________________________________
Join the millions of Australians using Live Search. Try live.com.au
http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=740&referral=million&URL=http://live.com.au
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
