sleep time is doubled, xilinx_zynq

Discussion:

sleep time is doubled, xilinx_zynq_zedboard

Giovanni Macciocu

2014-04-30 11:18:10 UTC

Hi All,

I'm working with a recent rtems head (23 April 2014) and the 'xilinx_zynq_zedboard' BSP.

I have everything up and running but somehow it looks if my clock / sleep relation is wrong. If i perform an usleep(1000) it will sleep for 2000 us instead of 1000. Also the baudrate of the serial port is 57600 instead 115000.

I wonder if it has something to do with the GTC (Global Clock Time) which is always clocked at 1/2 of the CPU frequency for an ARM Cortex A9.

Has anybody experienced similar problems or does somebody perhaps have an idea why such an error might occur?

Best regards,

Giovanni

Chris Johns

2014-05-01 08:24:49 UTC

Permalink

Post by Giovanni Macciocu
Hi All,
I'm working with a recent rtems head (23 April 2014) and the 'xilinx_zynq_zedboard' BSP.
I have everything up and running but somehow it looks if my clock / sleep relation is wrong. If i perform an usleep(1000) it will sleep for 2000 us instead of 1000. Also the baudrate of the serial port is 57600 instead 115000.
I wonder if it has something to do with the GTC (Global Clock Time) which is always clocked at 1/2 of the CPU frequency for an ARM Cortex A9.
Has anybody experienced similar problems or does somebody perhaps have an idea why such an error might occur?

I suggest you take a look at the BSPOPTS for the zync BSP. There are
some clocks you can set and one of these may help. I think
BSP_ARM_A9MPCORE_PERIPHCLK is the one.

Chris

Giovanni Macciocu

2014-05-01 08:53:07 UTC

Permalink

In my bspopt.h

/* ARM Cortex-A9 MPCore PERIPHCLK clock frequency in Hz */
#define BSP_ARM_A9MPCORE_PERIPHCLK 666666667U

This is the correct processor speed for my platform.
t you take a look at the BSPOPTS for the zync BSP. There are
some clocks you can set and one of these may help. I think
BSP_ARM_A9MPCORE_PERIPHCLK is the one.

Chris

Giovanni Macciocu

2014-05-01 10:52:07 UTC

Permalink

I've made some tests by changing the value of BSP_ARM_A9MPCORE_PERIPHCLK.
The value should be 666666667U as this is my cpu clock speed.

However in the following cases

#define BSP_ARM_A9MPCORE_PERIPHCLK (2 * 666666667U)

--> a Sleep now takes 4 times as long

#define BSP_ARM_A9MPCORE_PERIPHCLK 2 (666666667U / 2)

--> The sleep is now correct

In all cases the serial port keeps working at half of the normal buadrate.

Regards,

Giovanni
In my bspopt.h

/* ARM Cortex-A9 MPCore PERIPHCLK clock frequency in Hz */
#define BSP_ARM_A9MPCORE_PERIPHCLK 666666667U

This is the correct processor speed for my platform.
t you take a look at the BSPOPTS for the zync BSP. There are
some clocks you can set and one of these may help. I think
BSP_ARM_A9MPCORE_PERIPHCLK is the one.

Chris

Thomas Doerfler

2014-05-01 12:38:21 UTC

Permalink

Giovanni,

without knowing the BSP: You are talking about CPU clock, the macro is
call Periphclk. Can it be that the peripheral bus is clocked with half
of the CPU frequency?

wkr,

Thomas.

Post by Giovanni Macciocu
I've made some tests by changing the value of BSP_ARM_A9MPCORE_PERIPHCLK.
The value should be 666666667U as this is my cpu clock speed.
However in the following cases
#define BSP_ARM_A9MPCORE_PERIPHCLK (2 * 666666667U)
--> a Sleep now takes 4 times as long
#define BSP_ARM_A9MPCORE_PERIPHCLK 2 (666666667U / 2)
--> The sleep is now correct
In all cases the serial port keeps working at half of the normal buadrate.
Regards,
Giovanni
In my bspopt.h
/* ARM Cortex-A9 MPCore PERIPHCLK clock frequency in Hz */
#define BSP_ARM_A9MPCORE_PERIPHCLK 666666667U
This is the correct processor speed for my platform.
t you take a look at the BSPOPTS for the zync BSP. There are
some clocks you can set and one of these may help. I think
BSP_ARM_A9MPCORE_PERIPHCLK is the one.
Chris
_______________________________________________
rtems-devel mailing list
http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
http://www.rtems.org/mailman/listinfo/rtems-devel

