Hi Richard, Thanks for your response, i have fixed the problem. The problem was while U-boot is doing boardsetup it is filling incorrect frequencies which causes the problem.
Regards Surendra > Hi, > > Is it really hanging? > Or is it just sending console output somewhere else? > Try pinging the board after you think its hung. Can you ssh in and dmesg > to find out what went wrong? > I've had two problems similar to this recently. The first was that the > serial clock frequency was wrong in the dts file. > The second was schoolboy error when the console was handed over to ttyS1 > when I was plugged in to ttyS0. > If that all fails - put a scope on your serial port and see what its > really doing. > Good luck, > > > > > Richard. > > [EMAIL PROTECTED] wrote: >> Hi, >> >> I have a similar problem with custom MPC8360 board. >> I am able to boot Linux with the mpc836x_dts.dtb provided by freescale. >> but when use dtb customised for my board i am unable to boot Linux. >> It is hanging after the console handover to real console from boot >> console. >> >> I am filling all the frequencies properly, can someone help me to fix >> this >> Where to set the baud rate in dts file. >> >> Here is the log: >> >> >> => tftp $loadaddr /nfk684/vpm_test/uImage >> Using FSL UEC0 device >> TFTP from server 192.168.0.2; our IP address is 192.168.0.100 >> Filename '/nfk684/vpm_test/uImage'. >> Load address: 0x200000 >> Loading: >> ################################################################# >> ########## >> done >> Bytes transferred = 1095689 (10b809 hex) >> => tftp $fdtaddr /nfk684/vpm_test/mpc8360_vpm.dtb >> Using FSL UEC0 device >> TFTP from server 192.168.0.2; our IP address is 192.168.0.100 >> Filename '/nfk684/vpm_test/mpc8360_vpm.dtb'. >> Load address: 0x400000 >> Loading: # >> done >> Bytes transferred = 12288 (3000 hex) >> => bootm $loadaddr - $fdtaddr >> ## Booting image at 00200000 ... >> Image Name: Linux-2.6.22 >> Image Type: PowerPC Linux Kernel Image (gzip compressed) >> Data Size: 1095625 Bytes = 1 MB >> Load Address: 00000000 >> Entry Point: 00000000 >> Verifying Checksum ... OK >> Uncompressing Kernel Image ... OK >> Booting using the fdt at 0x400000 >> Probing machine type >> Using MPC8360 VPM machine description >> Linux version 2.6.22 ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 >> 4.0.0)) >> #17 Fri Aug 15 16:13:41 CDT 2008 >> setup_arch: bootmem >> mpc8360_vpm_setup_arch() >> Bad clock source for time stamp 1 >> Bad clock source for time stamp 2 >> arch: exit >> Zone PFN ranges: >> DMA 0 -> 65536 >> Normal 65536 -> 65536 >> early_node_map[1] active PFN ranges >> 0: 0 -> 65536 >> Built 1 zonelists. Total pages: 65024 >> Kernel command line: root=/dev/ram rw console=ttyS1,115200 >> IPIC (128 IRQ sources) at fdefc700 >> QEIC (64 IRQ sources) at fdefb080 >> PID hash table entries: 1024 (order: 10, 4096 bytes) >> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) >> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) >> Memory: 257280k/262144k available (2152k kernel code, 4624k reserved, >> 96k >> data, >> 80k bss, 128k init) >> Mount-cache hash table entries: 512 >> NET: Registered protocol family 16 >> >> Generic PHY: Registered new driver >> SCSI subsystem initialized >> NET: Registered protocol family 2 >> IP route cache hash table entries: 2048 (order: 1, 8192 bytes) >> TCP established hash table entries: 8192 (order: 4, 65536 bytes) >> TCP bind hash table entries: 8192 (order: 3, 32768 bytes) >> TCP: Hash tables configured (established 8192 bind 8192) >> TCP reno registered >> JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. >> io scheduler noop registered >> io scheduler anticipatory registered (default) >> io scheduler deadline registered >> io scheduler cfq registered >> Generic RTC Driver v1.07 >> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing >> disabled >> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A >> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A >> console handover: boot [udbg0] -> real [ttyS1] >> >> Regards >> Surendra >> >> >> >>> On Mon, Aug 18, 2008 at 07:52:12AM -0400, [EMAIL PROTECTED] wrote: >>> >>>> We've got an 8347 based board very similar to the A&M asp8347. Core >>>> clock >>>> is 400MHz. Bus clock is 266666666Hz. >>>> According to the data sheet for the 8347, the decrementer clock runs >>>> at >>>> a >>>> quarter of the rate of the bus clock. I have two questions: >>>> In arch/powerpc/boot/redboot-83xx.c, the timebase clock is passed to >>>> dt_fixup_cpu_clocks() as bi_busfreq / 16. If I leave it like this, my >>>> system clock runs approximately 4 times too fast. >>>> Can anyone point me in the direction of an explanation for the div by >>>> 16 >>>> rather than 4? >>>> >>> It's a bug, which I pointed out here: >>> http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058704.html >>> >>> >>>> If I change the call to dt_fixup_cpu_clocks so that bi_busfreq/4 is >>>> passed >>>> in, then the clock runs more accurately. However, its still not >>>> correct. >>>> This gives a decrementer frequency of 66666666Hz, but if I hard code >>>> the >>>> value to 66000000Hz, the clock runs accurately. >>>> Can anyone shed any light on why the value passed in by the boot >>>> loader >>>> (redboot) seems to be inaccurate. >>>> >>> Redboot probably has the wrong crystal frequency hardcoded. >>> >>> -Scott >>> _______________________________________________ >>> Linuxppc-dev mailing list >>> Linuxppc-dev@ozlabs.org >>> https://ozlabs.org/mailman/listinfo/linuxppc-dev >>> >>> >> >> >> _______________________________________________ >> Linuxppc-dev mailing list >> Linuxppc-dev@ozlabs.org >> https://ozlabs.org/mailman/listinfo/linuxppc-dev >> >> >> > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
