[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node



On 08/06/2015 16:44, Chris (Christopher) Brand wrote:
Hi Julien,

Hi Chris,

My test was limited as I don't have a platform where CNTFRQ/CNTFRQ_EL0 is not 
valid. I may have done a mistake in the code.

Understood. That's why I thought it would be worthwhile posting my results :-)

What I see is that in preinit_xen_time(), the call to dt_property_read_u32() 
returns zero. When I built Xen, I set CONFIG_DTB_FILE, and looking at the 
corresponding dts file it has a timer node with a clock-frequency property. I 
know that our bootloader also creates a DTB, though, and it looks like that one 
does *not* have a clock-frequency property in the timer node, so I guess Xen 
ends up using that one somehow. CNTFRQ on core 0 (only) is also set to the 
correct frequency, so I end up with the correct frequency in my Dom0 kernel 
anyway.

dt_property_read_u32 returns 0 when it cannot find a property or because the 
size of the value is not valid.

The device tree provided via CONFIG_DTB_FILE will always take precedence to the 
one pass by the bootloader.

How do you set CONFIG_DTB_FILE?

A simple "export CONFIG_DTB_FILE=...".

Are you using an absolute path?

I would also look to see if by any chance the wrong device tree is set via 
CONFIG_DTB_FILE.

I did double-check before I posted, and everything looks right to me. I 
certainly could have missed something. It does look like it's *somehow* getting 
the DT generated by the bootloader.

You can check what is the device tree used by dumping it from DOM0.
Thought, it may be slightly different (some nodes are rewritten). You can dump 
it using dtc -I fs /proc/device-tree -O dts

When I do that (at a shell prompt in Dom0), the timer node does not have a 
clock-frequency property. So your patch isn't designed to help in this case 
(CNTFRQ set on core 0 only, no clock-frequency property in timer node of DT).

Well, my patch is designed to propagate the "clock-frequency" property in DOMU via the toolstack. The propagation for Dom0 is already present in Xen since last year [1].

I don't usually use CONFIG_DTB_FILE because my bootloader (u-boot via a script) is creating the different node for Xen (multiboot, chosen,...). Although, the CONFIG_DTB_FILE implementation in Xen is very obvious (only 2 lines which override the register which store the pointer in head.S).

Does your bootloader create Xen nodes (multiboot, chosen, ...) or the device tree provided by the bootloader contain such nodes? If not, then you are using an appended DT (via CONFIG_DTB_FILE) to Xen.

If you didn't yet do it, I would try to clean Xen repository and try to rebuild Xen to see if the build system was using a stall DTB by mistake.

Regards,

[1] 94191dcee8ff9f8b925824e54741f28b954bf95e "xen/arm: Pass the timer "clock-frequency" to DOM0 in make_timer_node()"

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.