--
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: Thomas.Doerfler-L1vi/***@public.gmane.org
Phone: +49-89-18 94 741-12
Fax: +49-89-18 94 741-09
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Giovanni Macciocu

2014-05-01 13:01:27 UTC

Permalink

Yes I've noticed the same thing.

The ARM documentation states the following:

PERIPHCLK must be synchronous with CLK, and the PERIPHCLK clock period,
N, must be configured as a multiple of the CLK clock period. This
multiple N must be equal to, or greater than two.
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/CJHIGGDG.html)

So yes I think in this case the the multiple N = 2, resulting in a
peripheral bus clocked on half the speed. I would say this is a bug in
the xilinx_zynq_zedboard BSP,
the default value in configure.ac is 666666667U which can never be the
case as this is the CPU speed.

This still doens't solve the problem related to the serial port dough.
I've rolled back to an rtems head of +/- half a year ago. There my
serial port does work with a baudrate at 11500, i haven't been able to
tacke the difference.

Regards,

Giovanni
PM >>>
Giovanni,

without knowing the BSP: You are talking about CPU clock, the macro is
call Periphclk. Can it be that the peripheral bus is clocked with half
of the CPU frequency?

wkr,

Thomas.

Post by Giovanni Macciocu
I've made some tests by changing the value of

BSP_ARM_A9MPCORE_PERIPHCLK.

Post by Giovanni Macciocu
The value should be 666666667U as this is my cpu clock speed.
However in the following cases
#define BSP_ARM_A9MPCORE_PERIPHCLK (2 * 666666667U)
--> a Sleep now takes 4 times as long
#define BSP_ARM_A9MPCORE_PERIPHCLK 2 (666666667U / 2)
--> The sleep is now correct
In all cases the serial port keeps working at half of the normal buadrate.
Regards,
Giovanni
In my bspopt.h
/* ARM Cortex-A9 MPCore PERIPHCLK clock frequency in Hz */
#define BSP_ARM_A9MPCORE_PERIPHCLK 666666667U
This is the correct processor speed for my platform.
t you take a look at the BSPOPTS for the zync BSP. There are
some clocks you can set and one of these may help. I think
BSP_ARM_A9MPCORE_PERIPHCLK is the one.
Chris
_______________________________________________
rtems-devel mailing list
http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
http://www.rtems.org/mailman/listinfo/rtems-devel

--
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: ***@embedded-brains.de
Phone: +49-89-18 94 741-12
Fax: +49-89-18 94 741-09
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
rtems-***@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Gedare Bloom

2014-05-01 14:21:05 UTC

Permalink

Post by Giovanni Macciocu
Yes I've noticed the same thing.
PERIPHCLK must be synchronous with CLK, and the PERIPHCLK clock period,
N, must be configured as a multiple of the CLK clock period. This
multiple N must be equal to, or greater than two.
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/CJHIGGDG.html)
So yes I think in this case the the multiple N = 2, resulting in a
peripheral bus clocked on half the speed. I would say this is a bug in
the xilinx_zynq_zedboard BSP,
the default value in configure.ac is 666666667U which can never be the
case as this is the CPU speed.

That definitely sounds like a bug in the zedboard BSP then. Although
setting the BSPOPT is a suitable workaround, if 333 MHz is the correct
peripheral clock speed for the zedboard then it should be made the
default value.

Post by Giovanni Macciocu
This still doens't solve the problem related to the serial port dough.
I've rolled back to an rtems head of +/- half a year ago. There my
serial port does work with a baudrate at 11500, i haven't been able to
tacke the difference.

You may be interested to try to use git-bisect to find the commit
where the buadrate changes. Depending how long it takes for you to
figure out the effective baudrate, git-bisect should get you to the
bad commit in reasonable time.

Post by Giovanni Macciocu
Regards,
Giovanni
PM >>>
Giovanni,
without knowing the BSP: You are talking about CPU clock, the macro is
call Periphclk. Can it be that the peripheral bus is clocked with half
of the CPU frequency?
wkr,
Thomas.

Post by Giovanni Macciocu
I've made some tests by changing the value of

BSP_ARM_A9MPCORE_PERIPHCLK.

buadrate.

Post by Giovanni Macciocu
Regards,
Giovanni
In my bspopt.h
/* ARM Cortex-A9 MPCore PERIPHCLK clock frequency in Hz */
#define BSP_ARM_A9MPCORE_PERIPHCLK 666666667U
This is the correct processor speed for my platform.
t you take a look at the BSPOPTS for the zync BSP. There are
some clocks you can set and one of these may help. I think
BSP_ARM_A9MPCORE_PERIPHCLK is the one.
Chris
_______________________________________________
rtems-devel mailing list
http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
http://www.rtems.org/mailman/listinfo/rtems-devel

--
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
Phone: +49-89-18 94 741-12
Fax: +49-89-18 94 741-09
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
http://www.rtems.org/mailman/listinfo/rtems-devel

Giovanni Macciocu

2014-05-01 15:31:11 UTC

Permalink

I've rolled back the file arm/xilinq-zynq/console/zynq-uart.c to the
version before the commit of 10 Dec. 2013.
Now the the UART works on the correct speed (11500) with the current
head.

