Clock / Timebase / Bus Frequencies Help

Clock / Timebase / Bus Frequencies Help

[richw]

We've got an 8347 based board very similar to the A&M asp8347=2E Core cloc=
k
is 400MHz=2E Bus clock is 266666666Hz=2E
According to the data sheet for the 8347, the decrementer clock runs at a
quarter of the rate of the bus clock=2E I have two questions:
In arch/powerpc/boot/redboot-83xx=2Ec, the timebase clock is passed to
dt=5Ffixup=5Fcpu=5Fclocks() as bi=5Fbusfreq / 16=2E If I leave it like thi=
s, my
system clock runs approximately 4 times too fast=2E=20
Can anyone point me in the direction of an explanation for the div by 16
rather than 4=3F

If I change the call to dt=5Ffixup=5Fcpu=5Fclocks so that bi=5Fbusfreq/4 i=
s passed
in, then the clock runs more accurately=2E However, its still not correct=2E=

This gives a decrementer frequency of 66666666Hz, but if I hard code the
value to 66000000Hz, the clock runs accurately=2E
Can anyone shed any light on why the value passed in by the boot loader
(redboot) seems to be inaccurate=2E

Cheers,


Richard=2E



--------------------------------------------------------------------
mail2web LIVE =96 Free email based on Microsoft=AE Exchange technology -
http://link=2Email2web=2Ecom/LIVE

Re: Clock / Timebase / Bus Frequencies Help

[Scott Wood]

On Mon, Aug 18, 2008 at 07:52:12AM -0400, richw@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

Re: Clock / Timebase / Bus Frequencies Help

[surendranath.moilla]

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@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@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@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>

Re: 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@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@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@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@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>     
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
>   

Re: Clock / Timebase / Bus Frequencies Help

[surendranath.moilla]

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.
>
> surendranath.moilla@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@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@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@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
>

Re: Clock / Timebase / Bus Frequencies Help

[Richard Whitlock]

Scott,
Thanks for that - you're right - redboot has the wrong crystal frequency 
in the cdl for our board.

Cheers,


Richard.

Scott Wood wrote:
> On Mon, Aug 18, 2008 at 07:52:12AM -0400, richw@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@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
>