Clock / Timebase / Bus Frequencies Help

[Richard Whitlock]

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.

surendranath.moilla at cmcltd.com 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 (nfk684 at ilec4411) (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, richw at netcomuk.co.uk 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 at ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>     
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
>