Regards,

Giovanni

(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/CJHIGGDG.html)

Post by Giovanni Macciocu
So yes I think in this case the the multiple N = 2, resulting in a
peripheral bus clocked on half the speed. I would say this is a bug in
the xilinx_zynq_zedboard BSP,
the default value in configure.ac is 666666667U which can never be the
case as this is the CPU speed.

Post by Giovanni Macciocu
I've made some tests by changing the value of

BSP_ARM_A9MPCORE_PERIPHCLK.

buadrate.

Chris Johns

2014-05-02 00:16:42 UTC

Permalink

Post by Giovanni Macciocu
I've rolled back the file arm/xilinq-zynq/console/zynq-uart.c to the
version before the commit of 10 Dec. 2013.

There are a number of commits on that day. Do you mean ...

http://git.rtems.org/rtems/commit/?id=6e4255d9a5b32fcf4e665eb908a2091f327ab1d3

?

Post by Giovanni Macciocu
Now the the UART works on the correct speed (11500) with the current
head.

The uart driver was hard coded to a specific board and PL set up before
this commit. I changed the driver to allow board specific clocks via the
weak function 'zynq_uart_input_clock'. Maybe the Zed BSP needs to
provide one of these functions or the clock value default in the
console/zynq-uart.c needs to be based on a BSPOPTS based setting. The
default is (was?) working with my zc706 board. I will test today and see
if I can find a working JTAG cable.

The Zync is difficult because clocks can be configured in different ways
for the same board via the PL and this is exported by the Xilinx tools
via the ps7_init files. Typically you need to make sure the FSBL, the PL
bitfile and the BSP all line up. The weak function here lets you at the
application level above the BSP provide the correct set up.

Chris

Chris Johns

2014-05-02 08:31:57 UTC

Permalink

[ The first posting did not appear so I am sending it again. ]

Post by Giovanni Macciocu
I've rolled back the file arm/xilinq-zynq/console/zynq-uart.c to the
version before the commit of 10 Dec. 2013.

There are a number of commits on that day. Do you mean ...

http://git.rtems.org/rtems/commit/?id=6e4255d9a5b32fcf4e665eb908a2091f327ab1d3

?

Post by Giovanni Macciocu
Now the the UART works on the correct speed (11500) with the current
head.

Joel Sherrill

2014-05-01 13:03:48 UTC

Permalink

Post by Thomas Doerfler
Giovanni,
without knowing the BSP: You are talking about CPU clock, the macro is
call Periphclk. Can it be that the peripheral bus is clocked with half
of the CPU frequency?

In was thinking something similar Thomas (also in ignorance of this specific BSP). The main frequency may be correct but their may be two independent divider settings which can vary per implementation. This is "soft" hardware and could have a lot if potential tweak points. The BSP may or may not have the defaults to match your board instance and may or may not address all potential tweak points yet.

Are there dividers?

--joel

Post by Thomas Doerfler
wkr,
Thomas.

--
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
Phone: +49-89-18 94 741-12
Fax: +49-89-18 94 741-09
PGP: Public key available on request.
Diese Nachricht ist keine geschÃ€ftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
http://www.rtems.org/mailman/listinfo/rtems-devel

Giovanni Macciocu

2014-05-01 13:55:56 UTC

Permalink

There is only one type of zynz zedboard
(http://www.zedboard.org/product/zedboard). This board has the
Zynq®-7000 All Programmable SoC XC7Z020-CLG484-1
which runs at a default clock speed of 666 MHz. This can be downscaled
ofcourse but not upgraded. Maximum and default clock speed is thus
666MHz.

The value of BSP_ARM9MPCORE_PERIPHCLK can thus never be 666666667U as
this is equal to the max. clock speed, the ARM documentation states that
PERIPHCLK must be synchronous with CLK,
and that the PERIPHCLK clock period, N, must be configured as a
multiple of the CLK clock period.
On May 1, 2014 7:35 AM, Thomas Doerfler

Post by Thomas Doerfler
Giovanni,
without knowing the BSP: You are talking about CPU clock, the macro is
call Periphclk. Can it be that the peripheral bus is clocked with half
of the CPU frequency?

In was thinking something similar Thomas (also in ignorance of this
specific BSP). The main frequency may be correct but their may be two
independent divider settings which can vary per implementation. This is
"soft" hardware and could have a lot if potential tweak points. The BSP
may or may not have the defaults to match your board instance and may or
may not address all potential tweak points yet.

Are there dividers?

--joel

Post by Thomas Doerfler
wkr,
Thomas.

Post by Giovanni Macciocu
I've made some tests by changing the value of

BSP_ARM_A9MPCORE_PERIPHCLK.

Post by Thomas Doerfler

EHUG.

Post by Thomas Doerfler
_______________________________________________
rtems-devel mailing list
http://www.rtems.org/mailman/listinfo/rtems-devel